From netmod-bounces@ietf.org Wed Oct 1 02:01:51 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3C43A69DE; Wed, 1 Oct 2008 02:01: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 EE3163A69D4 for ; Wed, 1 Oct 2008 02:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 EK-9d9iZaTtW for ; Wed, 1 Oct 2008 02:01:49 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id BD91528C0EB for ; Wed, 1 Oct 2008 02:01:48 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 20C6D20269; Wed, 1 Oct 2008 11:02:10 +0200 (CEST) X-AuditID: c1b4fb3e-ab68abb000007a96-4b-48e33c929ce9 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 093C4209BF; Wed, 1 Oct 2008 11:02:10 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Oct 2008 11:02:09 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Oct 2008 11:02:09 +0200 Message-ID: <48E33DE0.20601@ericsson.com> Date: Wed, 01 Oct 2008 11:07:44 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Balazs Lengyel , "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" , netmod@ietf.org, "Ersue, Mehmet (NSN - DE/Munich)" References: <84028E2C0BD7D44F8308A6E7FF659CDB690087@FIESEXC015.nsn-intra.net> <20080930154522.GA25764@elstar.local> <48E33344.6020009@ericsson.com> <20081001083923.GA26926@elstar.local> In-Reply-To: <20081001083923.GA26926@elstar.local> X-OriginalArrivalTime: 01 Oct 2008 09:02:09.0450 (UTC) FILETIME=[62B668A0:01C923A4] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org It can make SW design easier if some meta information is visible from XML itself. Not every bit of the SW is fully YANG aware. Balazs Juergen Schoenwaelder wrote: > On Wed, Oct 01, 2008 at 10:22:28AM +0200, Balazs Lengyel wrote: > >> This solution allows you to check in the on-the-wire XML which basic >> grouping/list and which extension list/grouping is present, as the list >> itself carries the name of the grouping (only by a self-imposed naming >> convention). > > Why is this needed? There is a namespace, no? Since I know the modules > implemented on a device and their namespaces, I have everything I need > to identify the exact definition of something. > > /js > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 1 02:42: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 776C73A69DE; Wed, 1 Oct 2008 02:42: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 CFE2F3A6C19 for ; Wed, 1 Oct 2008 02:42:35 -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 jIH32HmlE2RB for ; Wed, 1 Oct 2008 02:42:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D5BAB3A69DE for ; Wed, 1 Oct 2008 02:42:34 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E0970C0066; Wed, 1 Oct 2008 11:42:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IqBKpBxAOrIK; Wed, 1 Oct 2008 11:42:51 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C1E0CC0064; Wed, 1 Oct 2008 11:42:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 22C157D79A3; Wed, 1 Oct 2008 11:42:52 +0200 (CEST) Date: Wed, 1 Oct 2008 11:42:52 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20081001094251.GB27057@elstar.local> Mail-Followup-To: Balazs Lengyel , "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" , netmod@ietf.org, "Ersue, Mehmet (NSN - DE/Munich)" References: <84028E2C0BD7D44F8308A6E7FF659CDB690087@FIESEXC015.nsn-intra.net> <20080930154522.GA25764@elstar.local> <48E33344.6020009@ericsson.com> <20081001083923.GA26926@elstar.local> <48E33DE0.20601@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48E33DE0.20601@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Augmentable Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, Oct 01, 2008 at 11:07:44AM +0200, Balazs Lengyel wrote: > It can make SW design easier if some meta information is visible from XML > itself. Not every bit of the SW is fully YANG aware. It makes SW design easier if you can _rely_ on it. Otherwise, you are fooling yourself. /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 Oct 1 03:40: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 D85CF3A681A; Wed, 1 Oct 2008 03:40: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 7FED43A6A2A for ; Wed, 1 Oct 2008 03:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zs6RWUnAr33B for ; Wed, 1 Oct 2008 03:40:26 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 58ADC3A681A for ; Wed, 1 Oct 2008 03:40:26 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A3F16214FB; Wed, 1 Oct 2008 12:40:48 +0200 (CEST) X-AuditID: c1b4fb3e-a8e85bb000007a96-d9-48e353b07d4b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2DB4C214F4; Wed, 1 Oct 2008 12:40:48 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Oct 2008 12:39:57 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Oct 2008 12:39:57 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 1 Oct 2008 12:39:55 +0200 User-Agent: KMail/1.9.10 References: <48E24913.40305@netconfcentral.com> In-Reply-To: <48E24913.40305@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200810011239.56025.david.partain@ericsson.com> X-OriginalArrivalTime: 01 Oct 2008 10:39:57.0370 (UTC) FILETIME=[0C43F1A0:01C923B2] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] NETMOD interim agenda X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi all, On Tuesday 30 September 2008 17.43.15 Andy Bierman wrote: > Hi, > > According to IETF Rules, the interim agenda is already 6 days late. Yes, and I'll take the hit for that. My apologies. > Is there going to be an agenda posted? It's being finalized between the chairs even as we speak... > Should we start a major issues list now? > > - import-by-revision (revision identification, etc.) > - module/submodule change control rules > - leafref and keyref > - feature and if-feature > > I would be thrilled if I left D.C. knowing the NETMOD WG > had really put a lot of thought into these 4 topics > and really nailed the solution. Thanks for the feedback! Others are very welcome to comment on what they think the most pressing issues are. We can make that a part of agenda bashing on the first day, or send it to the list or the chairs. Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 1 03:58: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 7E0233A6C33; Wed, 1 Oct 2008 03:58: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 1C38C3A6C3C for ; Wed, 1 Oct 2008 03:58:02 -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 yDZQ6qx99GO6 for ; Wed, 1 Oct 2008 03:58:01 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4347A3A6C33 for ; Wed, 1 Oct 2008 03:58:01 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A4B3761600C; Wed, 1 Oct 2008 12:58:23 +0200 (CEST) Date: Wed, 01 Oct 2008 13:01:15 +0200 (CEST) Message-Id: <20081001.130115.118873036.mbj@tail-f.com> To: david.partain@ericsson.com From: Martin Bjorklund In-Reply-To: <200810011239.56025.david.partain@ericsson.com> References: <48E24913.40305@netconfcentral.com> <200810011239.56025.david.partain@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] NETMOD interim agenda X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Partain wrote: > > Should we start a major issues list now? We already have the issues Wiki which is supposed to keep track of all open issues (http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang) > > - import-by-revision (revision identification, etc.) > > - module/submodule change control rules > > - leafref and keyref > > - feature and if-feature These are present on the wiki (I just added the change control rules issue) But I agree with you that we also need to prioritize. My high-prio list would be: yang-00000: module update rules - open yang-00413: import by revision - open yang-00750: add a "feature" feature - open Where the first two must be discussed together. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 1 04:00: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 967193A6C12; Wed, 1 Oct 2008 04:00: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 C7AD43A6C13 for ; Wed, 1 Oct 2008 04:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.843 X-Spam-Level: X-Spam-Status: No, score=-0.843 tagged_above=-999 required=5 tests=[AWL=0.407, 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 P4V5Y2YU6F8f for ; Wed, 1 Oct 2008 04:00:19 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 037183A6C12 for ; Wed, 1 Oct 2008 04:00:19 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 112E3D800D1 for ; Wed, 1 Oct 2008 13:00:42 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <200810011239.56025.david.partain@ericsson.com> References: <48E24913.40305@netconfcentral.com> <200810011239.56025.david.partain@ericsson.com> Organization: CESNET Date: Wed, 01 Oct 2008 13:00:42 +0200 Message-Id: <1222858842.8357.35.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] NETMOD interim agenda X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SGksCgpEYXZpZCBQYXJ0YWluIHDDrcWhZSB2IFN0IDAxLiAxMC4gMjAwOCB2IDEyOjM5ICswMjAw OgoKPiBUaGFua3MgZm9yIHRoZSBmZWVkYmFjayEgIE90aGVycyBhcmUgdmVyeSB3ZWxjb21lIHRv IGNvbW1lbnQgb24gd2hhdCB0aGV5IAo+IHRoaW5rIHRoZSBtb3N0IHByZXNzaW5nIGlzc3VlcyBh cmUuICBXZSBjYW4gbWFrZSB0aGF0IGEgcGFydCBvZiBhZ2VuZGEgCj4gYmFzaGluZyBvbiB0aGUg Zmlyc3QgZGF5LCBvciBzZW5kIGl0IHRvIHRoZSBsaXN0IG9yIHRoZSBjaGFpcnMuCgpJJ2QgYWRk IHRoZSBmb2xsb3dpbmcgaXRlbXMsIGluIHRoZSBvcmRlciBvZiBteSBwZXJzb25hbCBwcmlvcml0 eToKCi0gYXVnbWVudCByZWNvbnNpZGVyYXRpb24KLSByb2xlIG9mIERTREwgbWFwcGluZwotIG9y ZGVyIG9mIHNpYmxpbmdzCi0gaGFuZGxpbmcgb2YgbXVsdGlwbGUgcmVzdHJpY3Rpb25zIG9uIHR5 cGVzCi0gY29tbW9uIHBhcnQgZm9yIGFsbCBORVRNT0QgbmFtZXNwYWNlIFVSSXM/CgpDaGVlcnMs IExhZGEKCj4gCj4gQ2hlZXJzLAo+IAo+IERhdmlkCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KPiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4gbmV0bW9kQGll dGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QKLS0g CkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0 Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZAo= From netmod-bounces@ietf.org Wed Oct 1 04: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 997143A6AA2; Wed, 1 Oct 2008 04: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 3DB763A6C25 for ; Wed, 1 Oct 2008 04:19: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 0Pi53NX4dvmg for ; Wed, 1 Oct 2008 04:19:56 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 3A52B3A6AA2 for ; Wed, 1 Oct 2008 04:19:56 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9BB0C21327; Wed, 1 Oct 2008 13:20:18 +0200 (CEST) X-AuditID: c1b4fb3e-a7682bb000007a96-12-48e35cf2b9ef Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 91B07206E1; Wed, 1 Oct 2008 13:20:18 +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, 1 Oct 2008 13:20:18 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Oct 2008 13:20:18 +0200 Message-ID: <48E35F71.3090203@ericsson.com> Date: Wed, 01 Oct 2008 13:30:57 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <48E24913.40305@netconfcentral.com> <200810011239.56025.david.partain@ericsson.com> <20081001.130115.118873036.mbj@tail-f.com> In-Reply-To: <20081001.130115.118873036.mbj@tail-f.com> X-OriginalArrivalTime: 01 Oct 2008 11:20:18.0134 (UTC) FILETIME=[AF273760:01C923B7] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] NETMOD interim agenda X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I thought we use the open issues list. My priority list would include: # yang-00221: rpc statement in list - open # yang-00935: Default handling issues - open Balazs Martin Bjorklund wrote: > David Partain wrote: >>> Should we start a major issues list now? > > We already have the issues Wiki which is supposed to keep track of all > open issues > (http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang) > >>> - import-by-revision (revision identification, etc.) >>> - module/submodule change control rules >>> - leafref and keyref >>> - feature and if-feature > > These are present on the wiki (I just added the change control rules > issue) > > But I agree with you that we also need to prioritize. My high-prio list > would be: > > yang-00000: module update rules - open > yang-00413: import by revision - open > yang-00750: add a "feature" feature - open > > Where the first two must be discussed together. > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 1 04:24:16 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C6323A6C38; Wed, 1 Oct 2008 04:24:16 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9303A6C38 for ; Wed, 1 Oct 2008 04:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 IvmSMXKLh0pD for ; Wed, 1 Oct 2008 04:24:14 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 15F5A3A6A34 for ; Wed, 1 Oct 2008 04:24:14 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2F39F214A1 for ; Wed, 1 Oct 2008 13:24:31 +0200 (CEST) X-AuditID: c1b4fb3e-aae89bb000007a96-f7-48e35dee1062 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EC72021501 for ; Wed, 1 Oct 2008 13:24:30 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Oct 2008 13:24:30 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Oct 2008 13:24:30 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 1 Oct 2008 13:24:29 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200810011324.29974.david.partain@ericsson.com> X-OriginalArrivalTime: 01 Oct 2008 11:24:30.0382 (UTC) FILETIME=[458134E0:01C923B8] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Information about the upcoming interim (including 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 Greetings, Some information about the upcoming interim next week. Note that all information is kept up-to-date at http://wiki.tools.ietf.org/wg/netmod/trac/wiki/interim_oct08 The goal of this meeting is to close officially as many open issues as possible. Clearly, the consensus of the room will be verified on this mailing list. The chairs want to be sure we finish each topic by clearly establishing the proposed consensus to take to the list. We will not move off a topic until we have determined that there is 1) a specific consensus proposal, or 2) the WG has not and most likely will not reach consensus on the item during the meeting and it requires more ML discussion. We will have internet connectivity in the room and, as such, will be using the jabber room. We will need a set of volunteers to scribe as much as possible since voice out isn't going to happen. The jabber room will give us some record of our conversations. In addition, we will absolutely need minute takers, so please volunteer in advance of the meeting. Reading you should do before arriving: 1. The two WG drafts: http://tools.ietf.org/wg/netmod/draft-ietf-netmod-yang/ http://tools.ietf.org/wg/netmod/draft-ietf-netmod-yang-types/ 2. The NETMOD mailing list: http://www.ietf.org/mail-archive/web/netmod/current/maillist.html 3. Phil Shafer's architecture draft: http://tools.ietf.org/html/draft-shafer-netmod-arch-00 The agenda of the meeting will be approximately the following: 1. Introduction, WG Status and agenda bashing 2. Work through known issues in the YANG and YANG types documents, with an emphasis on the former. The issues will be taken from the mailing list and from the wiki. See http://trac.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang and http://trac.tools.ietf.org/wg/netmod/trac/wiki/Issues_types We will work on the types draft first in the assumption that there are fewer and simpler issues to deal with. Those issues lists will be (more) up-to-date by the end of this week. However, the assumption is that people are caught up on the mailing list, which is where the issues have been discussed. The authors and the chairs will work together to prioritize the lists so that focus is on the right issues. That prioritized list will be on the wiki by close of work on Friday. 3. Discuss the architecture draft for possible acceptance as a starting point for the WG architecture draft. Note that there will be no discussion on the DSDL mapping work, since we do not currently have a draft published. Assuming that draft is available for Minneapolis, we will spend time on it then. See you in a week! David^2 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 1 08:41: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 A2F193A67E9; Wed, 1 Oct 2008 08:41: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 60B553A689F for ; Wed, 1 Oct 2008 08:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.482 X-Spam-Level: X-Spam-Status: No, score=-1.482 tagged_above=-999 required=5 tests=[AWL=-0.741, 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 KjIonXK7dyVF for ; Wed, 1 Oct 2008 08:41:39 -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 3969B3A67E9 for ; Wed, 1 Oct 2008 08:41:39 -0700 (PDT) X-Trace: 88516225/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.52.109 X-SBRS: None X-RemoteIP: 213.116.52.109 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAGM340jVdDRt/2dsb2JhbACDRziIXbFkA4Fn X-IronPort-AV: E=Sophos;i="4.33,344,1220223600"; d="scan'208";a="88516225" X-IP-Direction: IN Received: from 1cust109.tnt102.lnd4.gbr.da.uu.net (HELO allison) ([213.116.52.109]) by smtp.pipex.tiscali.co.uk with SMTP; 01 Oct 2008 16:42:00 +0100 Message-ID: <001101c923d2$d15b5da0$0601a8c0@allison> From: "tom.petch" To: "Romascanu, Dan \(Dan\)" , "NETMOD Working Group" References: Date: Wed, 1 Oct 2008 16:31:55 +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 Subject: Re: [netmod] ForCES Forwarding Element Model 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 Belatedly, yes I have been tracking the ForCES model, do understand it (but found it very hard work to understand). The terminology caused me much grief - same words given a special meaning in ForCES when they already had one in XML - so I pressed for and got changes there, making it more XML-friendly. I had not seen it as a candidate for YANG (assuming that that is what you mean by being a NETMOD candidate) but as I expect you are aware, the author is active on both Netconf and NETMOD working group lists and may have his own view Tom Petch ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "NETMOD Working Group" Sent: Wednesday, September 24, 2008 4:17 PM Subject: [netmod] ForCES Forwarding Element Model > I am reviewing > http://www.ietf.org/internet-drafts/draft-ietf-forces-model-15.txt which > is on the IESG table for approval. It looks like a good candidate for > NETMOD if the language was ready. Is any of you folks familiar with this > work and thought how NETMOD would apply? Other comments? > > Dan > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 1 08:50:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E6CC3A689F; Wed, 1 Oct 2008 08:50:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AA5F28C212 for ; Wed, 1 Oct 2008 08:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.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 Lfe6IeGmg+aU for ; Wed, 1 Oct 2008 08:50:24 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 7572128C1FE for ; Wed, 1 Oct 2008 08:50:21 -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 m91Fohf5025737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 1 Oct 2008 17:50:43 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m91Fohga023888; Wed, 1 Oct 2008 17:50:43 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Oct 2008 17:50:43 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 1 Oct 2008 17:50:41 +0200 Message-ID: In-Reply-To: <200810011324.29974.david.partain@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Information about the upcoming interim (including agenda) Thread-Index: AckjuEzpsbW4jvqXTwuc5d56/fz29QAJOx9g References: <200810011324.29974.david.partain@ericsson.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext David Partain" , X-OriginalArrivalTime: 01 Oct 2008 15:50:43.0481 (UTC) FILETIME=[7636B090:01C923DD] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081001175043-22346BB0-179E6E50/0-0/0-15 X-purgate-size: 3671/0 Subject: Re: [netmod] Information about the upcoming interim (including 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 Dear David ^2, > since voice out isn't going to happen. What about SHOUTcast or another conf switch? Is there any technical issue? Cheers, Mehmet > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of ext David Partain > Sent: Wednesday, October 01, 2008 1:24 PM > To: netmod@ietf.org > Subject: [netmod] Information about the upcoming interim > (including agenda) > > Greetings, > > Some information about the upcoming interim next week. Note that all > information is kept up-to-date at > http://wiki.tools.ietf.org/wg/netmod/trac/wiki/interim_oct08 > > The goal of this meeting is to close officially as many open > issues as > possible. Clearly, the consensus of the room will be > verified on this > mailing list. The chairs want to be sure we finish each > topic by clearly > establishing the proposed consensus to take to the list. We > will not move off > a topic until we have determined that there is 1) a specific consensus > proposal, or 2) the WG has not and most likely will not reach > consensus on the > item during the meeting and it requires more ML discussion. > > We will have internet connectivity in the room and, as such, > will be using the > jabber room. We will need a set of volunteers to scribe as > much as possible > since voice out isn't going to happen. The jabber room will > give us some > record of our conversations. In addition, we will absolutely > need minute > takers, so please volunteer in advance of the meeting. > > Reading you should do before arriving: > > 1. The two WG drafts: > > http://tools.ietf.org/wg/netmod/draft-ietf-netmod-yang/ > http://tools.ietf.org/wg/netmod/draft-ietf-netmod-yang-types/ > > 2. The NETMOD mailing list: > http://www.ietf.org/mail-archive/web/netmod/current/maillist.html > > 3. Phil Shafer's architecture draft: > http://tools.ietf.org/html/draft-shafer-netmod-arch-00 > > The agenda of the meeting will be approximately the following: > > 1. Introduction, WG Status and agenda bashing > > 2. Work through known issues in the YANG and YANG types > documents, with an > emphasis on the former. The issues will be taken from the > mailing list and > from the wiki. See > http://trac.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang and > http://trac.tools.ietf.org/wg/netmod/trac/wiki/Issues_types > We will work on the types draft first in the assumption that > there are fewer > and simpler issues to deal with. > > Those issues lists will be (more) up-to-date by the end of > this week. > However, the assumption is that people are caught up on the > mailing list, > which is where the issues have been discussed. The authors > and the chairs > will work together to prioritize the lists so that focus is > on the right > issues. That prioritized list will be on the wiki by close > of work on > Friday. > > 3. Discuss the architecture draft for possible acceptance as > a starting point > for the WG architecture draft. > > Note that there will be no discussion on the DSDL mapping > work, since we do > not currently have a draft published. Assuming that draft is > available for > Minneapolis, we will spend time on it then. > > See you in a week! > > David^2 > > _______________________________________________ > 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 Oct 1 09:36: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 8DA9F3A659A; Wed, 1 Oct 2008 09:36: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 B58CF3A68F4 for ; Wed, 1 Oct 2008 09:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.361 X-Spam-Level: X-Spam-Status: No, score=-3.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOcF+n2-bE+P for ; Wed, 1 Oct 2008 09:36:35 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id CF94A3A659A for ; Wed, 1 Oct 2008 09:36:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 90142430320; Wed, 1 Oct 2008 09:36:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-162.clppva.btas.verizon.net [71.161.51.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id B03CD43031C; Wed, 1 Oct 2008 09:36:34 -0700 (PDT) Message-ID: <48E3A6FE.10709@joelhalpern.com> Date: Wed, 01 Oct 2008 12:36:14 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "tom.petch" References: <001101c923d2$d15b5da0$0601a8c0@allison> In-Reply-To: <001101c923d2$d15b5da0$0601a8c0@allison> Cc: NETMOD Working Group Subject: Re: [netmod] ForCES Forwarding Element Model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org My own take was that ForCES was not well matched to the NetMod / NetConf needs. Firstly, the ForCES model and protocol are aimed at a very fine level of detail. Much moee detailed than would normally be visible in a CLI. Secondly, and closely related to the first, ForCES uses a state oriented view, rather than an operational oriented view. ForCES is about configuring fine grained logical function blocks, and stringing those blocks together to actually deliver packet behaviors. Which brings us to the conceptual difference. In the ForCES model, while forwarding elements can be affected with SNMP, it is assumed that the normal use of configuration operations (SNMP, CLI, NetConf) would be with the CE. And that hese operations would be in terms of higher level constructs (traffic classes and their per hob behaviors, for example.) The Control Element (CE) is responsible for translating that into the details required to configure the distinct FEs (possibly from different vendors, with differing capabilities) to deliver the user requested effects. Note that as a result of these decisions, for example, the ForCES protocol is not XML at all. It is operations using the model defined by XML documents. But those operations are encoded in a binary TLV protocol, since it is for use by the CE, which is presumed to know the XML definitions of the various components. Yours, Joel M. Halpern tom.petch wrote: > Belatedly, yes I have been tracking the ForCES model, do understand it (but > found it very hard work to understand). The terminology caused me much grief - > same words given a special meaning in ForCES when they already had one in XML - > so I pressed for and got changes there, making it more XML-friendly. > > I had not seen it as a candidate for YANG (assuming that that is what you mean > by being a NETMOD candidate) but as I expect you are aware, the author is active > on both Netconf and NETMOD working group lists and may have his own view > > Tom Petch > > > ----- Original Message ----- > From: "Romascanu, Dan (Dan)" > To: "NETMOD Working Group" > Sent: Wednesday, September 24, 2008 4:17 PM > Subject: [netmod] ForCES Forwarding Element Model > > >> I am reviewing >> http://www.ietf.org/internet-drafts/draft-ietf-forces-model-15.txt which >> is on the IESG table for approval. It looks like a good candidate for >> NETMOD if the language was ready. Is any of you folks familiar with this >> work and thought how NETMOD would apply? Other comments? >> >> Dan >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > 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 Oct 2 01:47:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39BD73A6848; Thu, 2 Oct 2008 01:47:39 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24FD23A6AAF for ; Thu, 2 Oct 2008 01:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, 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 IHPFAwRYDqpc for ; Thu, 2 Oct 2008 01:47:37 -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 5A01E3A6848 for ; Thu, 2 Oct 2008 01:47:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,349,1220241600"; d="scan'208";a="145893569" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 02 Oct 2008 04:47:16 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Oct 2008 04:47:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Oct 2008 10:47:14 +0200 Message-ID: In-Reply-To: <001101c923d2$d15b5da0$0601a8c0@allison> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] ForCES Forwarding Element Model Thread-Index: Ackj3EyMXpkcHP3JS22OwNe4vDRu/wAjoJ4w References: <001101c923d2$d15b5da0$0601a8c0@allison> From: "Romascanu, Dan (Dan)" To: "tom.petch" , "NETMOD Working Group" Subject: Re: [netmod] ForCES Forwarding Element Model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > I had not seen it as a candidate for YANG (assuming that that > is what you mean by being a NETMOD candidate) but as I expect > you are aware, the author is active on both Netconf and > NETMOD working group lists and may have his own view Actually what I had in mind was using NETMOD to meet the goals of ForCES but I am aware as I said that the timing was working against such a course of the events. The other course that you are mentioning would have been an interesting path that I frankly did not think about, but this is also by now just another not walked what-if path in the history. Yes, I would also be interested to listen opinions from the principal author or other ForCES contributors on these topics. Dan > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Oct 2 07:48: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 245773A67E4; Thu, 2 Oct 2008 07:48: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 2AD363A697A for ; Thu, 2 Oct 2008 07:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 bvgULvBsor+T for ; Thu, 2 Oct 2008 07:48:21 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id AB87B3A67E4 for ; Thu, 2 Oct 2008 07:48:20 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Thu, 02 Oct 2008 07:46:13 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Oct 2008 07:47:20 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Oct 2008 07:47:20 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Oct 2008 07:47: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 m92ElJM45109; Thu, 2 Oct 2008 07:47: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 m92Eh7dv027442; Thu, 2 Oct 2008 14:43:08 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200810021443.m92Eh7dv027442@idle.juniper.net> To: David Partain In-reply-to: <200810011239.56025.david.partain@ericsson.com> Date: Thu, 02 Oct 2008 10:43:07 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 Oct 2008 14:47:19.0927 (UTC) FILETIME=[C5882870:01C9249D] Cc: netmod@ietf.org Subject: Re: [netmod] NETMOD interim agenda X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Partain writes: >It's being finalized between the chairs even as we speak... I need a final head count asap. The interim web page lists: http://wiki.tools.ietf.org/wg/netmod/trac/wiki/interim_oct08 Attendee List * David Harrington * David Partain * Martin Bjorklund * Phil Shafer * Andy Bierman * David Reid * Jurgen Schonwalder (probably) * Mehmet Ersue (probably) * Ladislav Lhotka * Ran Atkinson * Russ Housley (probably for part of the time) * Ron Bonica * Balazs Lengyel * Mike Vaughn (Jurgen and Mehmet, are you coming?) If you are on that list but will not attend, please let me know. If you are not on the list and will attend, please let me know. If you don't let me know, you get to sit and drool while the rest of us eat delicious snacks. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Oct 2 08:21:13 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EC4C3A6A77; Thu, 2 Oct 2008 08:21:13 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2B193A6A8B for ; Thu, 2 Oct 2008 08:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.088, 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 UYM12L+RWLof for ; Thu, 2 Oct 2008 08:21:08 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id ECBA43A6A77 for ; Thu, 2 Oct 2008 08:21:08 -0700 (PDT) Received: (qmail 66926 invoked from network); 2 Oct 2008 15:20:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.138.156 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 2 Oct 2008 15:20:47 -0000 X-YMail-OSG: 1a.UoEMVM1mRJc0nXAuddbgfYIWagGGCd8rKHBm0iayu8kCvKsJ8XSBR9MewEZs_ielqJ8JxG6F.yrs79n9vcoCaRuSTiXnVowtIEHhiYKCilYTXsBxewLa_H8EcMHOP6h4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48E4E6CD.7070005@netconfcentral.com> Date: Thu, 02 Oct 2008 08:20:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: David Reid References: <200809301729.NAA23997@adminfs.snmp.com> In-Reply-To: <200809301729.NAA23997@adminfs.snmp.com> Cc: netmod@ietf.org Subject: Re: [netmod] read-create access X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Reid wrote: > SMIv2's addition of read-create access was helpful to code generators > to know what code to generate to handle a row create attempt. An attempt > to create a row in a read-write table generates an error response while an > attempt to create a row in a read-create table creates a new row (if all > the other constraints are met). > > I'd like to automatically generate similar code from yang, but the only > information I have is config true/false. Is there a way to know if new > list entries can be created that I'm not seeing? If not, would it be useful > to have a substatement under the list statement which would indicate if new > list entries can be created? Or maybe extend the config statement in some > way? > There have been a few corner cases mentioned for max-access, and this topic has been discussed several times in the past. The scope of our problem space is the NETCONF operation, which has merge, replace, create, and delete. The config-stmt, mandatory-stmt, and object type (leaf, list, container, etc.) of the new node and the parent node are usually enough to determine what to do. There seems to be at least 3 distinct options not currently supported: 1) create and delete only (no mgr editing after creation) 2) merge and replace only on existing nodes (no mgr create or delete, just edit) 3) edit for the startup version only (no affect until next reboot) I do not think YANG should support this sort of partial implementation of the operation. NETCONF conformance means that the agent provides knobs suited for NETCONF, which have very clear implementation behavior. If mandatory is false, then create/delete can be done at any time by the manager. If true, the existence of the parent node (or siblings in a choice) determines this property. Any existing config data node can be edited at any time by the manager (except if locked or access denied). Any config change must take affect right away for and at time for as target. > -David Reid Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Oct 2 23:51:21 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA5F33A69E0; Thu, 2 Oct 2008 23:51:21 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5651E3A6A3C for ; Thu, 2 Oct 2008 23:51: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 NI0s8A1RCVhn for ; Thu, 2 Oct 2008 23:51:18 -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 DACBD3A69D8 for ; Thu, 2 Oct 2008 23:51:17 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3AFC5616006 for ; Fri, 3 Oct 2008 08:51:44 +0200 (CEST) Date: Fri, 03 Oct 2008 08:54:50 +0200 (CEST) Message-Id: <20081003.085450.158213844.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] 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 input to the discussions next week, we have written down a proposal for how to handle conformance in YANG. Most of the proposal is included below. For all the details, including new ABNF rules, see: http://www.yang-central.org/tmp/draft-ietf-netmod-yang-01-with-conformance.txt or the diff to the current version: http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-netmod-yang-01.txt&url2=http://www.yang-central.org/tmp/draft-ietf-netmod-yang-01-with-conformance.txt Martin & Phil ------------------------ ** Conformance @conformance@ Conformance is a measure of how accurately a device follows the model. Generally speaking, devices are responsible for implementing the model faithfully, allowing applications to treat devices which implement the model identically. Deviations from the model can reduce the utility of the model and increase fragility into applications that use it. YANG modelers have three levels of conformance: - the basic behavior of the model - optional features that are part of the model - deviations from the model We will consider each of these in sequence. *** Basic Behavior The model defines a contract between the client and server, which allows both parties to have faith the other knows the syntax and semantics behind the modeled data. The strength of YANG lies in the strength of this contract and the mindless devotion with which implementers follow it. *** Optional Features In many models, the modeler will allow sections of the model to be conditional, based on the device. The device controls whether these conditional portions of the model are supported or valid for that particular device. For example, a syslog data model may choose to include the ability to save logs locally, but the modeler will realize that this is only possible if the device has local storage. If there is no local storage, an application should not tell the device to save logs. YANG supports this conditional mechanism using a construct called "features". A module may declare any number of features, identified by simple strings, and may make portions of the module optional based on those feature. If the device supports a feature, then the corresponding portions of the module are valid for that device. If the device doesn't support the feature, those parts of the module are not valid, and applications should behave accordingly. Features give the modeler a mechanism for making portions of the module conditional in a manner that is controlled by the device. The model can express constructs which are not universally present in all devices. These features are included in the model definition, allowing a consistent view and allowing applications to learn which features are supported and tailor their behavior to the device. Features are defined using the "feature" statement. Definitions in the module that are conditional to the feature are noted by the "if-feature" statement with the name of the feature as its argument. Further details are available in ^feature^. *** Deviations In an ideal world, all devices would be required to implement the model exactly as defined, and deviations from the model would not be allowed. But in the real world, devices are often not able or willing to implement the model as written. For YANG-based automation to deal with these device deviations, a mechanism must exist for devices to inform applications of the specifics of such deviations. For example, a BGP module may allow any number of BGP peers, but a particular device may only support 16 BGP peers. Any application configuring the 17th peer will receive an error. While an error may suffice to let the application know it cannot add another peer, it would be far better if the application had prior knowledge of this limitation and could prevent the user from starting down the path that could not succeed. Device deviations are declared using the "deviation" statement, which takes as its argument a string which identifies a node in the schema tree. The contents of the statement details the manner in which the device implementation deviates from the contract as defined in the module. *** Announcing Conformance Information in the Message Devices indicate the names of supported features and device deviations via the message. In hello messages, the features are encoded in the "features" parameter within the URI. The value of this parameter is a comma-separated list of feature names which the device supports for the specific module. http://example.com/mod/mcp?features=feat1&module=mcp http://example.com/mod/some?module=some&features=one,two,three Device deviations are announced via the "deviations" parameter. The value of the deviations parameter is a comma-separated list of modules containing deviations from the capability's module. http://example.com/abc?deviations=my-devs ** Conformance-related Statements @conformance-stmts@ This section defines statements related to conformance, as described in ^conformance^. *** The feature Statement @feature@ The "feature" statement is used to define a mechanism by which portions of the schema are marked as conditional. A feature name is defined that can later be referenced using the "if-feature" statement (see ^if-feature^). Schema nodes tagged with a feature are ignored unless the device supports the given feature. This allows portions of the YANG module to be conditional based on conditions on the device. The model can represent the abilities of the device within the model, giving a richer model that allows for differing device abilities and roles. The argument to the "feature" statement is the name of the new feature, and follows the rules for identifiers in ^identifiers^. This name is used by the "if-feature" statement to tie the schema nodes to the feature. In this example, a feature called "local-storage" represents the ability for a device to store syslog messages on local storage of some sort. This feature is used to make the "local-storage-limit" leaf conditional on the presence of some sort of local-storage. If the device does not report that it supports this feature, the local-storage-limit node is not supported. module my-syslog { ... feature local-storage { description "This feature means the device supports local storage (memory, flash or disk) that can be used to store syslog messages."; } container syslog { leaf local-storage-limit { if-feature local-storage; config false; description "The amount of local storage that can be used to hold syslog messages."; } } } The "if-feature" statement can be used in many places within the YANG syntax. Definitions tagged with "if-feature" are ignored when the device does not support that feature. In this example, a type definition is built based on features. If the feature "v4-support" is present, the application can know that the device will include support for addresses in the IPv4 notation, and if the "v6-support" feature is present, it can know there is support for IPv6 addresses. typedef peer-address { description "Address of a peer"; type union { type inet:ipv4address { if-feature v4-support; } type inet:ipv6address { if-feature v6-support; } } } **** The feature's Substatements !! table !! head ! substatement ! section ! cardinality !! row ! description ! ^description^ ! 0..1 !! row ! if-feature ! ^if-feature^ ! 0..n !! row ! status ! ^status^ ! 0..1 !! row ! reference ! ^reference^ ! 0..1 *** The if-feature Statement @if-feature@ The "if-feature" statement is used to mark portions of the model as conditional. The argument is the name of a feature, as defined by a "feature" statement. If a prefix is present on the feature name, it refers to a feature defined the module which was imported with that prefix. Otherwise a feature with the matching name must be defined in the current module or an included submodule. Since submodules cannot include the parent module, any features in the module which need to be exposed to submodules must be defined in a submodule. Submodules can then include this submodule to find the definition of the feature. *** The deviation Statement @deviation@ The deviation statement defines a hierarchy of the module which the device does not implement faithfully. The argument is a string that identifies the node in the schema tree where a deviation from the module occurs. This node is called the deviation's target node. The contents of the deviation statement give details about the deviation. The argument's syntax is formally defined by the rule "deviation-arg" in ^grammar^. Deviations define the way a device or class of devices deviate from the standard. This means that deviations MUST never be part of a published standard, since they are the mechanism for learning how implementations vary from the standards. Device deviations are strongly discouraged and should only be used as a last resort. Telling the application how a device fails to follow the standard is no substitute for implementing the standard directly. However in many cases the cost of following the standard is heavy and the payoff may be small. A particular device may not have the hardware or software ability to support parts of a standard module. When this occurs, the device makes a choice to treat attempts to configure unsupported parts of the module as either an error that is reported back to the unsuspecting application, or ignore that incoming requests. Neither choice is acceptable. Instead, YANG allows devices to document portions of the base module which are not supported or supported but with different syntax, by using the "deviation" statement. **** The deviation's Substatements !! table !! head ! substatement ! section ! cardinality !! row ! description ! ^description^ ! 0..1 !! row ! deviate ! ^deviate^ ! 0..n !! row ! reference ! ^reference^ ! 0..1 **** The deviate Statement @deviate@ The "deviate" statement defines how the device's implementation of the target node deviates from its original definition. The argument is one of the strings "not-supported", "add", "replace", or "delete". The argument "not-supported" indicates that the target node is not implemented by this device. The argument "add" adds properties to the target node. The properties to add are identified as a substatement to the "deviate" statement. If the property can only appear once, the property MUST NOT exist in the target node. The argument "replace" replaces properties of the target node. The properties to replace are identified by substatements to the "deviate" statement. The property to replace MUST NOT exist in the target node. The argument "delete" deletes properties from the target node. The properties to delete are identified by substatement to "delete". The substatement's keyword MUST match a corresponding keyword in the target node, and the argument's string MUST be equal to the corresponding keyword's argument string in the target node. !! table The deviates's Substatements !! head ! substatement ! section ! cardinality !! row ! config ! ^config^ ! 0..1 !! row ! default ! ^leaf-default^ ! 0..1 !! row ! mandatory ! ^mandatory^ ! 0..1 !! row ! max-elements ! ^max-elements^ ! 0..1 !! row ! min-elements ! ^min-elements^ ! 0..1 !! row ! must ! ^must^ ! 0..n !! row ! type ! ^type^ ! 0..1 !! row ! unique ! ^unique^ ! 0..n !! row ! units ! ^units^ ! 0..1 **** Usage Example In this example, the device is informing client applications that it does not support the old RFC867-style "daytime" service. deviation /base:system/base:daytime { deviate not-supported; } The following example sets a device-specific default value to a leaf that does not have a default value defined: deviation /base:system/base:user/base:type { deviate add { default "admin"; // new users are 'admin' by default } } In this example, the device limits the number of name servers to 3: deviation /base:system/base:name-server { deviate replace { max-elements 3; } } If the original definition is: container system { must "daytime or time"; ... } a device might remove this must constraint by doing: deviation "/base:system" { deviate delete { must "daytime or time"; } } _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Oct 3 07:48: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 80E813A688C; Fri, 3 Oct 2008 07:48: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 573313A6820 for ; Fri, 3 Oct 2008 07:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.080, 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 ERgv34mJmirs for ; Fri, 3 Oct 2008 07:48:41 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 7F04A3A688C for ; Fri, 3 Oct 2008 07:48:41 -0700 (PDT) Received: (qmail 65258 invoked from network); 3 Oct 2008 14:46:46 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.138.156 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 3 Oct 2008 14:46:44 -0000 X-YMail-OSG: vLlXYpkVM1nWx5Aqi.rEy5bGqQuyDAuPT6U7uZ5dvvXUpPxpNaMjeNmyuRjwbtY.QG5v6OmDVQGvRVodj_.O54NdGgZceyyT19teuRlCQaAgENbq_EXo_G4NqIUXY6i7ITltsoSzneNqA4z.77.AI9dI X-Yahoo-Newman-Property: ymail-3 Message-ID: <48E63053.3050509@netconfcentral.com> Date: Fri, 03 Oct 2008 07:46:43 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <20081003.085450.158213844.mbj@tail-f.com> In-Reply-To: <20081003.085450.158213844.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > As input to the discussions next week, we have written down a proposal > for how to handle conformance in YANG. > > Most of the proposal is included below. For all the details, > including new ABNF rules, see: > > http://www.yang-central.org/tmp/draft-ietf-netmod-yang-01-with-conformance.txt > > or the diff to the current version: > > http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-netmod-yang-01.txt&url2=http://www.yang-central.org/tmp/draft-ietf-netmod-yang-01-with-conformance.txt > > > Martin & Phil > This proposal has been expanded from the original feature request from the IPFIX WG. I strongly oppose the deviation features such as add, replace, and delete. There seems to be an underlying assumption that a vendor cannot implement a standard as specified, and should be able to add, delete, and replace the data model defined in the standard with different semantics. I do not think this is what an application developer has in mind when utilizing standard agent technology. I thought the 'if-feature' proposal was simply to partition a module into a flat set of non-overlapping conformance packages, called features. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Oct 3 12:53: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 ABE6F3A68AF; Fri, 3 Oct 2008 12:53: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 D0DCC3A6B66 for ; Fri, 3 Oct 2008 12:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.162, 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 sqddHlySEwNk for ; Fri, 3 Oct 2008 12:53:32 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7ob116.obsmtp.com [64.18.2.218]) by core3.amsl.com (Postfix) with ESMTP id 10E843A68AF for ; Fri, 3 Oct 2008 12:53:29 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP; Fri, 03 Oct 2008 12:53:39 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, 3 Oct 2008 12:53:27 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Oct 2008 12:53:27 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Oct 2008 12:53:26 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m93JrQM09952; Fri, 3 Oct 2008 12:53:26 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m93JnDCX014148; Fri, 3 Oct 2008 19:49:13 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200810031949.m93JnDCX014148@idle.juniper.net> To: Andy Bierman In-reply-to: <48E63053.3050509@netconfcentral.com> Date: Fri, 03 Oct 2008 15:49:12 -0400 From: Phil Shafer X-OriginalArrivalTime: 03 Oct 2008 19:53:26.0971 (UTC) FILETIME=[B38E68B0:01C92591] Cc: netmod@ietf.org Subject: Re: [netmod] 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: , 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 proposal has been expanded from the original feature request >from the IPFIX WG. Both proposals come from discussions in Dublin. The two are related pieces of the conformance story, so we worked them up together. >There seems to be an underlying >assumption that a vendor cannot implement a standard as specified, Assumption or fact? We have lots of historical examples. >I do not think this is what an application developer >has in mind when utilizing standard agent technology. The choice is to let these deviations be published and documented or to let them be discovered by each app writer anew. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Oct 3 13: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 403BA3A6839; Fri, 3 Oct 2008 13: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 033373A6A15 for ; Fri, 3 Oct 2008 13:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=0.226, 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 zGQk0m8eSLe0 for ; Fri, 3 Oct 2008 13:23:27 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 356DF3A6833 for ; Fri, 3 Oct 2008 13:23:27 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id BA54F76C322; Fri, 3 Oct 2008 22:23:17 +0200 (CEST) Date: Fri, 03 Oct 2008 22:25:33 +0200 (CEST) Message-Id: <20081003.222533.237590839.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48E63053.3050509@netconfcentral.com> References: <20081003.085450.158213844.mbj@tail-f.com> <48E63053.3050509@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] 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 Andy Bierman wrote: > I strongly oppose the deviation features such as > add, replace, and delete. There seems to be an underlying > assumption that a vendor cannot implement a standard as specified, > and should be able to add, delete, and replace the data model > defined in the standard with different semantics. > I do not think this is what an application developer > has in mind when utilizing standard agent technology. We're trying to attack the whole conformance / compliance / agent-capabilities problem. This proposal is essentially a YANG version of rfc 2580. > I thought the 'if-feature' proposal was simply to partition > a module into a flat set of non-overlapping conformance packages, > called features. It is. That's one part of the solution. The other part is the device deviations (~= AGENT-CAPABILITIES). /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Oct 3 13:53: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 B2DB63A6A07; Fri, 3 Oct 2008 13:53: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 7D9833A6A07 for ; Fri, 3 Oct 2008 13:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.073, 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 NLsxB3hRwD6j for ; Fri, 3 Oct 2008 13:53:34 -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 B2DDF3A6814 for ; Fri, 3 Oct 2008 13:53:34 -0700 (PDT) Received: (qmail 64445 invoked from network); 3 Oct 2008 20:54:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.138.156 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 3 Oct 2008 20:54:01 -0000 X-YMail-OSG: w.5TslkVM1l0Ju23lKHly33R1tXpFnXc4NrM7XZwNWFxA22paiLKcIkrUd1tCRoA4b9FchTa6zbkFd0NcmEl6sl6LfDhydiJn1oQPcI8uJL_Zyw3dGn5VKO0eM5HG1tzX.M- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48E68667.10708@netconfcentral.com> Date: Fri, 03 Oct 2008 13:53:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Phil Shafer References: <200810031949.m93JnDCX014148@idle.juniper.net> In-Reply-To: <200810031949.m93JnDCX014148@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] 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 Phil Shafer wrote: > Andy Bierman writes: >> This proposal has been expanded from the original feature request >>from the IPFIX WG. > > Both proposals come from discussions in Dublin. The two are related > pieces of the conformance story, so we worked them up together. > >> There seems to be an underlying >> assumption that a vendor cannot implement a standard as specified, > > Assumption or fact? We have lots of historical examples. > >> I do not think this is what an application developer >> has in mind when utilizing standard agent technology. > > The choice is to let these deviations be published and documented > or to let them be discovered by each app writer anew. > These device deviations should be in a separate document, not tied to the release of YANG 1.0. IMO, a standard for configuration management needs a stable and uniform API. If you cannot use the standard data model to do a particular function, then you need to use a proprietary data model, or something other than NETCONF. The success of SNMP conformance is varied, and since most of the conformance data gathered by the IETF has been for monitoring MIBs, the experience may not really apply to NETCONF. It is possible to write reasonable monitoring applications for standard MIB modules that have missing or proprietary data, because an agent can overlay as many monitoring MIBs on top of the same underlying data-store as needed. It is not possible to write reasonable applications for standard configuration data models if arbitrary pieces of the API have been changed in almost arbitrary ways by every device that implements the 'standard'. The reason I supported the if-feature partitioning is that it is 'all-or-nothing' conformance. If you advertise the feature 'foo', then you implement everything scoped by an 'if-feature foo;' statement; IMO, standards based configuration cannot work unless vendors implement the data models correctly, using features to partition the data model into as many pieces as needed to reach consensus in the WG creating the data model. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Oct 3 20:07:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 736903A68D1; Fri, 3 Oct 2008 20:07:56 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62F63A6828 for ; Fri, 3 Oct 2008 20:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 llmPCNwXFwZt for ; Fri, 3 Oct 2008 20:07:54 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 3DDAF3A68D1 for ; Fri, 3 Oct 2008 20:07:50 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Fri, 03 Oct 2008 20:08:15 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, 3 Oct 2008 20:05:54 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Oct 2008 20:05:54 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Oct 2008 20:05:54 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m9435rM88886; Fri, 3 Oct 2008 20:05: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 m9431dLh016060; Sat, 4 Oct 2008 03:01:39 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200810040301.m9431dLh016060@idle.juniper.net> To: Andy Bierman In-reply-to: <48E68667.10708@netconfcentral.com> Date: Fri, 03 Oct 2008 23:01:39 -0400 From: Phil Shafer X-OriginalArrivalTime: 04 Oct 2008 03:05:54.0185 (UTC) FILETIME=[1D4D0F90:01C925CE] Cc: netmod@ietf.org Subject: Re: [netmod] 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: , 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: >These device deviations should be in a separate document, >not tied to the release of YANG 1.0. That would require a rev of YANG (1.1?) which would be a tremendous cost for a new language. Incorporating this into the language from the start seems like a better path if we want it to succeed. >IMO, a standard for configuration management needs a stable >and uniform API. I think this would be grand, but I'm not prepared to bet the success of YANG on it. There are always justifications for nonconformance. To pretend that it won't happen is wishful thinking. So the question is will we deal with it by giving apps the tools to deal with it, or will we simply say that's not our problem and live in denial? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Oct 3 21:28: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 34C733A67EE; Fri, 3 Oct 2008 21:28: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 3D30A3A67EE for ; Fri, 3 Oct 2008 21:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.068, 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 G2CPrZjvdh-O for ; Fri, 3 Oct 2008 21:28:18 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 8EE1A3A67E1 for ; Fri, 3 Oct 2008 21:28:18 -0700 (PDT) Received: (qmail 5982 invoked from network); 4 Oct 2008 04:28:48 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.122.138.156 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 4 Oct 2008 04:28:46 -0000 X-YMail-OSG: 4xg2y20VM1nUF1bnYFvxgfjps2hwIRsn_0aUB9xaG2a3fPf49xAPX2zRsmRZC7ICXhD4Zmi1naRHmjz6Me7ySKiWuI70j98N3X32K8A7eQRl6qAsEzXmVUPLGPfHdaU4ChE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48E6F0FD.5070008@netconfcentral.com> Date: Fri, 03 Oct 2008 21:28:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Phil Shafer References: <200810040301.m9431dLh016060@idle.juniper.net> In-Reply-To: <200810040301.m9431dLh016060@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] 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 Phil Shafer wrote: > Andy Bierman writes: >> These device deviations should be in a separate document, >> not tied to the release of YANG 1.0. > > That would require a rev of YANG (1.1?) which would > be a tremendous cost for a new language. Incorporating > this into the language from the start seems like a better > path if we want it to succeed. > I do not think the 'deviation' stuff belongs on the standards track at all. IMO you cannot just mix and match config data structure members or RPC method parameters. You can't trade 2 standard leafs for 3 proprietary leafs, remove a few standard knobs, change a few more, etc., and have any hope of multi-vendor interoperability. Even if this work is pursued in the IETF, then this sort of meta-data needs to be specified in separate files from the data model definition. Maintaining vendor-specific standard variance in the data model file is not going to work. It is easy to decouple the data model variance language from the data modeling language. There is no reason at all that YANG 1.0 would need to reference the other document, or any reason to change it in order to specify a companion DM variance language. IMO, the requirements for NETCONF-based configuration management data model variance and conformance are not well understood, or agreed upon. It will delay YANG 1.0 significantly if this extra work is undertaken now. Andy >> IMO, a standard for configuration management needs a stable >> and uniform API. > > I think this would be grand, but I'm not prepared to bet > the success of YANG on it. There are always justifications > for nonconformance. To pretend that it won't happen is > wishful thinking. > > So the question is will we deal with it by giving apps the > tools to deal with it, or will we simply say that's not > our problem and live in denial? > > Thanks, > Phil > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Oct 3 23:54: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 2CFAA3A6850; Fri, 3 Oct 2008 23:54: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 9876E3A68DC for ; Fri, 3 Oct 2008 23:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[AWL=0.382, 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 JfXHwxUv4eCG for ; Fri, 3 Oct 2008 23:54:45 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6063C3A6850 for ; Fri, 3 Oct 2008 23:54:44 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A3225D800C8 for ; Sat, 4 Oct 2008 08:55:09 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20081003.085450.158213844.mbj@tail-f.com> References: <20081003.085450.158213844.mbj@tail-f.com> Organization: CESNET Date: Sat, 04 Oct 2008 08:55:08 +0200 Message-Id: <1223103308.8412.20.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] 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="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SGksCgoxLiBDb3VsZCB0aGUgZnVuY3Rpb25hbGl0eSBvZiAibm9uLWxvY2FsIiB0b3AtbGV2ZWwg YXVnbWVudCBwZXJoYXBzIGJlCm1vdmVkIHVuZGVyICJkZXZpYXRpb24iPy4gSXQgaGFzIHRoZSBz YW1lIHB1cnBvc2UsIGlmIEkgdW5kZXJzdGFuZCBpdApjb3JyZWN0bHkuCgoyLiBUaGUgZXhhbXBs ZQoKZGV2aWF0aW9uICIvYmFzZTpzeXN0ZW0iIHsgZGV2aWF0ZSBkZWxldGUgeyBtdXN0ICJkYXl0 aW1lIG9yIHRpbWUiOyB9IH0KCmFnYWluIHJhaXNlcyB0aGUgcXVlc3Rpb24gd2hldGhlciB0aGUg aWRlbnRpZmljYXRpb24gb2YgdGhlIG5vZGUKYWRkcmVzc2VkIGJ5IHRoZSBkZXZpYXRpb24gaXMg YmFzZWQgb24gbWF0Y2hpbmcgaW4gdGhlIGxleGljYWwgb3IgdmFsdWUKc3BhY2UuIFdoYXQgaWYg dGhlIG9yaWdpbmFsIG1vZHVsZSBoYXMgdGhlIGNvbmRpdGlvbiBleHByZXNzZWQgYXMKCm11c3Qg IihkYXl0aW1lKSBvciB0aW1lIjsKCm9yCgptdXN0ICJiYXNlOmRheXRpbWUgb3IgYmFzZTp0aW1l IjsKCkxhZGEKCk1hcnRpbiBCam9ya2x1bmQgcMOtxaFlIHYgUMOhIDAzLiAxMC4gMjAwOCB2IDA4 OjU0ICswMjAwOgo+IEhpLAo+IAo+IEFzIGlucHV0IHRvIHRoZSBkaXNjdXNzaW9ucyBuZXh0IHdl ZWssIHdlIGhhdmUgd3JpdHRlbiBkb3duIGEgcHJvcG9zYWwKPiBmb3IgaG93IHRvIGhhbmRsZSBj b25mb3JtYW5jZSBpbiBZQU5HLiAKPiAKPiBNb3N0IG9mIHRoZSBwcm9wb3NhbCBpcyBpbmNsdWRl ZCBiZWxvdy4gIEZvciBhbGwgdGhlIGRldGFpbHMsCj4gaW5jbHVkaW5nIG5ldyBBQk5GIHJ1bGVz LCBzZWU6Cj4gCj4gaHR0cDovL3d3dy55YW5nLWNlbnRyYWwub3JnL3RtcC9kcmFmdC1pZXRmLW5l dG1vZC15YW5nLTAxLXdpdGgtY29uZm9ybWFuY2UudHh0Cj4gCj4gb3IgdGhlIGRpZmYgdG8gdGhl IGN1cnJlbnQgdmVyc2lvbjoKPiAKPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwx PWh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW5ldG1vZC15YW5nLTAxLnR4dCZ1 cmwyPWh0dHA6Ly93d3cueWFuZy1jZW50cmFsLm9yZy90bXAvZHJhZnQtaWV0Zi1uZXRtb2QteWFu Zy0wMS13aXRoLWNvbmZvcm1hbmNlLnR4dAo+IAo+IAo+IE1hcnRpbiAmIFBoaWwKPiAKPiAKPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiAKPiAqKiBDb25mb3JtYW5jZSBAY29uZm9ybWFuY2VA Cj4gCj4gQ29uZm9ybWFuY2UgaXMgYSBtZWFzdXJlIG9mIGhvdyBhY2N1cmF0ZWx5IGEgZGV2aWNl IGZvbGxvd3MgdGhlCj4gbW9kZWwuICBHZW5lcmFsbHkgc3BlYWtpbmcsIGRldmljZXMgYXJlIHJl c3BvbnNpYmxlIGZvciBpbXBsZW1lbnRpbmcKPiB0aGUgbW9kZWwgZmFpdGhmdWxseSwgYWxsb3dp bmcgYXBwbGljYXRpb25zIHRvIHRyZWF0IGRldmljZXMgd2hpY2gKPiBpbXBsZW1lbnQgdGhlIG1v ZGVsIGlkZW50aWNhbGx5LiAgRGV2aWF0aW9ucyBmcm9tIHRoZSBtb2RlbCBjYW4gcmVkdWNlCj4g dGhlIHV0aWxpdHkgb2YgdGhlIG1vZGVsIGFuZCBpbmNyZWFzZSBmcmFnaWxpdHkgaW50byBhcHBs aWNhdGlvbnMKPiB0aGF0IHVzZSBpdC4KPiAKPiBZQU5HIG1vZGVsZXJzIGhhdmUgdGhyZWUgbGV2 ZWxzIG9mIGNvbmZvcm1hbmNlOgo+IC0gdGhlIGJhc2ljIGJlaGF2aW9yIG9mIHRoZSBtb2RlbAo+ IC0gb3B0aW9uYWwgZmVhdHVyZXMgdGhhdCBhcmUgcGFydCBvZiB0aGUgbW9kZWwKPiAtIGRldmlh dGlvbnMgZnJvbSB0aGUgbW9kZWwKPiAKPiBXZSB3aWxsIGNvbnNpZGVyIGVhY2ggb2YgdGhlc2Ug aW4gc2VxdWVuY2UuCj4gCj4gKioqIEJhc2ljIEJlaGF2aW9yCj4gCj4gVGhlIG1vZGVsIGRlZmlu ZXMgYSBjb250cmFjdCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHNlcnZlciwgd2hpY2gKPiBhbGxv d3MgYm90aCBwYXJ0aWVzIHRvIGhhdmUgZmFpdGggdGhlIG90aGVyIGtub3dzIHRoZSBzeW50YXgg YW5kCj4gc2VtYW50aWNzIGJlaGluZCB0aGUgbW9kZWxlZCBkYXRhLiAgVGhlIHN0cmVuZ3RoIG9m IFlBTkcgbGllcyBpbiB0aGUKPiBzdHJlbmd0aCBvZiB0aGlzIGNvbnRyYWN0IGFuZCB0aGUgbWlu ZGxlc3MgZGV2b3Rpb24gd2l0aCB3aGljaAo+IGltcGxlbWVudGVycyBmb2xsb3cgaXQuCj4gCj4g KioqIE9wdGlvbmFsIEZlYXR1cmVzCj4gCj4gSW4gbWFueSBtb2RlbHMsIHRoZSBtb2RlbGVyIHdp bGwgYWxsb3cgc2VjdGlvbnMgb2YgdGhlIG1vZGVsIHRvIGJlCj4gY29uZGl0aW9uYWwsIGJhc2Vk IG9uIHRoZSBkZXZpY2UuICBUaGUgZGV2aWNlIGNvbnRyb2xzIHdoZXRoZXIgdGhlc2UKPiBjb25k aXRpb25hbCBwb3J0aW9ucyBvZiB0aGUgbW9kZWwgYXJlIHN1cHBvcnRlZCBvciB2YWxpZCBmb3Ig dGhhdAo+IHBhcnRpY3VsYXIgZGV2aWNlLgo+IAo+IEZvciBleGFtcGxlLCBhIHN5c2xvZyBkYXRh IG1vZGVsIG1heSBjaG9vc2UgdG8gaW5jbHVkZSB0aGUgYWJpbGl0eSB0bwo+IHNhdmUgbG9ncyBs b2NhbGx5LCBidXQgdGhlIG1vZGVsZXIgd2lsbCByZWFsaXplIHRoYXQgdGhpcyBpcyBvbmx5Cj4g cG9zc2libGUgaWYgdGhlIGRldmljZSBoYXMgbG9jYWwgc3RvcmFnZS4gIElmIHRoZXJlIGlzIG5v IGxvY2FsCj4gc3RvcmFnZSwgYW4gYXBwbGljYXRpb24gc2hvdWxkIG5vdCB0ZWxsIHRoZSBkZXZp Y2UgdG8gc2F2ZSBsb2dzLgo+IAo+IFlBTkcgc3VwcG9ydHMgdGhpcyBjb25kaXRpb25hbCBtZWNo YW5pc20gdXNpbmcgYSBjb25zdHJ1Y3QgY2FsbGVkCj4gImZlYXR1cmVzIi4gIEEgbW9kdWxlIG1h eSBkZWNsYXJlIGFueSBudW1iZXIgb2YgZmVhdHVyZXMsIGlkZW50aWZpZWQKPiBieSBzaW1wbGUg c3RyaW5ncywgYW5kIG1heSBtYWtlIHBvcnRpb25zIG9mIHRoZSBtb2R1bGUgb3B0aW9uYWwgYmFz ZWQgb24KPiB0aG9zZSBmZWF0dXJlLiAgSWYgdGhlIGRldmljZSBzdXBwb3J0cyBhIGZlYXR1cmUs IHRoZW4gdGhlIGNvcnJlc3BvbmRpbmcKPiBwb3J0aW9ucyBvZiB0aGUgbW9kdWxlIGFyZSB2YWxp ZCBmb3IgdGhhdCBkZXZpY2UuICBJZiB0aGUgZGV2aWNlCj4gZG9lc24ndCBzdXBwb3J0IHRoZSBm ZWF0dXJlLCB0aG9zZSBwYXJ0cyBvZiB0aGUgbW9kdWxlIGFyZSBub3QgdmFsaWQsCj4gYW5kIGFw cGxpY2F0aW9ucyBzaG91bGQgYmVoYXZlIGFjY29yZGluZ2x5Lgo+IAo+IEZlYXR1cmVzIGdpdmUg dGhlIG1vZGVsZXIgYSBtZWNoYW5pc20gZm9yIG1ha2luZyBwb3J0aW9ucyBvZiB0aGUKPiBtb2R1 bGUgY29uZGl0aW9uYWwgaW4gYSBtYW5uZXIgdGhhdCBpcyBjb250cm9sbGVkIGJ5IHRoZSBkZXZp Y2UuICBUaGUKPiBtb2RlbCBjYW4gZXhwcmVzcyBjb25zdHJ1Y3RzIHdoaWNoIGFyZSBub3QgdW5p dmVyc2FsbHkgcHJlc2VudCBpbiBhbGwKPiBkZXZpY2VzLiAgVGhlc2UgZmVhdHVyZXMgYXJlIGlu Y2x1ZGVkIGluIHRoZSBtb2RlbCBkZWZpbml0aW9uLAo+IGFsbG93aW5nIGEgY29uc2lzdGVudCB2 aWV3IGFuZCBhbGxvd2luZyBhcHBsaWNhdGlvbnMgdG8gbGVhcm4gd2hpY2gKPiBmZWF0dXJlcyBh cmUgc3VwcG9ydGVkIGFuZCB0YWlsb3IgdGhlaXIgYmVoYXZpb3IgdG8gdGhlIGRldmljZS4KPiAK PiBGZWF0dXJlcyBhcmUgZGVmaW5lZCB1c2luZyB0aGUgImZlYXR1cmUiIHN0YXRlbWVudC4gIERl ZmluaXRpb25zIGluCj4gdGhlIG1vZHVsZSB0aGF0IGFyZSBjb25kaXRpb25hbCB0byB0aGUgZmVh dHVyZSBhcmUgbm90ZWQgYnkgdGhlCj4gImlmLWZlYXR1cmUiIHN0YXRlbWVudCB3aXRoIHRoZSBu YW1lIG9mIHRoZSBmZWF0dXJlIGFzIGl0cyBhcmd1bWVudC4KPiAKPiBGdXJ0aGVyIGRldGFpbHMg YXJlIGF2YWlsYWJsZSBpbiBeZmVhdHVyZV4uCj4gCj4gKioqIERldmlhdGlvbnMKPiAKPiBJbiBh biBpZGVhbCB3b3JsZCwgYWxsIGRldmljZXMgd291bGQgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50 IHRoZQo+IG1vZGVsIGV4YWN0bHkgYXMgZGVmaW5lZCwgYW5kIGRldmlhdGlvbnMgZnJvbSB0aGUg bW9kZWwgd291bGQgbm90IGJlCj4gYWxsb3dlZC4gIEJ1dCBpbiB0aGUgcmVhbCB3b3JsZCwgZGV2 aWNlcyBhcmUgb2Z0ZW4gbm90IGFibGUgb3IKPiB3aWxsaW5nIHRvIGltcGxlbWVudCB0aGUgbW9k ZWwgYXMgd3JpdHRlbi4gIEZvciBZQU5HLWJhc2VkCj4gYXV0b21hdGlvbiB0byBkZWFsIHdpdGgg dGhlc2UgZGV2aWNlIGRldmlhdGlvbnMsIGEgbWVjaGFuaXNtIG11c3QKPiBleGlzdCBmb3IgZGV2 aWNlcyB0byBpbmZvcm0gYXBwbGljYXRpb25zIG9mIHRoZSBzcGVjaWZpY3Mgb2Ygc3VjaAo+IGRl dmlhdGlvbnMuCj4gCj4gRm9yIGV4YW1wbGUsIGEgQkdQIG1vZHVsZSBtYXkgYWxsb3cgYW55IG51 bWJlciBvZiBCR1AgcGVlcnMsIGJ1dCBhCj4gcGFydGljdWxhciBkZXZpY2UgbWF5IG9ubHkgc3Vw cG9ydCAxNiBCR1AgcGVlcnMuICBBbnkgYXBwbGljYXRpb24KPiBjb25maWd1cmluZyB0aGUgMTd0 aCBwZWVyIHdpbGwgcmVjZWl2ZSBhbiBlcnJvci4gIFdoaWxlIGFuIGVycm9yIG1heQo+IHN1ZmZp Y2UgdG8gbGV0IHRoZSBhcHBsaWNhdGlvbiBrbm93IGl0IGNhbm5vdCBhZGQgYW5vdGhlciBwZWVy LCBpdAo+IHdvdWxkIGJlIGZhciBiZXR0ZXIgaWYgdGhlIGFwcGxpY2F0aW9uIGhhZCBwcmlvciBr bm93bGVkZ2Ugb2YgdGhpcwo+IGxpbWl0YXRpb24gYW5kIGNvdWxkIHByZXZlbnQgdGhlIHVzZXIg ZnJvbSBzdGFydGluZyBkb3duIHRoZSBwYXRoIHRoYXQKPiBjb3VsZCBub3Qgc3VjY2VlZC4KPiAK PiBEZXZpY2UgZGV2aWF0aW9ucyBhcmUgZGVjbGFyZWQgdXNpbmcgdGhlICJkZXZpYXRpb24iIHN0 YXRlbWVudCwgd2hpY2gKPiB0YWtlcyBhcyBpdHMgYXJndW1lbnQgYSBzdHJpbmcgd2hpY2ggaWRl bnRpZmllcyBhIG5vZGUgaW4gdGhlIHNjaGVtYSB0cmVlLgo+IFRoZSBjb250ZW50cyBvZiB0aGUg c3RhdGVtZW50IGRldGFpbHMgdGhlIG1hbm5lciBpbiB3aGljaCB0aGUgZGV2aWNlCj4gaW1wbGVt ZW50YXRpb24gZGV2aWF0ZXMgZnJvbSB0aGUgY29udHJhY3QgYXMgZGVmaW5lZCBpbiB0aGUgbW9k dWxlLgo+IAo+ICoqKiBBbm5vdW5jaW5nIENvbmZvcm1hbmNlIEluZm9ybWF0aW9uIGluIHRoZSA8 aGVsbG8+IE1lc3NhZ2UKPiAKPiBEZXZpY2VzIGluZGljYXRlIHRoZSBuYW1lcyBvZiBzdXBwb3J0 ZWQgZmVhdHVyZXMgYW5kIGRldmljZSBkZXZpYXRpb25zCj4gdmlhIHRoZSA8aGVsbG8+IG1lc3Nh Z2UuICBJbiBoZWxsbyBtZXNzYWdlcywgdGhlIGZlYXR1cmVzIGFyZSBlbmNvZGVkCj4gaW4gdGhl ICJmZWF0dXJlcyIgcGFyYW1ldGVyIHdpdGhpbiB0aGUgVVJJLiAgVGhlIHZhbHVlIG9mIHRoaXMK PiBwYXJhbWV0ZXIgaXMgYSBjb21tYS1zZXBhcmF0ZWQgbGlzdCBvZiBmZWF0dXJlIG5hbWVzIHdo aWNoIHRoZSBkZXZpY2UKPiBzdXBwb3J0cyBmb3IgdGhlIHNwZWNpZmljIG1vZHVsZS4KPiAKPiAg ICAgPGhlbGxvPgo+ICAgICAgIDxjYXBhYmlsaXR5Pgo+ICAgICAgICAgaHR0cDovL2V4YW1wbGUu Y29tL21vZC9tY3A/ZmVhdHVyZXM9ZmVhdDEmbW9kdWxlPW1jcAo+ICAgICAgIDwvY2FwYWJpbGl0 eT4KPiAgICAgICA8Y2FwYWJpbGl0eT4KPiAgICAgICAgIGh0dHA6Ly9leGFtcGxlLmNvbS9tb2Qv c29tZT9tb2R1bGU9c29tZSZmZWF0dXJlcz1vbmUsdHdvLHRocmVlCj4gICAgICAgPC9jYXBhYmls aXR5Pgo+ICAgICA8L2hlbGxvPgo+IAo+IERldmljZSBkZXZpYXRpb25zIGFyZSBhbm5vdW5jZWQg dmlhIHRoZSAiZGV2aWF0aW9ucyIgcGFyYW1ldGVyLgo+IFRoZSB2YWx1ZSBvZiB0aGUgZGV2aWF0 aW9ucyBwYXJhbWV0ZXIgaXMgYSBjb21tYS1zZXBhcmF0ZWQgbGlzdCBvZgo+IG1vZHVsZXMgY29u dGFpbmluZyBkZXZpYXRpb25zIGZyb20gdGhlIGNhcGFiaWxpdHkncyBtb2R1bGUuCj4gCj4gICAg IDxoZWxsbz4KPiAgICAgICA8Y2FwYWJpbGl0eT4KPiAgICAgICAgIGh0dHA6Ly9leGFtcGxlLmNv bS9hYmM/ZGV2aWF0aW9ucz1teS1kZXZzCj4gICAgICAgPC9jYXBhYmlsaXR5Pgo+ICAgICA8L2hl bGxvPgo+IAo+IAo+IAo+ICoqIENvbmZvcm1hbmNlLXJlbGF0ZWQgU3RhdGVtZW50cyBAY29uZm9y bWFuY2Utc3RtdHNACj4gCj4gVGhpcyBzZWN0aW9uIGRlZmluZXMgc3RhdGVtZW50cyByZWxhdGVk IHRvIGNvbmZvcm1hbmNlLCBhcyBkZXNjcmliZWQKPiBpbiBeY29uZm9ybWFuY2VeLgo+IAo+ICoq KiBUaGUgZmVhdHVyZSBTdGF0ZW1lbnQgQGZlYXR1cmVACj4gCj4gVGhlICJmZWF0dXJlIiBzdGF0 ZW1lbnQgaXMgdXNlZCB0byBkZWZpbmUgYSBtZWNoYW5pc20gYnkgd2hpY2gKPiBwb3J0aW9ucyBv ZiB0aGUgc2NoZW1hIGFyZSBtYXJrZWQgYXMgY29uZGl0aW9uYWwuICBBIGZlYXR1cmUgbmFtZSBp cwo+IGRlZmluZWQgdGhhdCBjYW4gbGF0ZXIgYmUgcmVmZXJlbmNlZCB1c2luZyB0aGUgImlmLWZl YXR1cmUiIHN0YXRlbWVudAo+IChzZWUgXmlmLWZlYXR1cmVeKS4gIFNjaGVtYSBub2RlcyB0YWdn ZWQgd2l0aCBhIGZlYXR1cmUgYXJlIGlnbm9yZWQKPiB1bmxlc3MgdGhlIGRldmljZSBzdXBwb3J0 cyB0aGUgZ2l2ZW4gZmVhdHVyZS4gIFRoaXMgYWxsb3dzIHBvcnRpb25zIG9mCj4gdGhlIFlBTkcg bW9kdWxlIHRvIGJlIGNvbmRpdGlvbmFsIGJhc2VkIG9uIGNvbmRpdGlvbnMgb24gdGhlIGRldmlj ZS4KPiBUaGUgbW9kZWwgY2FuIHJlcHJlc2VudCB0aGUgYWJpbGl0aWVzIG9mIHRoZSBkZXZpY2Ug d2l0aGluIHRoZSBtb2RlbCwKPiBnaXZpbmcgYSByaWNoZXIgbW9kZWwgdGhhdCBhbGxvd3MgZm9y IGRpZmZlcmluZyBkZXZpY2UgYWJpbGl0aWVzIGFuZAo+IHJvbGVzLiAKPiAKPiBUaGUgYXJndW1l bnQgdG8gdGhlICJmZWF0dXJlIiBzdGF0ZW1lbnQgaXMgdGhlIG5hbWUgb2YgdGhlIG5ldwo+IGZl YXR1cmUsIGFuZCBmb2xsb3dzIHRoZSBydWxlcyBmb3IgaWRlbnRpZmllcnMgaW4gXmlkZW50aWZp ZXJzXi4gIFRoaXMKPiBuYW1lIGlzIHVzZWQgYnkgdGhlICJpZi1mZWF0dXJlIiBzdGF0ZW1lbnQg dG8gdGllIHRoZSBzY2hlbWEgbm9kZXMgdG8KPiB0aGUgZmVhdHVyZS4KPiAKPiBJbiB0aGlzIGV4 YW1wbGUsIGEgZmVhdHVyZSBjYWxsZWQgImxvY2FsLXN0b3JhZ2UiIHJlcHJlc2VudHMgdGhlCj4g YWJpbGl0eSBmb3IgYSBkZXZpY2UgdG8gc3RvcmUgc3lzbG9nIG1lc3NhZ2VzIG9uIGxvY2FsIHN0 b3JhZ2Ugb2Ygc29tZQo+IHNvcnQuICBUaGlzIGZlYXR1cmUgaXMgdXNlZCB0byBtYWtlIHRoZSAi bG9jYWwtc3RvcmFnZS1saW1pdCIgbGVhZgo+IGNvbmRpdGlvbmFsIG9uIHRoZSBwcmVzZW5jZSBv ZiBzb21lIHNvcnQgb2YgbG9jYWwtc3RvcmFnZS4gIElmIHRoZQo+IGRldmljZSBkb2VzIG5vdCBy ZXBvcnQgdGhhdCBpdCBzdXBwb3J0cyB0aGlzIGZlYXR1cmUsIHRoZQo+IGxvY2FsLXN0b3JhZ2Ut bGltaXQgbm9kZSBpcyBub3Qgc3VwcG9ydGVkLgo+IAo+ICAgICBtb2R1bGUgbXktc3lzbG9nIHsK PiAgICAgICAgIC4uLgo+ICAgICAgICAgZmVhdHVyZSBsb2NhbC1zdG9yYWdlIHsKPiAgICAgICAg ICAgICBkZXNjcmlwdGlvbiAiVGhpcyBmZWF0dXJlIG1lYW5zIHRoZSBkZXZpY2Ugc3VwcG9ydHMg bG9jYWwKPiAgICAgICAgICAgICAgICAgc3RvcmFnZSAobWVtb3J5LCBmbGFzaCBvciBkaXNrKSB0 aGF0IGNhbiBiZSB1c2VkIHRvCj4gICAgICAgICAgICAgICAgIHN0b3JlIHN5c2xvZyBtZXNzYWdl cy4iOwo+ICAgICAgICAgfQo+IAo+ICAgICAgICAgY29udGFpbmVyIHN5c2xvZyB7Cj4gICAgICAg ICAgICAgbGVhZiBsb2NhbC1zdG9yYWdlLWxpbWl0IHsKPiAgICAgICAgICAgICAgICAgaWYtZmVh dHVyZSBsb2NhbC1zdG9yYWdlOwo+ICAgICAgICAgICAgICAgICBjb25maWcgZmFsc2U7Cj4gICAg ICAgICAgICAgICAgIGRlc2NyaXB0aW9uICJUaGUgYW1vdW50IG9mIGxvY2FsIHN0b3JhZ2UgdGhh dCBjYW4gYmUKPiAgICAgICAgICAgICAgICAgICAgIHVzZWQgdG8gaG9sZCBzeXNsb2cgbWVzc2Fn ZXMuIjsKPiAgICAgICAgICAgICB9Cj4gICAgICAgICB9Cj4gICAgIH0KPiAKPiBUaGUgImlmLWZl YXR1cmUiIHN0YXRlbWVudCBjYW4gYmUgdXNlZCBpbiBtYW55IHBsYWNlcyB3aXRoaW4gdGhlIFlB TkcKPiBzeW50YXguICBEZWZpbml0aW9ucyB0YWdnZWQgd2l0aCAiaWYtZmVhdHVyZSIgYXJlIGln bm9yZWQgd2hlbiB0aGUKPiBkZXZpY2UgZG9lcyBub3Qgc3VwcG9ydCB0aGF0IGZlYXR1cmUuCj4g Cj4gSW4gdGhpcyBleGFtcGxlLCBhIHR5cGUgZGVmaW5pdGlvbiBpcyBidWlsdCBiYXNlZCBvbiBm ZWF0dXJlcy4gIElmIHRoZQo+IGZlYXR1cmUgInY0LXN1cHBvcnQiIGlzIHByZXNlbnQsIHRoZSBh cHBsaWNhdGlvbiBjYW4ga25vdyB0aGF0IHRoZQo+IGRldmljZSB3aWxsIGluY2x1ZGUgc3VwcG9y dCBmb3IgYWRkcmVzc2VzIGluIHRoZSBJUHY0IG5vdGF0aW9uLCBhbmQgaWYKPiB0aGUgInY2LXN1 cHBvcnQiIGZlYXR1cmUgaXMgcHJlc2VudCwgaXQgY2FuIGtub3cgdGhlcmUgaXMgc3VwcG9ydCBm b3IKPiBJUHY2IGFkZHJlc3Nlcy4KPiAKPiAgICAgdHlwZWRlZiBwZWVyLWFkZHJlc3Mgewo+ICAg ICAgICAgZGVzY3JpcHRpb24gIkFkZHJlc3Mgb2YgYSBwZWVyIjsKPiAgICAgICAgIHR5cGUgdW5p b24gewo+ICAgICAgICAgICAgIHR5cGUgaW5ldDppcHY0YWRkcmVzcyB7IGlmLWZlYXR1cmUgdjQt c3VwcG9ydDsgfQo+ICAgICAgICAgICAgIHR5cGUgaW5ldDppcHY2YWRkcmVzcyB7IGlmLWZlYXR1 cmUgdjYtc3VwcG9ydDsgfQo+ICAgICAgICAgfQo+ICAgICB9Cj4gCj4gKioqKiBUaGUgZmVhdHVy ZSdzIFN1YnN0YXRlbWVudHMKPiAKPiAhISB0YWJsZQo+ICEhIGhlYWQgISBzdWJzdGF0ZW1lbnQg ICAgICAhIHNlY3Rpb24gICAgICAgICAgICAgISBjYXJkaW5hbGl0eQo+ICEhIHJvdyAgISBkZXNj cmlwdGlvbiAgICAgICAhIF5kZXNjcmlwdGlvbl4gICAgICAgISAwLi4xCj4gISEgcm93ICAhIGlm LWZlYXR1cmUgICAgICAgICEgXmlmLWZlYXR1cmVeICAgICAgICAhIDAuLm4KPiAhISByb3cgICEg c3RhdHVzICAgICAgICAgICAgISBec3RhdHVzXiAgICAgICAgICAgICEgMC4uMQo+ICEhIHJvdyAg ISByZWZlcmVuY2UgICAgICAgICAhIF5yZWZlcmVuY2VeICAgICAgICAgISAwLi4xCj4gCj4gKioq IFRoZSBpZi1mZWF0dXJlIFN0YXRlbWVudCBAaWYtZmVhdHVyZUAKPiAKPiBUaGUgImlmLWZlYXR1 cmUiIHN0YXRlbWVudCBpcyB1c2VkIHRvIG1hcmsgcG9ydGlvbnMgb2YgdGhlIG1vZGVsIGFzCj4g Y29uZGl0aW9uYWwuICBUaGUgYXJndW1lbnQgaXMgdGhlIG5hbWUgb2YgYSBmZWF0dXJlLCBhcyBk ZWZpbmVkIGJ5IGEKPiAiZmVhdHVyZSIgc3RhdGVtZW50LiAgSWYgYSBwcmVmaXggaXMgcHJlc2Vu dCBvbiB0aGUgZmVhdHVyZSBuYW1lLCBpdAo+IHJlZmVycyB0byBhIGZlYXR1cmUgZGVmaW5lZCB0 aGUgbW9kdWxlIHdoaWNoIHdhcyBpbXBvcnRlZCB3aXRoIHRoYXQKPiBwcmVmaXguICBPdGhlcndp c2UgYSBmZWF0dXJlIHdpdGggdGhlIG1hdGNoaW5nIG5hbWUgbXVzdCBiZSBkZWZpbmVkIGluCj4g dGhlIGN1cnJlbnQgbW9kdWxlIG9yIGFuIGluY2x1ZGVkIHN1Ym1vZHVsZS4KPiAKPiBTaW5jZSBz dWJtb2R1bGVzIGNhbm5vdCBpbmNsdWRlIHRoZSBwYXJlbnQgbW9kdWxlLCBhbnkgZmVhdHVyZXMg aW4gdGhlCj4gbW9kdWxlIHdoaWNoIG5lZWQgdG8gYmUgZXhwb3NlZCB0byBzdWJtb2R1bGVzIG11 c3QgYmUgZGVmaW5lZCBpbiBhCj4gc3VibW9kdWxlLiAgU3VibW9kdWxlcyBjYW4gdGhlbiBpbmNs dWRlIHRoaXMgc3VibW9kdWxlIHRvIGZpbmQgdGhlCj4gZGVmaW5pdGlvbiBvZiB0aGUgZmVhdHVy ZS4KPiAKPiAqKiogVGhlIGRldmlhdGlvbiBTdGF0ZW1lbnQgQGRldmlhdGlvbkAKPiAKPiBUaGUg ZGV2aWF0aW9uIHN0YXRlbWVudCBkZWZpbmVzIGEgaGllcmFyY2h5IG9mIHRoZSBtb2R1bGUgd2hp Y2ggdGhlCj4gZGV2aWNlIGRvZXMgbm90IGltcGxlbWVudCBmYWl0aGZ1bGx5LiAgVGhlIGFyZ3Vt ZW50IGlzIGEgc3RyaW5nIHRoYXQKPiBpZGVudGlmaWVzIHRoZSBub2RlIGluIHRoZSBzY2hlbWEg dHJlZSB3aGVyZSBhIGRldmlhdGlvbiBmcm9tIHRoZQo+IG1vZHVsZSBvY2N1cnMuICBUaGlzIG5v ZGUgaXMgY2FsbGVkIHRoZSBkZXZpYXRpb24ncwo+IHRhcmdldCBub2RlLiAgVGhlIGNvbnRlbnRz IG9mIHRoZSBkZXZpYXRpb24gc3RhdGVtZW50IGdpdmUgZGV0YWlscwo+IGFib3V0IHRoZSBkZXZp YXRpb24uCj4gCj4gVGhlIGFyZ3VtZW50J3Mgc3ludGF4IGlzIGZvcm1hbGx5IGRlZmluZWQgYnkg dGhlIHJ1bGUgImRldmlhdGlvbi1hcmciCj4gaW4gXmdyYW1tYXJeLgo+IAo+IERldmlhdGlvbnMg ZGVmaW5lIHRoZSB3YXkgYSBkZXZpY2Ugb3IgY2xhc3Mgb2YgZGV2aWNlcyBkZXZpYXRlIGZyb20K PiB0aGUgc3RhbmRhcmQuICBUaGlzIG1lYW5zIHRoYXQgZGV2aWF0aW9ucyBNVVNUIG5ldmVyIGJl IHBhcnQgb2YgYQo+IHB1Ymxpc2hlZCBzdGFuZGFyZCwgc2luY2UgdGhleSBhcmUgdGhlIG1lY2hh bmlzbSBmb3IgbGVhcm5pbmcgaG93Cj4gaW1wbGVtZW50YXRpb25zIHZhcnkgZnJvbSB0aGUgc3Rh bmRhcmRzLgo+IAo+IERldmljZSBkZXZpYXRpb25zIGFyZSBzdHJvbmdseSBkaXNjb3VyYWdlZCBh bmQgc2hvdWxkIG9ubHkgYmUgdXNlZCBhcwo+IGEgbGFzdCByZXNvcnQuICBUZWxsaW5nIHRoZSBh cHBsaWNhdGlvbiBob3cgYSBkZXZpY2UgZmFpbHMgdG8gZm9sbG93Cj4gdGhlIHN0YW5kYXJkIGlz IG5vIHN1YnN0aXR1dGUgZm9yIGltcGxlbWVudGluZyB0aGUgc3RhbmRhcmQgZGlyZWN0bHkuCj4g Cj4gSG93ZXZlciBpbiBtYW55IGNhc2VzIHRoZSBjb3N0IG9mIGZvbGxvd2luZyB0aGUgc3RhbmRh cmQgaXMgaGVhdnkgYW5kCj4gdGhlIHBheW9mZiBtYXkgYmUgc21hbGwuICBBIHBhcnRpY3VsYXIg ZGV2aWNlIG1heSBub3QgaGF2ZSB0aGUKPiBoYXJkd2FyZSBvciBzb2Z0d2FyZSBhYmlsaXR5IHRv IHN1cHBvcnQgcGFydHMgb2YgYSBzdGFuZGFyZCBtb2R1bGUuCj4gV2hlbiB0aGlzIG9jY3Vycywg dGhlIGRldmljZSBtYWtlcyBhIGNob2ljZSB0byB0cmVhdCBhdHRlbXB0cyB0bwo+IGNvbmZpZ3Vy ZSB1bnN1cHBvcnRlZCBwYXJ0cyBvZiB0aGUgbW9kdWxlIGFzIGVpdGhlciBhbiBlcnJvciB0aGF0 IGlzCj4gcmVwb3J0ZWQgYmFjayB0byB0aGUgdW5zdXNwZWN0aW5nIGFwcGxpY2F0aW9uLCBvciBp Z25vcmUgdGhhdCBpbmNvbWluZwo+IHJlcXVlc3RzLiAgTmVpdGhlciBjaG9pY2UgaXMgYWNjZXB0 YWJsZS4KPiAKPiBJbnN0ZWFkLCBZQU5HIGFsbG93cyBkZXZpY2VzIHRvIGRvY3VtZW50IHBvcnRp b25zIG9mIHRoZSBiYXNlIG1vZHVsZQo+IHdoaWNoIGFyZSBub3Qgc3VwcG9ydGVkIG9yIHN1cHBv cnRlZCBidXQgd2l0aCBkaWZmZXJlbnQgc3ludGF4LCBieQo+IHVzaW5nIHRoZSAiZGV2aWF0aW9u IiBzdGF0ZW1lbnQuCj4gCj4gKioqKiBUaGUgZGV2aWF0aW9uJ3MgU3Vic3RhdGVtZW50cwo+IAo+ ICEhIHRhYmxlCj4gISEgaGVhZCAhIHN1YnN0YXRlbWVudCAgICAgICEgc2VjdGlvbiAgICAgICAg ICAgICAhIGNhcmRpbmFsaXR5Cj4gISEgcm93ICAhIGRlc2NyaXB0aW9uICAgICAgICEgXmRlc2Ny aXB0aW9uXiAgICAgICAhIDAuLjEKPiAhISByb3cgICEgZGV2aWF0ZSAgICAgICAgICAgISBeZGV2 aWF0ZV4gICAgICAgICAgICEgMC4ubgo+ICEhIHJvdyAgISByZWZlcmVuY2UgICAgICAgICAhIF5y ZWZlcmVuY2VeICAgICAgICAgISAwLi4xCj4gCj4gKioqKiBUaGUgZGV2aWF0ZSBTdGF0ZW1lbnQg QGRldmlhdGVACj4gCj4gVGhlICJkZXZpYXRlIiBzdGF0ZW1lbnQgZGVmaW5lcyBob3cgdGhlIGRl dmljZSdzIGltcGxlbWVudGF0aW9uIG9mIHRoZQo+IHRhcmdldCBub2RlIGRldmlhdGVzIGZyb20g aXRzIG9yaWdpbmFsIGRlZmluaXRpb24uICBUaGUgYXJndW1lbnQgaXMKPiBvbmUgb2YgdGhlIHN0 cmluZ3MgIm5vdC1zdXBwb3J0ZWQiLCAiYWRkIiwgInJlcGxhY2UiLCBvciAiZGVsZXRlIi4KPiAK PiBUaGUgYXJndW1lbnQgIm5vdC1zdXBwb3J0ZWQiIGluZGljYXRlcyB0aGF0IHRoZSB0YXJnZXQg bm9kZSBpcyBub3QKPiBpbXBsZW1lbnRlZCBieSB0aGlzIGRldmljZS4KPiAKPiBUaGUgYXJndW1l bnQgImFkZCIgYWRkcyBwcm9wZXJ0aWVzIHRvIHRoZSB0YXJnZXQgbm9kZS4gIFRoZSBwcm9wZXJ0 aWVzCj4gdG8gYWRkIGFyZSBpZGVudGlmaWVkIGFzIGEgc3Vic3RhdGVtZW50IHRvIHRoZSAiZGV2 aWF0ZSIgc3RhdGVtZW50Lgo+IElmIHRoZSBwcm9wZXJ0eSBjYW4gb25seSBhcHBlYXIgb25jZSwg dGhlIHByb3BlcnR5IE1VU1QgTk9UIGV4aXN0IGluCj4gdGhlIHRhcmdldCBub2RlLgo+IAo+IFRo ZSBhcmd1bWVudCAicmVwbGFjZSIgcmVwbGFjZXMgcHJvcGVydGllcyBvZiB0aGUgdGFyZ2V0IG5v ZGUuICBUaGUKPiBwcm9wZXJ0aWVzIHRvIHJlcGxhY2UgYXJlIGlkZW50aWZpZWQgYnkgc3Vic3Rh dGVtZW50cyB0byB0aGUgImRldmlhdGUiCj4gc3RhdGVtZW50LiAgVGhlIHByb3BlcnR5IHRvIHJl cGxhY2UgTVVTVCBOT1QgZXhpc3QgaW4gdGhlIHRhcmdldCBub2RlLgo+IAo+IFRoZSBhcmd1bWVu dCAiZGVsZXRlIiBkZWxldGVzIHByb3BlcnRpZXMgZnJvbSB0aGUgdGFyZ2V0IG5vZGUuICBUaGUK PiBwcm9wZXJ0aWVzIHRvIGRlbGV0ZSBhcmUgaWRlbnRpZmllZCBieSBzdWJzdGF0ZW1lbnQgdG8g ImRlbGV0ZSIuICBUaGUKPiBzdWJzdGF0ZW1lbnQncyBrZXl3b3JkIE1VU1QgbWF0Y2ggYSBjb3Jy ZXNwb25kaW5nIGtleXdvcmQgaW4gdGhlCj4gdGFyZ2V0IG5vZGUsIGFuZCB0aGUgYXJndW1lbnQn cyBzdHJpbmcgTVVTVCBiZSBlcXVhbCB0byB0aGUKPiBjb3JyZXNwb25kaW5nIGtleXdvcmQncyBh cmd1bWVudCBzdHJpbmcgaW4gdGhlIHRhcmdldCBub2RlLgo+IAo+ICEhIHRhYmxlIFRoZSBkZXZp YXRlcydzIFN1YnN0YXRlbWVudHMKPiAhISBoZWFkICEgc3Vic3RhdGVtZW50ICAgICAgISBzZWN0 aW9uICAgICAgICAgICAgICEgY2FyZGluYWxpdHkKPiAhISByb3cgICEgY29uZmlnICAgICAgICAg ICAgISBeY29uZmlnXiAgICAgICAgICAgICEgMC4uMQo+ICEhIHJvdyAgISBkZWZhdWx0ICAgICAg ICAgICAhIF5sZWFmLWRlZmF1bHReICAgICAgISAwLi4xCj4gISEgcm93ICAhIG1hbmRhdG9yeSAg ICAgICAgICEgXm1hbmRhdG9yeV4gICAgICAgICAhIDAuLjEKPiAhISByb3cgICEgbWF4LWVsZW1l bnRzICAgICAgISBebWF4LWVsZW1lbnRzXiAgICAgICEgMC4uMQo+ICEhIHJvdyAgISBtaW4tZWxl bWVudHMgICAgICAhIF5taW4tZWxlbWVudHNeICAgICAgISAwLi4xCj4gISEgcm93ICAhIG11c3Qg ICAgICAgICAgICAgICEgXm11c3ReICAgICAgICAgICAgICAhIDAuLm4KPiAhISByb3cgICEgdHlw ZSAgICAgICAgICAgICAgISBedHlwZV4gICAgICAgICAgICAgICEgMC4uMQo+ICEhIHJvdyAgISB1 bmlxdWUgICAgICAgICAgICAhIF51bmlxdWVeICAgICAgICAgICAgISAwLi5uCj4gISEgcm93ICAh IHVuaXRzICAgICAgICAgICAgICEgXnVuaXRzXiAgICAgICAgICAgICAhIDAuLjEKPiAKPiAqKioq IFVzYWdlIEV4YW1wbGUKPiAKPiBJbiB0aGlzIGV4YW1wbGUsIHRoZSBkZXZpY2UgaXMgaW5mb3Jt aW5nIGNsaWVudCBhcHBsaWNhdGlvbnMgdGhhdCBpdAo+IGRvZXMgbm90IHN1cHBvcnQgdGhlIG9s ZCBSRkM4Njctc3R5bGUgImRheXRpbWUiIHNlcnZpY2UuCj4gCj4gICAgIGRldmlhdGlvbiAvYmFz ZTpzeXN0ZW0vYmFzZTpkYXl0aW1lIHsKPiAgICAgICAgIGRldmlhdGUgbm90LXN1cHBvcnRlZDsK PiAgICAgfQo+IAo+IFRoZSBmb2xsb3dpbmcgZXhhbXBsZSBzZXRzIGEgZGV2aWNlLXNwZWNpZmlj IGRlZmF1bHQgdmFsdWUgdG8gYSBsZWFmCj4gdGhhdCBkb2VzIG5vdCBoYXZlIGEgZGVmYXVsdCB2 YWx1ZSBkZWZpbmVkOgo+IAo+ICAgZGV2aWF0aW9uIC9iYXNlOnN5c3RlbS9iYXNlOnVzZXIvYmFz ZTp0eXBlIHsKPiAgICAgICBkZXZpYXRlIGFkZCB7Cj4gICAgICAgICAgIGRlZmF1bHQgImFkbWlu IjsgLy8gbmV3IHVzZXJzIGFyZSAnYWRtaW4nIGJ5IGRlZmF1bHQKPiAgICAgICB9Cj4gICB9Cj4g Cj4gSW4gdGhpcyBleGFtcGxlLCB0aGUgZGV2aWNlIGxpbWl0cyB0aGUgbnVtYmVyIG9mIG5hbWUg c2VydmVycyB0byAzOgo+IAo+ICAgICBkZXZpYXRpb24gL2Jhc2U6c3lzdGVtL2Jhc2U6bmFtZS1z ZXJ2ZXIgewo+ICAgICAgICAgZGV2aWF0ZSByZXBsYWNlIHsKPiAgICAgICAgICAgICBtYXgtZWxl bWVudHMgMzsKPiAgICAgICAgIH0KPiAgICAgfQo+IAo+IElmIHRoZSBvcmlnaW5hbCBkZWZpbml0 aW9uIGlzOgo+IAo+ICAgY29udGFpbmVyIHN5c3RlbSB7Cj4gICAgICAgbXVzdCAiZGF5dGltZSBv ciB0aW1lIjsKPiAgICAgICAuLi4KPiAgIH0KPiAKPiBhIGRldmljZSBtaWdodCByZW1vdmUgdGhp cyBtdXN0IGNvbnN0cmFpbnQgYnkgZG9pbmc6Cj4gCj4gICBkZXZpYXRpb24gIi9iYXNlOnN5c3Rl bSIgewo+ICAgICAgIGRldmlhdGUgZGVsZXRlIHsKPiAgICAgICAgICAgbXVzdCAiZGF5dGltZSBv ciB0aW1lIjsKPiAgICAgICB9Cj4gICB9Cj4gCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KPiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4gbmV0bW9kQGll dGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QKLS0g CkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0 Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZAo= From netmod-bounces@ietf.org Sat Oct 4 00:36: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 5FA9028C1CB; Sat, 4 Oct 2008 00:36: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 20A0628C1CB for ; Sat, 4 Oct 2008 00:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=0.201, 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 Jd8fTXWETZZg for ; Sat, 4 Oct 2008 00:36: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 49F8628C1AF for ; Sat, 4 Oct 2008 00:36:23 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id B1DA976C4E5; Sat, 4 Oct 2008 09:36:52 +0200 (CEST) Date: Sat, 04 Oct 2008 09:36:47 +0200 (CEST) Message-Id: <20081004.093647.142220504.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48E6F0FD.5070008@netconfcentral.com> References: <200810040301.m9431dLh016060@idle.juniper.net> <48E6F0FD.5070008@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] 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 Andy Bierman wrote: > Even if this work is pursued in the IETF, then this sort of meta-data > needs to be specified in separate files from the data model > definition. Maintaining vendor-specific standard variance > in the data model file is not going to work. By just adding the deviation statement to our normal module framwork, we keep things simple. No need to invent some other kind of language, or top-level keyword, and rules for how this would work. Obviously, you will never find deviation statements in standard data data modules. But if a vendor writes a module for how it augments a standard module, it can choose to put deviation stataments in the same module. > It is easy to > decouple the data model variance language from the > data modeling language. There is no reason at all > that YANG 1.0 would need to reference the other document, > or any reason to change it in order to specify a companion > DM variance language. If we did this, what should be said about conformance in the main document? How can we write the text so that it allows some other document in the future to add deviations? Should we be silent on the issue, or should we say that in order to claim conformance to a module you MUST implement everything exactly as written? Or maybe that you MAY implement everything exactly as written? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Oct 4 00:41:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FCF43A6A08; Sat, 4 Oct 2008 00:41: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 180163A69D0 for ; Sat, 4 Oct 2008 00:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.181, 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 2P3zSixmjzcc for ; Sat, 4 Oct 2008 00:41: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 A9D7B3A69FF for ; Sat, 4 Oct 2008 00:40:27 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id EAC7F76C4EA; Sat, 4 Oct 2008 09:40:57 +0200 (CEST) Date: Sat, 04 Oct 2008 09:40:55 +0200 (CEST) Message-Id: <20081004.094055.231786801.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1223103308.8412.20.camel@missotis> References: <20081003.085450.158213844.mbj@tail-f.com> <1223103308.8412.20.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] 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 Ladislav Lhotka wrote: > Hi, > > 1. Could the functionality of "non-local" top-level augment perhaps be > moved under "deviation"?. It has the same purpose, if I understand it > correctly. Not really. Top-level augment adds new definitions to an existing hierarchy. This is normal and good. But deviations are strongly discouraged, since they specifiy how you break the contract defined in a standard module. > 2. The example > > deviation "/base:system" { deviate delete { must "daytime or time"; } } > > again raises the question whether the identification of the node > addressed by the deviation is based on matching in the lexical or value > space. The idea is that in order to identify statements in the "deviate delete", the identification is done in the lexical space. Anything else would be too complicated, as shown in your examples. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Oct 4 00:52: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 2CCF83A67AF; Sat, 4 Oct 2008 00:52: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 569F03A6861 for ; Sat, 4 Oct 2008 00:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.146 X-Spam-Level: X-Spam-Status: No, score=-0.146 tagged_above=-999 required=5 tests=[AWL=-0.385, 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 LDtjHC+veDei for ; Sat, 4 Oct 2008 00:52:14 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 74ADB3A67AF for ; Sat, 4 Oct 2008 00:52:14 -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 98347D800BD; Sat, 4 Oct 2008 09:52:44 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20081004.094055.231786801.mbj@tail-f.com> References: <20081003.085450.158213844.mbj@tail-f.com> <1223103308.8412.20.camel@missotis> <20081004.094055.231786801.mbj@tail-f.com> Organization: CESNET Date: Sat, 04 Oct 2008 09:52:44 +0200 Message-Id: <1223106764.8412.28.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] 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="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTbyAwNC4gMTAuIDIwMDggdiAwOTo0MCArMDIwMDoK PiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBjZXNuZXQuY3o+IHdyb3RlOgo+ID4gSGksCj4gPiAK PiA+IDEuIENvdWxkIHRoZSBmdW5jdGlvbmFsaXR5IG9mICJub24tbG9jYWwiIHRvcC1sZXZlbCBh dWdtZW50IHBlcmhhcHMgYmUKPiA+IG1vdmVkIHVuZGVyICJkZXZpYXRpb24iPy4gSXQgaGFzIHRo ZSBzYW1lIHB1cnBvc2UsIGlmIEkgdW5kZXJzdGFuZCBpdAo+ID4gY29ycmVjdGx5Lgo+IAo+IE5v dCByZWFsbHkuICBUb3AtbGV2ZWwgYXVnbWVudCBhZGRzIG5ldyBkZWZpbml0aW9ucyB0byBhbiBl eGlzdGluZwo+IGhpZXJhcmNoeS4gIFRoaXMgaXMgbm9ybWFsIGFuZCBnb29kLgo+IAo+IEJ1dCBk ZXZpYXRpb25zIGFyZSBzdHJvbmdseSBkaXNjb3VyYWdlZCwgc2luY2UgdGhleSBzcGVjaWZpeSBo b3cgeW91Cj4gYnJlYWsgdGhlIGNvbnRyYWN0IGRlZmluZWQgaW4gYSBzdGFuZGFyZCBtb2R1bGUu CgpCdXQgaW4gZmFjdCB0aGUgZWZmZWN0IGlzIHRoZSBzYW1lIC0gY2hhbmdlIGluIGEgZm9yZWln biBtb2R1bGUuIEkKYWN0dWFsbHkgbGlrZSB0aGUgd2F5IGhvdyB0aGUgZGV2aWF0aW9uIGlzIGV4 cGxpY2l0bHkgYXR0YWNoZWQgdG8gdGhlCnRhcmdldCBtb2R1bGUgaW4gdGhlIGhlbGxvIG1lc3Nh Z2UuIEluIGNvbnRyYXN0LCB0aGUgbm9uLWxvY2FsIGF1Z21lbnQKaXMgc29ydCBvZiBvcGVuLWVu ZGVkIGluIHRoYXQgaXQgcmVsaWVzIG9uIHRoZSBmYWN0IHRoYXQgdGhlIGZvcmVpZ24KbW9kdWxl IGlzIG5lZ290aWF0ZWQgc2VwYXJhdGVseS4KCj4gCj4gPiAyLiBUaGUgZXhhbXBsZQo+ID4gCj4g PiBkZXZpYXRpb24gIi9iYXNlOnN5c3RlbSIgeyBkZXZpYXRlIGRlbGV0ZSB7IG11c3QgImRheXRp bWUgb3IgdGltZSI7IH0gfQo+ID4gCj4gPiBhZ2FpbiByYWlzZXMgdGhlIHF1ZXN0aW9uIHdoZXRo ZXIgdGhlIGlkZW50aWZpY2F0aW9uIG9mIHRoZSBub2RlCj4gPiBhZGRyZXNzZWQgYnkgdGhlIGRl dmlhdGlvbiBpcyBiYXNlZCBvbiBtYXRjaGluZyBpbiB0aGUgbGV4aWNhbCBvciB2YWx1ZQo+ID4g c3BhY2UuCj4gCj4gVGhlIGlkZWEgaXMgdGhhdCBpbiBvcmRlciB0byBpZGVudGlmeSBzdGF0ZW1l bnRzIGluIHRoZSAiZGV2aWF0ZQo+IGRlbGV0ZSIsIHRoZSBpZGVudGlmaWNhdGlvbiBpcyBkb25l IGluIHRoZSBsZXhpY2FsIHNwYWNlLiAgQW55dGhpbmcKPiBlbHNlIHdvdWxkIGJlIHRvbyBjb21w bGljYXRlZCwgYXMgc2hvd24gaW4geW91ciBleGFtcGxlcy4KCkkgZ3Vlc3MgYXQgbGVhc3Qgd2hp dGVzcGFjZSBub3JtYWxpemF0aW9uIG11c3QgYmUgZG9uZSBvdGhlcndpc2UgaXQKd291bGQgYmUg dmVyeSBmcmFnaWxlLgoKTGFkYQoKPiAKPiAKPiAvbWFydGluCi0tIApMYWRpc2xhdiBMaG90a2Es IENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcK aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Sat Oct 4 07:25:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997633A682C; Sat, 4 Oct 2008 07:25:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8884A3A6A17 for ; Sat, 4 Oct 2008 07:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REI92gBXV2y7 for ; Sat, 4 Oct 2008 07:25:23 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 6B9633A6A46 for ; Sat, 4 Oct 2008 07:25:22 -0700 (PDT) Received: (qmail 44350 invoked from network); 4 Oct 2008 14:25:48 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.105.127 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 4 Oct 2008 14:25:46 -0000 X-YMail-OSG: QgfRRDwVM1muaJfuhwnc64jaU0bYQFiq6LvTyc3atqUhV7hBtxe7FVdQAQZuyZZivhiXx3ZHsPgd5MjHsUrS4LSbaLLhvMBCfQt7krav.KcMsiKs_08NwdpZopQ0kK.ky5MSchoHk6ok7uCEtituSATi X-Yahoo-Newman-Property: ymail-3 Message-ID: <48E77CE8.5030707@netconfcentral.com> Date: Sat, 04 Oct 2008 07:25:44 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <200810040301.m9431dLh016060@idle.juniper.net> <48E6F0FD.5070008@netconfcentral.com> <20081004.093647.142220504.mbj@tail-f.com> In-Reply-To: <20081004.093647.142220504.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Even if this work is pursued in the IETF, then this sort of meta-data >> needs to be specified in separate files from the data model >> definition. Maintaining vendor-specific standard variance >> in the data model file is not going to work. > > By just adding the deviation statement to our normal module framwork, > we keep things simple. No need to invent some other kind of language, > or top-level keyword, and rules for how this would work. > I disagree. The deviation-stmt makes YANG much more complicated. But I don't want to discuss the solution because I do not agree with the problem statement. I think the very idea of allowing vendors to change the data model contract in arbitrary ways is harmful to interoperability. This will not work for configuration management. It doesn't even work for monitoring. > Obviously, you will never find deviation statements in standard data > data modules. But if a vendor writes a module for how it augments a > standard module, it can choose to put deviation stataments in the same > module. > This is something harmful to interoperability, so it does not belong in the IETF at all. Vendors should reach agreement on a language separately to specify all the ways they do not implement a data model correctly. >> It is easy to >> decouple the data model variance language from the >> data modeling language. There is no reason at all >> that YANG 1.0 would need to reference the other document, >> or any reason to change it in order to specify a companion >> DM variance language. > > If we did this, what should be said about conformance in the main > document? How can we write the text so that it allows some other > document in the future to add deviations? Should we be silent on the > issue, or should we say that in order to claim conformance to a module > you MUST implement everything exactly as written? Or maybe that you > MAY implement everything exactly as written? > You MUST implement everything in the feature to advertise the feature as 'supported'. You need to define lots of features if you plan to leave out various pieces on various platforms. There are no excuses for replacing, modifying, and otherwise rewriting the data model API via deviation statements. The CLI 'anything goes' mentality will not work for standards-based configuration management. The IETF should be spending energy on promoting interoperability, not on more and more clever ways for vendors to avoid implementing a standard data model correctly. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Oct 4 10:44: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 C30BB3A6A44; Sat, 4 Oct 2008 10:44: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 A27623A68F4 for ; Sat, 4 Oct 2008 10:44: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 DJR7pRRP5gEg for ; Sat, 4 Oct 2008 10:44:18 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 88EB43A689F for ; Sat, 4 Oct 2008 10:44:17 -0700 (PDT) Received: from p4ff03d3b.dip0.t-ipconnect.de ([79.240.61.59] helo=[192.168.178.23]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1KmBBQ-0003xS-M7 for netmod@ietf.org; Sat, 04 Oct 2008 19:44:48 +0200 Message-ID: <48E7AB9C.5090900@informatik.uni-tuebingen.de> Date: Sat, 04 Oct 2008 19:45:00 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: netmod@ietf.org References: In-Reply-To: Subject: Re: [netmod] 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: multipart/mixed; boundary="===============1566730883==" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1566730883== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060904050702060402090804" This is a cryptographically signed message in MIME format. --------------ms060904050702060402090804 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Martin, Phil, I've read your proposal. From my point of view, both, features and deviations are useful. However, I'm not an expert regarding possible implications and resulting interoperability problems. Maybe, YANG cannot prevent data model writer or implementor from doing stupid things anyway. In the context of the IPFIX configuration data model, deviations allow devices to report resource restrictions to the manager, for example the maximum number of Selection Process instances as mentioned in http://www.ietf.org/mail-archive/web/netmod/current/msg00792.html. A common usage will be the addition of a max-elements statement to a certain node. I assume that resource restrictions lead to device-specific configuration restrictions in other contexts as well. Deviations provide a simple and flexible solution addressing this problem. Maybe there are good reasons for not allowing deviations. But then alternative mechanisms are needed to report resource restrictions. Does YANG dictate that a manager application must adopt and respect all deviations received in the hello message? Understanding and interpreting arbitrary deviations may largely increase the complexity of the application. So, you could specify: - a device MUST report deviations but MUST NOT expect that the deviations are adopted by the manager - a manager MAY respect deviations Then, the fallback option is that the device returns an error message indicating that a certain configuration failed due to a deviation. I see an overlap between features and deviations. Knowing that deviations are possible anyway, module writers might become lazy and "forget" to partition their module into reasonable features. But maybe this falls into the category of "stupid things" that cannot be prevented. Regards, Gerhard > Hi, > > As input to the discussions next week, we have written down a proposal > for how to handle conformance in YANG. > > Most of the proposal is included below. For all the details, > including new ABNF rules, see: > > http://www.yang-central.org/tmp/draft-ietf-netmod-yang-01-with-conformance.txt > > or the diff to the current version: > > http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-netmod-yang-01.txt&url2=http://www.yang-central.org/tmp/draft-ietf-netmod-yang-01-with-conformance.txt > > > Martin & Phil --------------ms060904050702060402090804 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MTAwNDE3NDUwMFowIwYJKoZIhvcNAQkEMRYEFDE/V9BiwYa0 BrrYaOHUwFTbbrr/MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQBhi0DimBEBvS0A1ttOeroD7DOhiJYuSCidOCpMN6EkBboS5DIdgUVpD4gl y4G0drbJNYmWnmH/3isbZQUTxYuly58QSNorEUOxBF6bXlIvgpCAhz7+lVqog3NJtKCcFWvb hPTAtCk0MwogPDTPj2vIH/EIYaRfBuYDwd/R1U4G6KYU7c5YdtfxmB/0ezOLqIbpk8tSsRA6 fsYihLBiOIJBLwm23woZibFzT/8Nrp5r8nOzeD7i5KNFMmJgrHQPWR8hdRsq+QTHqoG7Psgl 8z4EwjjI6ZzrOZK3XiAKk1uwgDZU65n+cUuC59d5FVZRlzOY6HX2eJHJby147/eeulI2AAAA AAAA --------------ms060904050702060402090804-- --===============1566730883== 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 --===============1566730883==-- From netmod-bounces@ietf.org Sat Oct 4 18:56: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 ED5F33A6780; Sat, 4 Oct 2008 18:56: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 0C9D73A684B for ; Sat, 4 Oct 2008 18:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 YInQbNcP+wHO for ; Sat, 4 Oct 2008 18:56:30 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 9C1C13A6780 for ; Sat, 4 Oct 2008 18:56:27 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Sat, 04 Oct 2008 18:56:31 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Oct 2008 18:51:21 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Oct 2008 18:51:21 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Oct 2008 18:51:20 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m951pKM16146; Sat, 4 Oct 2008 18:51:20 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m951l5BZ020208; Sun, 5 Oct 2008 01:47:06 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200810050147.m951l5BZ020208@idle.juniper.net> To: Gerhard Muenz In-reply-to: <48E7AB9C.5090900@informatik.uni-tuebingen.de> Date: Sat, 04 Oct 2008 21:47:05 -0400 From: Phil Shafer X-OriginalArrivalTime: 05 Oct 2008 01:51:20.0773 (UTC) FILETIME=[DD5A4F50:01C9268C] Cc: netmod@ietf.org Subject: Re: [netmod] 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Gerhard Muenz writes: >Maybe, YANG cannot >prevent data model writer or implementor from doing stupid things anyway. Exactly. You can't fix stupid, but deviations provides a means of learning about implementation "short-comings", rather than telling applications that it's fine to stay ignorant of these issues. >Does YANG dictate that a manager application must adopt and respect all >deviations received in the hello message? Nope. I see these as advisory. "Hello, my name is example.net and here are my issues". The application can "play thru" as though the device never let it know and the result will be no worse than the current state of affairs. >I see an overlap between features and deviations. Knowing that >deviations are possible anyway, module writers might become lazy and >"forget" to partition their module into reasonable features. But maybe >this falls into the category of "stupid things" that cannot be prevented. Features are part of the model and there's design and thought put into them. Deviations are the ugly little secrets that form the negative side of engineering trade-offs. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Oct 4 19:00: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 1C50E3A6780; Sat, 4 Oct 2008 19:00: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 0C1F33A67AE for ; Sat, 4 Oct 2008 19:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 Q3ckB1KNeRrH for ; Sat, 4 Oct 2008 19:00:17 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 2AC503A6780 for ; Sat, 4 Oct 2008 19:00:15 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Sat, 04 Oct 2008 19:00:45 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Oct 2008 18:58:28 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Oct 2008 18:58:27 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Oct 2008 18:58: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 m951wQM17895; Sat, 4 Oct 2008 18:58:26 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m951sAMp020251; Sun, 5 Oct 2008 01:54:12 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200810050154.m951sAMp020251@idle.juniper.net> To: Andy Bierman In-reply-to: <48E77CE8.5030707@netconfcentral.com> Date: Sat, 04 Oct 2008 21:54:10 -0400 From: Phil Shafer X-OriginalArrivalTime: 05 Oct 2008 01:58:27.0218 (UTC) FILETIME=[DB88A720:01C9268D] Cc: netmod@ietf.org Subject: Re: [netmod] 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: , 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 the very idea >of allowing vendors to change the data model contract in >arbitrary ways is harmful to interoperability. Or, viewed the other way, the assumption that vendors will faithfully implement data models as specified has been harmful to the adoption of network management. It's not a lily-white world. Admit it and brace yourself to handle it. >Vendors should reach agreement >on a language separately to specify all the ways they >do not implement a data model correctly. A non-standard mechanism for announcing deviations will be harmful to interoperability. >You MUST implement everything in the feature to advertise the feature >as 'supported'. You need to define lots of features if you plan >to leave out various pieces on various platforms. Features are defined by the modeler. They are part of the model and are useful for expressing optional facets of the model. Deviations are for the implementor to admit their issues in failing to implement the data model as written. These are two very different sources of information. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Oct 4 23:36:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1EB3A6918; Sat, 4 Oct 2008 23:36:46 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4F803A6918 for ; Sat, 4 Oct 2008 23:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_00=-2.599, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCTwBugHyqrB for ; Sat, 4 Oct 2008 23:36:44 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 7B73C3A68DE for ; Sat, 4 Oct 2008 23:36:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,363,1220241600"; d="scan'208";a="123969750" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Oct 2008 02:37:13 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 05 Oct 2008 02:37:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 5 Oct 2008 08:37:10 +0200 Message-ID: In-Reply-To: <48E77CE8.5030707@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] conformance Thread-Index: AckmLR/75r1u0wEmTVyMajnJ4wdQqAAhKUwg References: <200810040301.m9431dLh016060@idle.juniper.net> <48E6F0FD.5070008@netconfcentral.com><20081004.093647.142220504.mbj@tail-f.com> <48E77CE8.5030707@netconfcentral.com> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , "Martin Bjorklund" Cc: netmod@ietf.org Subject: Re: [netmod] 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 Here is my opinion as a contributor and implementer of many agents with various degrees of deviations who at some point in time jumped over the fence to develop management applications that had to deal with deviations in agents codes. 1. I fully agree with Andy that deviations will make interoperability between agents and managers difficult and probably impossible in many cases. Standards compliance to YANG data model means that all features in the data model MUST be implemented as written. Period. 2. Variants to standard data models are facts of life. If they can be described in standard language this is useful. Managers have a chance to cope with specific variant agents. Interoperating with one specific variant agent does not guarantee that the manager will be able to interoperate with any other variant agent. 3. I cannot judge to what degree the deviation-stmt makes the YANG 1.0 more complicated. I believe that having this statement in one form or another within the language would be very useful, if marked clearly as a mean to describe variants that make the agents not compliant with the standard data model. In other words, implementing all features in the data model as written is the only way to achieve compliance. Describing variants by using the deviation-stmt is a tool that agents developers can use to help management applications deal with their non-compliant implementations on a case to case basis. Dan > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Saturday, October 04, 2008 5:26 PM > To: Martin Bjorklund > Cc: netmod@ietf.org > Subject: Re: [netmod] conformance > > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Even if this work is pursued in the IETF, then this sort > of meta-data > >> needs to be specified in separate files from the data model > >> definition. Maintaining vendor-specific standard variance in the > >> data model file is not going to work. > > > > By just adding the deviation statement to our normal module > framwork, > > we keep things simple. No need to invent some other kind > of language, > > or top-level keyword, and rules for how this would work. > > > > I disagree. The deviation-stmt makes YANG much more complicated. > > But I don't want to discuss the solution because I do not > agree with the problem statement. I think the very idea of > allowing vendors to change the data model contract in > arbitrary ways is harmful to interoperability. This will not > work for configuration management. It doesn't even work for > monitoring. > > > > Obviously, you will never find deviation statements in > standard data > > data modules. But if a vendor writes a module for how it > augments a > > standard module, it can choose to put deviation stataments > in the same > > module. > > > > This is something harmful to interoperability, so it does not > belong in the IETF at all. Vendors should reach agreement on > a language separately to specify all the ways they do not > implement a data model correctly. > > > >> It is easy to > >> decouple the data model variance language from the data modeling > >> language. There is no reason at all that YANG 1.0 would need to > >> reference the other document, or any reason to change it > in order to > >> specify a companion DM variance language. > > > > If we did this, what should be said about conformance in the main > > document? How can we write the text so that it allows some other > > document in the future to add deviations? Should we be > silent on the > > issue, or should we say that in order to claim conformance > to a module > > you MUST implement everything exactly as written? Or maybe > that you > > MAY implement everything exactly as written? > > > > > You MUST implement everything in the feature to advertise the > feature as 'supported'. You need to define lots of features > if you plan to leave out various pieces on various platforms. > > There are no excuses for replacing, modifying, and otherwise > rewriting the data model API via deviation statements. > The CLI 'anything goes' mentality will not work for > standards-based configuration management. The IETF should be > spending energy on promoting interoperability, not on more > and more clever ways for vendors to avoid implementing a > standard data model correctly. > > > > > > /martin > > > > > > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Oct 5 00:22: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 EF9813A677E; Sun, 5 Oct 2008 00:22: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 4BB153A67B2 for ; Sun, 5 Oct 2008 00:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.724 X-Spam-Level: X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpLGwf+G-+ft for ; Sun, 5 Oct 2008 00:22:10 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 5EA743A677E for ; Sun, 5 Oct 2008 00:22:10 -0700 (PDT) Received: (qmail 34668 invoked from network); 5 Oct 2008 07:22:42 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.105.127 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 5 Oct 2008 07:22:41 -0000 X-YMail-OSG: E9wU_ZIVM1lfxJXvCqSW4Y1gLS.FMIoWT0lGt7YSlwBeZmz3T9RFADn99Z_WPiXQ2KeMJQ9tLHoxGC05Tp15X1ETtHA3WhtlKAHBrTnE6Vy_KiJ7Q0CeXQVVUlLMX5KL4XWwOELOHuNyZhIpBjM4DBW5 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48E86B3F.5050702@netconfcentral.com> Date: Sun, 05 Oct 2008 00:22:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <200810040301.m9431dLh016060@idle.juniper.net> <48E6F0FD.5070008@netconfcentral.com><20081004.093647.142220504.mbj@tail-f.com> <48E77CE8.5030707@netconfcentral.com> In-Reply-To: Cc: netmod@ietf.org Subject: Re: [netmod] 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 Romascanu, Dan (Dan) wrote: > Here is my opinion as a contributor and implementer of many agents with > various degrees of deviations who at some point in time jumped over the > fence to develop management applications that had to deal with > deviations in agents codes. > > 1. I fully agree with Andy that deviations will make interoperability > between agents and managers difficult and probably impossible in many > cases. Standards compliance to YANG data model means that all features > in the data model MUST be implemented as written. Period. > > 2. Variants to standard data models are facts of life. If they can be > described in standard language this is useful. Managers have a chance to > cope with specific variant agents. Interoperating with one specific > variant agent does not guarantee that the manager will be able to > interoperate with any other variant agent. > > 3. I cannot judge to what degree the deviation-stmt makes the YANG 1.0 > more complicated. I believe that having this statement in one form or > another within the language would be very useful, if marked clearly as a > mean to describe variants that make the agents not compliant with the > standard data model. > > In other words, implementing all features in the data model as written > is the only way to achieve compliance. Describing variants by using the > deviation-stmt is a tool that agents developers can use to help > management applications deal with their non-compliant implementations on > a case to case basis. > If the agent could replace a standard leaf with a proprietary leaf in such a way that the derivation-stmt could solve the variation, then why can't the agent implement the standard leaf correctly, and simply translate the proprietary leaf into the standard leaf within the agent itself? Why move that automatic translation to the manager? If it isn't automatic, then it isn't any better than the DESCRIPTION clause approach we have now. > Dan Andy > > > >> -----Original Message----- >> From: netmod-bounces@ietf.org >> [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman >> Sent: Saturday, October 04, 2008 5:26 PM >> To: Martin Bjorklund >> Cc: netmod@ietf.org >> Subject: Re: [netmod] conformance >> >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Even if this work is pursued in the IETF, then this sort >> of meta-data >>>> needs to be specified in separate files from the data model >>>> definition. Maintaining vendor-specific standard variance in the >>>> data model file is not going to work. >>> By just adding the deviation statement to our normal module >> framwork, >>> we keep things simple. No need to invent some other kind >> of language, >>> or top-level keyword, and rules for how this would work. >>> >> I disagree. The deviation-stmt makes YANG much more complicated. >> >> But I don't want to discuss the solution because I do not >> agree with the problem statement. I think the very idea of >> allowing vendors to change the data model contract in >> arbitrary ways is harmful to interoperability. This will not >> work for configuration management. It doesn't even work for >> monitoring. >> >> >>> Obviously, you will never find deviation statements in >> standard data >>> data modules. But if a vendor writes a module for how it >> augments a >>> standard module, it can choose to put deviation stataments >> in the same >>> module. >>> >> This is something harmful to interoperability, so it does not >> belong in the IETF at all. Vendors should reach agreement on >> a language separately to specify all the ways they do not >> implement a data model correctly. >> >> >>>> It is easy to >>>> decouple the data model variance language from the data modeling >>>> language. There is no reason at all that YANG 1.0 would need to >>>> reference the other document, or any reason to change it >> in order to >>>> specify a companion DM variance language. >>> If we did this, what should be said about conformance in the main >>> document? How can we write the text so that it allows some other >>> document in the future to add deviations? Should we be >> silent on the >>> issue, or should we say that in order to claim conformance >> to a module >>> you MUST implement everything exactly as written? Or maybe >> that you >>> MAY implement everything exactly as written? >>> >> >> You MUST implement everything in the feature to advertise the >> feature as 'supported'. You need to define lots of features >> if you plan to leave out various pieces on various platforms. >> >> There are no excuses for replacing, modifying, and otherwise >> rewriting the data model API via deviation statements. >> The CLI 'anything goes' mentality will not work for >> standards-based configuration management. The IETF should be >> spending energy on promoting interoperability, not on more >> and more clever ways for vendors to avoid implementing a >> standard data model correctly. >> >> >>> /martin >>> >>> >>> >> Andy >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Oct 5 00:35: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 30E973A6884; Sun, 5 Oct 2008 00:35: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 C5C823A6917 for ; Sun, 5 Oct 2008 00:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DA+f+Djk2Upc for ; Sun, 5 Oct 2008 00:35:54 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id C519B3A690D for ; Sun, 5 Oct 2008 00:35:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,363,1220241600"; d="scan'208";a="137347100" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 05 Oct 2008 03:36:26 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 05 Oct 2008 03:36:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 5 Oct 2008 09:36:24 +0200 Message-ID: In-Reply-To: <48E86B3F.5050702@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] conformance Thread-Index: AckmuykB90KYk02nSVW0lp2OqKWxHQAAFHOA References: <200810040301.m9431dLh016060@idle.juniper.net> <48E6F0FD.5070008@netconfcentral.com><20081004.093647.142220504.mbj@tail-f.com> <48E77CE8.5030707@netconfcentral.com> <48E86B3F.5050702@netconfcentral.com> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" Cc: netmod@ietf.org Subject: Re: [netmod] 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 > -----Original Message----- > From: Andy Bierman [mailto:andy@netconfcentral.com] > > > > If the agent could replace a standard leaf with a proprietary > leaf in such a way that the derivation-stmt could solve the > variation, then why can't the agent implement the standard > leaf correctly, and simply translate the proprietary leaf > into the standard leaf within the agent itself? Why move > that automatic translation to the manager? If it isn't > automatic, then it isn't any better than the DESCRIPTION > clause approach we have now. > > > > Dan > > Andy > Let me try to answer with a couple of examples based on my experience with AGENT-CAPABILITIES (allow me to acronym this by A-C). I should say that in the old days many vendors were reluctant to use A-C because it was documenting their holes in implementations that were supposed to claim standards compliance. This should be made even more clear and crisp if we do agree to define something like this in YANG. One of the reasons in SMI we used A-C was that agents were dealing with sub-agents that were not under their control and came with their own variants that had to be dealt with and exposed to managers using SMUX or Emanate or AGENTX. In such cases a manager could deal with situations like 'in this enumerated object only five of the seven enumerated values are implemented, but we added this other three' and 'I am not implementing this standard knob, but my older proprietary knob with identical semantics'. Dan _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Oct 5 07:06: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 5EF2B3A687E; Sun, 5 Oct 2008 07:06: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 EC4BE3A687E for ; Sun, 5 Oct 2008 07:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=0.271, 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 ZY35OnJHZQcO for ; Sun, 5 Oct 2008 07:06:58 -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 3CB483A6847 for ; Sun, 5 Oct 2008 07:06:58 -0700 (PDT) Received: (qmail 58122 invoked from network); 5 Oct 2008 14:07:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.105.127 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 5 Oct 2008 14:07:30 -0000 X-YMail-OSG: pH20I9oVM1nd2wF71p_0gAsn1Q0MyzWhSZuXF6RsWA1T7aCHuId.ilwn03CHpG7SIdeL7fNTy32A8EQFuSJaopxIk8InsNWBbIGk6bXNN6rMVd2CDIAU0IVzfGDbXDSB15suDZemTwP5_VVG1VmdbU1L X-Yahoo-Newman-Property: ymail-3 Message-ID: <48E8CA20.5000402@netconfcentral.com> Date: Sun, 05 Oct 2008 07:07:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <200810040301.m9431dLh016060@idle.juniper.net> <48E6F0FD.5070008@netconfcentral.com><20081004.093647.142220504.mbj@tail-f.com> <48E77CE8.5030707@netconfcentral.com> <48E86B3F.5050702@netconfcentral.com> In-Reply-To: Cc: netmod@ietf.org Subject: Re: [netmod] 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 Romascanu, Dan (Dan) wrote: > > >> -----Original Message----- >> From: Andy Bierman [mailto:andy@netconfcentral.com] >> If the agent could replace a standard leaf with a proprietary >> leaf in such a way that the derivation-stmt could solve the >> variation, then why can't the agent implement the standard >> leaf correctly, and simply translate the proprietary leaf >> into the standard leaf within the agent itself? Why move >> that automatic translation to the manager? If it isn't >> automatic, then it isn't any better than the DESCRIPTION >> clause approach we have now. >> >> >>> Dan >> Andy >> > > Let me try to answer with a couple of examples based on my experience > with AGENT-CAPABILITIES (allow me to acronym this by A-C). I should say > that in the old days many vendors were reluctant to use A-C because it > was documenting their holes in implementations that were supposed to > claim standards compliance. This should be made even more clear and > crisp if we do agree to define something like this in YANG. One of the > reasons in SMI we used A-C was that agents were dealing with sub-agents > that were not under their control and came with their own variants that > had to be dealt with and exposed to managers using SMUX or Emanate or > AGENTX. In such cases a manager could deal with situations like 'in this > enumerated object only five of the seven enumerated values are > implemented, but we added this other three' and 'I am not implementing > this standard knob, but my older proprietary knob with identical > semantics'. > If the YANG proposal was constrained like AGENT-CAPABILITIES, then I would not object to it. It is one thing to implement the range 1-8 when the real knob is 1-10, or subset the number of buffers requested. It is quite another to replace the standard knob when N vendor knobs that may or may not have anything to do with the original semantics. > Dan > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Oct 5 13:01: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 A322E3A6917; Sun, 5 Oct 2008 13:01: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 7F9603A6917 for ; Sun, 5 Oct 2008 13:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=0.181, 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 WtGwEyjGXDZk for ; Sun, 5 Oct 2008 13:01:52 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id DCDE23A67B1 for ; Sun, 5 Oct 2008 13:01:51 -0700 (PDT) Received: (qmail 39226 invoked from network); 5 Oct 2008 20:02:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.105.127 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 5 Oct 2008 20:02:20 -0000 X-YMail-OSG: veBZmEoVM1nSx4YX_Gu7nSOVrdvsw2LNaJKpI4QJbh32LbZhhnFbQRePLn.HJjJYGeCVZFmmbOFl3hIwfMGsplHpKqAv_dmEehnDtmiw3Pbn.NWPdFHgJF3LkYet4fQhWRw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48E91D4B.9030005@netconfcentral.com> Date: Sun, 05 Oct 2008 13:02:19 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] 7.13.4 -- put back the element X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I think the recent change to the encoding is broken. This change removes the element and encodes the rpc output-stmt nodes directly within , as in the example in 7.13.5 (but not 4.2.9). The NETCONF rpc-reply should be capable of returning any arbitrary content to the manager, even elements and . However, by putting the reply payload at the same sibling level as the header nodes, an application would very likely interpret the 'content' as the actual header nodes they are. Therefore, the container needs to be in the PDU, as it is defined in RFC 4741. This ensures that no application can possibly misinterpret the or elements within the content layer as header nodes. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Oct 5 13:53: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 648023A67E4; Sun, 5 Oct 2008 13:53: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 9701B3A6997 for ; Sun, 5 Oct 2008 13:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.164, 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 SvK48wy1Fnxw for ; Sun, 5 Oct 2008 13:53: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 C7B163A6808 for ; Sun, 5 Oct 2008 13:53:56 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 7227176C31E; Sun, 5 Oct 2008 22:54:19 +0200 (CEST) Date: Sun, 05 Oct 2008 22:56:43 +0200 (CEST) Message-Id: <20081005.225643.264992628.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48E91D4B.9030005@netconfcentral.com> References: <48E91D4B.9030005@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.13.4 -- put back the element X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 was discussed in the email thread "rpc-reply" on the netconf list a while back, before I made this change. Sepcifically, we discussed if the text in 4.2 of RFC 4741 is correct: The response name and response data are encoded as the contents of the element. The name of the reply is an element directly inside the element, and any data is encoded inside this element. This text specifies that the respone element is a direct child to . Andy Bierman wrote: > Hi, > > I think the recent change to the encoding is broken. > This change removes the element and encodes the > rpc output-stmt nodes directly within , as in > the example in 7.13.5 (but not 4.2.9). > > The NETCONF rpc-reply should be capable of returning > any arbitrary content to the manager, even elements > and . However, by putting the reply payload > at the same sibling level as the header nodes, > an application would very likely interpret the 'content' > as the actual header nodes they are. What "header nodes"? > Therefore, the container needs to be in the PDU, > as it is defined in RFC 4741. This ensures that no > application can possibly misinterpret the or > elements within the content layer as header nodes. Can you provide an example of an rpc-reply that an application can misinterpret? I don't understand what you mean. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Oct 5 14: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 E68FF3A6855; Sun, 5 Oct 2008 14: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 4A2DE3A6855 for ; Sun, 5 Oct 2008 14:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=0.135, 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 hHlTkx7oDqD3 for ; Sun, 5 Oct 2008 14:24:06 -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 8C7193A697A for ; Sun, 5 Oct 2008 14:24:06 -0700 (PDT) Received: (qmail 13996 invoked from network); 5 Oct 2008 21:24:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.105.127 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 5 Oct 2008 21:24:39 -0000 X-YMail-OSG: AKjod7kVM1loWaNoCMGmptLcQGae8F5sfyNBG1abzgNyM9IbZTPV53I1bqEL_I_gYSN5uHw7ZZCaFbkP4A7RV0kRwhIcdjE.qYVyK.YCf38NeiaemZc1xZ64pbdBY1Wr6Uq_ucY04cdy0zX2ElnVU7ny X-Yahoo-Newman-Property: ymail-3 Message-ID: <48E93096.1020108@netconfcentral.com> Date: Sun, 05 Oct 2008 14:24:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <48E91D4B.9030005@netconfcentral.com> <20081005.225643.264992628.mbj@tail-f.com> In-Reply-To: <20081005.225643.264992628.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] 7.13.4 -- put back the element X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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, > > This was discussed in the email thread "rpc-reply" on the netconf list > a while back, before I made this change. Sepcifically, we discussed > if the text in 4.2 of RFC 4741 is correct: > > The response name and response data are encoded as the contents of > the element. The name of the reply is an element > directly inside the element, and any data is encoded > inside this element. > > This text specifies that the respone element is a direct child to > . > > > Andy Bierman wrote: >> Hi, >> >> I think the recent change to the encoding is broken. >> This change removes the element and encodes the >> rpc output-stmt nodes directly within , as in >> the example in 7.13.5 (but not 4.2.9). >> >> The NETCONF rpc-reply should be capable of returning >> any arbitrary content to the manager, even elements >> and . However, by putting the reply payload >> at the same sibling level as the header nodes, >> an application would very likely interpret the 'content' >> as the actual header nodes they are. > > What "header nodes"? > >> Therefore, the container needs to be in the PDU, >> as it is defined in RFC 4741. This ensures that no >> application can possibly misinterpret the or >> elements within the content layer as header nodes. > > Can you provide an example of an rpc-reply that an application can > misinterpret? I don't understand what you mean. > The elements and have meaning already defined when they are the direct child nodes of . The NETCONF protocol is supposed to be able to carry arbitrary content (as per the diagram everybody copies). But without a node within the , then an application which for whatever reason wants to return the or elements cannot do so without them being mis-interpreted. The node also future-proofs the for any new standard-defined replies. An RPC method called get-example-error might need to return an element, but it can't with the data node taken out. An application cannot be sure if the RPC worked or not. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Oct 5 14:40: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 A714D3A67E5; Sun, 5 Oct 2008 14:40: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 79AE63A687E for ; Sun, 5 Oct 2008 14:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wgFhOK2BDfd for ; Sun, 5 Oct 2008 14:40:34 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 96E283A67F6 for ; Sun, 5 Oct 2008 14:40:34 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id DFE2F76C31E; Sun, 5 Oct 2008 23:41:08 +0200 (CEST) Date: Sun, 05 Oct 2008 23:43:31 +0200 (CEST) Message-Id: <20081005.234331.224733404.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48E93096.1020108@netconfcentral.com> References: <48E91D4B.9030005@netconfcentral.com> <20081005.225643.264992628.mbj@tail-f.com> <48E93096.1020108@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.13.4 -- put back the element X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: > But without a node within the , > then an application which for whatever reason > wants to return the or elements > cannot do so without them being mis-interpreted. But other rpc's replies will be in some other namespace, so I don't see how these replies will be mis-interpreted as or in the netconf namespace? > An RPC method called get-example-error might need > to return an element, but it can't > with the data node taken out. Why not? For example, using the example in the draft: rpc activate-software-image { input { leaf image-name { type string; } } output { leaf status { type string; } } } If everything is ok, the following os returned: The image acmefw-2.3 is being installed. If an error occurs, you might get: application access-denied error /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Oct 5 16:31: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 7641F3A68B8; Sun, 5 Oct 2008 16:31: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 203933A68CC for ; Sun, 5 Oct 2008 16:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.108, 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 wD1DaS7cJiP3 for ; Sun, 5 Oct 2008 16:31:18 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 5A5F73A68B8 for ; Sun, 5 Oct 2008 16:31:18 -0700 (PDT) Received: (qmail 5368 invoked from network); 5 Oct 2008 23:31:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.105.127 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 5 Oct 2008 23:31:51 -0000 X-YMail-OSG: UCzc5E8VM1kzcIBBpxQ0x.xLwXDSZe6Xp7Iy85zOvPCEh5syhAYylNBHskbDoC6X01HNpc1YHKjuhrNhHaayye5ikBQay.x4xJVbyH1MOSFHHhYbnaf7Y_oM5bLYoNcKDkdgyiFAe4BbtOHUTId.Y3uZ X-Yahoo-Newman-Property: ymail-3 Message-ID: <48E94E66.3080202@netconfcentral.com> Date: Sun, 05 Oct 2008 16:31:50 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <48E91D4B.9030005@netconfcentral.com> <20081005.225643.264992628.mbj@tail-f.com> <48E93096.1020108@netconfcentral.com> <20081005.234331.224733404.mbj@tail-f.com> In-Reply-To: <20081005.234331.224733404.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] 7.13.4 -- put back the element X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: >> But without a node within the , >> then an application which for whatever reason >> wants to return the or elements >> cannot do so without them being mis-interpreted. > > But other rpc's replies will be in some other namespace, so I don't > see how these replies will be mis-interpreted as or > in the netconf namespace? > So removing the element is OK because nobody is ever allowed to have a YANG module that uses the NETCONF namespace? That should be mentioned in the draft, not just assumed. Removing the element has another impact on implementations that choose to generate elements inline within a reply. This can generate XML that is definitely invalid according to the XSD. If the RPC output is a set of sibling nodes (e.g., a, b, c) then if the agent generates any warnings, or if 'a' and 'c' are not available: application operation-failed warning data-unavailable /rpc-reply/a foo-bar application operation-failed warning data-unavailable /rpc-reply/c The XSD for specifies the element, and including it again after the element in a PDU will likely cause a parser to complain. Andy >> An RPC method called get-example-error might need >> to return an element, but it can't >> with the data node taken out. > > Why not? > > For example, using the example in the draft: > > rpc activate-software-image { > input { > leaf image-name { > type string; > } > } > output { > leaf status { > type string; > } > } > } > > If everything is ok, the following os returned: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > The image acmefw-2.3 is being installed. > > > > If an error occurs, you might get: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > application > access-denied > error > > > > > /martin > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 00:32: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 E625E28C1F2; Mon, 6 Oct 2008 00:32: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 B1E3128C1FE for ; Mon, 6 Oct 2008 00:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fiylCybw536 for ; Mon, 6 Oct 2008 00:32:09 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4851628C1F2 for ; Mon, 6 Oct 2008 00:32:09 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id C528276C4E8; Mon, 6 Oct 2008 09:32:43 +0200 (CEST) Date: Mon, 06 Oct 2008 09:32:41 +0200 (CEST) Message-Id: <20081006.093241.33474258.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48E94E66.3080202@netconfcentral.com> References: <48E93096.1020108@netconfcentral.com> <20081005.234331.224733404.mbj@tail-f.com> <48E94E66.3080202@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.13.4 -- put back the element X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> But without a node within the , > >> then an application which for whatever reason > >> wants to return the or elements > >> cannot do so without them being mis-interpreted. > > But other rpc's replies will be in some other namespace, so I don't > > see how these replies will be mis-interpreted as or > > in the netconf namespace? > > > > So removing the element is OK because > nobody is ever allowed to have a YANG module > that uses the NETCONF namespace? > > That should be mentioned in the draft, not just assumed. It is stated that all XML elements are in the module's namespace. > Removing the element has another impact > on implementations that choose to generate > elements inline within a reply. I though we said earlier that inline rpc-error was not rfc 4741 compliant? If it is complient, what are the rules for such inline errors? Are these rules data modelling language specific? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 02:00:01 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F48B3A6831; Mon, 6 Oct 2008 02:00:01 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D5983A6A1A for ; Mon, 6 Oct 2008 02:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-i1ado2keaf for ; Mon, 6 Oct 2008 01:59:59 -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 44FE63A6831 for ; Mon, 6 Oct 2008 01:59:59 -0700 (PDT) Received: (qmail 96249 invoked from network); 6 Oct 2008 08:59:46 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.158.105 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 6 Oct 2008 08:59:44 -0000 X-YMail-OSG: 9hXmnqYVM1mSF2SaJ4ITvrsllIa1kC4O1x8WbRX.im.DAykBk0n3DqLyBUbarEDdn8u5ZbvuaoNtwEimTEvp4GTMymGEjv11SWzyVRykMJhLgqNvaXHmtU0lplurqF7mzvmBwasVXkokfQlFxSjyPO0qRDZ3lCYTPfBSK0nGEupT X-Yahoo-Newman-Property: ymail-3 Message-ID: <48E9D37F.8050000@netconfcentral.com> Date: Mon, 06 Oct 2008 01:59:43 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <48E93096.1020108@netconfcentral.com> <20081005.234331.224733404.mbj@tail-f.com> <48E94E66.3080202@netconfcentral.com> <20081006.093241.33474258.mbj@tail-f.com> In-Reply-To: <20081006.093241.33474258.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] 7.13.4 -- put back the element X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> But without a node within the , >>>> then an application which for whatever reason >>>> wants to return the or elements >>>> cannot do so without them being mis-interpreted. >>> But other rpc's replies will be in some other namespace, so I don't >>> see how these replies will be mis-interpreted as or >>> in the netconf namespace? >>> >> So removing the element is OK because >> nobody is ever allowed to have a YANG module >> that uses the NETCONF namespace? >> >> That should be mentioned in the draft, not just assumed. > The draft mentions that the namespace URI defined by RFC 4741 is reserved and can not ever be used in a YANG module? > It is stated that all XML elements are in the module's namespace. > >> Removing the element has another impact >> on implementations that choose to generate >> elements inline within a reply. > > I though we said earlier that inline rpc-error was not rfc 4741 > compliant? If it is complient, what are the rules for such inline > errors? Are these rules data modelling language specific? > Within the element they are inline. As child nodes of they are not. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 04:13: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 0BABF3A67AC; Mon, 6 Oct 2008 04:13: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 126143A68C4 for ; Mon, 6 Oct 2008 04:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.617 X-Spam-Level: X-Spam-Status: No, score=-1.617 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Al-T5RWYHG1e for ; Mon, 6 Oct 2008 04:13:01 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 55A943A67AC for ; Mon, 6 Oct 2008 04:13:01 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 8864C76C4E8; Mon, 6 Oct 2008 13:13:00 +0200 (CEST) Date: Mon, 06 Oct 2008 13:13:00 +0200 (CEST) Message-Id: <20081006.131300.172045470.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48E9D37F.8050000@netconfcentral.com> References: <48E94E66.3080202@netconfcentral.com> <20081006.093241.33474258.mbj@tail-f.com> <48E9D37F.8050000@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.13.4 -- put back the element X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 draft mentions that the namespace URI defined by RFC 4741 > is reserved and can not ever be used in a YANG module? No of course not. It would be very useful if we had a netconf.yang module published. The operation could be something like: rpc get { input { anyxml filter; } output { anyxml data; } } /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 04:23: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 2AF323A6A9E; Mon, 6 Oct 2008 04:23: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 4C7633A6AB1 for ; Mon, 6 Oct 2008 04:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.569 X-Spam-Level: X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L68t5KLY1ee8 for ; Mon, 6 Oct 2008 04:23:08 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7864C3A6A9E for ; Mon, 6 Oct 2008 04:23:08 -0700 (PDT) Received: from [195.113.228.115] (missotis.w2lan.cesnet.cz [195.113.228.115]) by office2.cesnet.cz (Postfix) with ESMTP id AC259D800C5; Mon, 6 Oct 2008 13:23:43 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20081006.131300.172045470.mbj@tail-f.com> References: <48E94E66.3080202@netconfcentral.com> <20081006.093241.33474258.mbj@tail-f.com> <48E9D37F.8050000@netconfcentral.com> <20081006.131300.172045470.mbj@tail-f.com> Organization: CESNET Date: Mon, 06 Oct 2008 13:23:43 +0200 Message-Id: <1223292223.6327.32.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] 7.13.4 -- put back the element X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBQbyAwNi4gMTAuIDIwMDggdiAxMzoxMyArMDIwMDoK PiBBbmR5IEJpZXJtYW4gPGFuZHlAbmV0Y29uZmNlbnRyYWwuY29tPiB3cm90ZToKPiA+IFRoZSBk cmFmdCBtZW50aW9ucyB0aGF0IHRoZSBuYW1lc3BhY2UgVVJJIGRlZmluZWQgYnkgUkZDIDQ3NDEK PiA+IGlzIHJlc2VydmVkIGFuZCBjYW4gbm90IGV2ZXIgYmUgdXNlZCBpbiBhIFlBTkcgbW9kdWxl Pwo+IAo+IE5vIG9mIGNvdXJzZSBub3QuICBJdCB3b3VsZCBiZSB2ZXJ5IHVzZWZ1bCBpZiB3ZSBo YWQgYSBuZXRjb25mLnlhbmcKCkJ1dCBjYW4gaXQgYmUgZG9uZT8gRm9yIG9uZSwgWUFORyBjYW5u b3QgbW9kZWwgWE1MIGF0dHJpYnV0ZXMuCgpMYWRhCgo+IG1vZHVsZSBwdWJsaXNoZWQuICBUaGUg PGdldD4gb3BlcmF0aW9uIGNvdWxkIGJlIHNvbWV0aGluZyBsaWtlOgo+IAo+ICAgcnBjIGdldCB7 Cj4gICAgaW5wdXQgewo+ICAgICAgYW55eG1sIGZpbHRlcjsKPiAgICB9Cj4gICAgb3V0cHV0IHsK PiAgICAgIGFueXhtbCBkYXRhOwo+ICAgIH0KPiAgfQo+IAo+IAo+IAo+IC9tYXJ0aW4KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IG5ldG1vZCBtYWls aW5nIGxpc3QKPiBuZXRtb2RAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZAotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDog RTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Mon Oct 6 07:38: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 6B7D83A69C1; Mon, 6 Oct 2008 07:38: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 7AAF83A6932 for ; Mon, 6 Oct 2008 07:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4g5NMYqMQ48 for ; Mon, 6 Oct 2008 07:38:12 -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 A0F3A3A67B4 for ; Mon, 6 Oct 2008 07:38:12 -0700 (PDT) Received: (qmail 54386 invoked from network); 6 Oct 2008 14:38:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.69.54 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 6 Oct 2008 14:38:28 -0000 X-YMail-OSG: H6h8MxQVM1nAWmd.NO8MpFU_IWg0LXe374ERrnEPuRNleDkt5fevfdTN3BJs5vJm5mulBmniYbW6qE1WDWyz9nQGd3ri6S_ZSXnb.9D5AnpFtwiamuG2.18zGp8pD52iK9PxdTwxYSq9fbatRwWlO8NN X-Yahoo-Newman-Property: ymail-3 Message-ID: <48EA22E2.3010806@netconfcentral.com> Date: Mon, 06 Oct 2008 07:38:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <48E94E66.3080202@netconfcentral.com> <20081006.093241.33474258.mbj@tail-f.com> <48E9D37F.8050000@netconfcentral.com> <20081006.131300.172045470.mbj@tail-f.com> In-Reply-To: <20081006.131300.172045470.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] 7.13.4 -- put back the element X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 draft mentions that the namespace URI defined by RFC 4741 >> is reserved and can not ever be used in a YANG module? > > No of course not. It would be very useful if we had a netconf.yang > module published. The operation could be something like: > > rpc get { > input { > anyxml filter; > } > output { > anyxml data; > } > } > What about the element? What about the element? If any RPC method in the fictitious netconf.yang module had a node named 'ok' or 'rpc-error' in the output section, then the missing element becomes a problem. Any future common child nodes of would also be problematic. I prefer the YANG mapping to NETCONF to be 100% deterministic, such that any possible QName could be used in the NETCONF content layer. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 07:38: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 84DF23A68C4; Mon, 6 Oct 2008 07:38: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 7356B3A69C1 for ; Mon, 6 Oct 2008 07:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tlr7DdJg0Ce for ; Mon, 6 Oct 2008 07:38:53 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A71F83A68C4 for ; Mon, 6 Oct 2008 07:38:53 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 096492057B; Mon, 6 Oct 2008 16:39:17 +0200 (CEST) X-AuditID: c1b4fb3c-ac0cabb0000015b5-d7-48ea2314b2cc Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E6CBD204DB; Mon, 6 Oct 2008 16:39:16 +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, 6 Oct 2008 16:39:16 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 16:39:15 +0200 Message-ID: <48EA2313.2070900@ericsson.com> Date: Mon, 06 Oct 2008 16:39:15 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka References: <20081003.085450.158213844.mbj@tail-f.com> <1223103308.8412.20.camel@missotis> In-Reply-To: <1223103308.8412.20.camel@missotis> X-OriginalArrivalTime: 06 Oct 2008 14:39:15.0931 (UTC) FILETIME=[4EB33AB0:01C927C1] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] conformance and augment X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka wrote: > Hi, > > 1. Could the functionality of "non-local" top-level augment perhaps be > moved under "deviation"?. It has the same purpose, if I understand it > correctly. BALAZS: NO. Top level conformance is not a deviation it is an extension mechanism. I have a base model, and I want to extend it with some additional stuff that might be proprietary or even standard according to a separate RFC. So augment is NEEDED. Augment does not break the original contract (module definition), deviations usually do. Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 07:40: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 93CE83A6A4B; Mon, 6 Oct 2008 07:40: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 AE8953A69C1 for ; Mon, 6 Oct 2008 07:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.120, 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 JijjjpHDuhZZ for ; Mon, 6 Oct 2008 07:40:01 -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 101023A6932 for ; Mon, 6 Oct 2008 07:40:01 -0700 (PDT) Received: (qmail 3552 invoked from network); 6 Oct 2008 14:40:20 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.69.54 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 6 Oct 2008 14:40:19 -0000 X-YMail-OSG: E77YsCIVM1mV3FP8DkJeLmzCx197HQrv3RwMznvjdhMCLFzjFfB5t5K2YasuGuvS_SYdQDDhDg0nlD6__01RJC7v_5ZCAWGnrqIWp5NN.ESZNmw68enlUlakvBsTw6yDqq7sb5UdNoGULMR_8.VuAwFV X-Yahoo-Newman-Property: ymail-3 Message-ID: <48EA2351.1000709@netconfcentral.com> Date: Mon, 06 Oct 2008 07:40:17 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <48E93096.1020108@netconfcentral.com> <20081005.234331.224733404.mbj@tail-f.com> <48E94E66.3080202@netconfcentral.com> <20081006.093241.33474258.mbj@tail-f.com> In-Reply-To: <20081006.093241.33474258.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] 7.13.4 -- put back the element X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> But without a node within the , >>>> then an application which for whatever reason >>>> wants to return the or elements >>>> cannot do so without them being mis-interpreted. >>> But other rpc's replies will be in some other namespace, so I don't >>> see how these replies will be mis-interpreted as or >>> in the netconf namespace? >>> >> So removing the element is OK because >> nobody is ever allowed to have a YANG module >> that uses the NETCONF namespace? >> >> That should be mentioned in the draft, not just assumed. > > It is stated that all XML elements are in the module's namespace. > >> Removing the element has another impact >> on implementations that choose to generate >> elements inline within a reply. > > I though we said earlier that inline rpc-error was not rfc 4741 > compliant? If it is complient, what are the rules for such inline > errors? Are these rules data modelling language specific? > Turning this around for a second... What problem is solved by removing the element? It saves 13 bytes on the wire? Big deal? In XML terms, that's one drop in the bucket. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 07:43:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC73E3A6932; Mon, 6 Oct 2008 07:43: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 5566B3A6A63 for ; Mon, 6 Oct 2008 07:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PH4xZOEu6mP1 for ; Mon, 6 Oct 2008 07:43:55 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 76D673A6932 for ; Mon, 6 Oct 2008 07:43:55 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8AA3621350; Mon, 6 Oct 2008 16:43:21 +0200 (CEST) X-AuditID: c1b4fb3e-a6680bb000007a96-60-48ea24092c83 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6C6232067A; Mon, 6 Oct 2008 16:43:21 +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, 6 Oct 2008 16:43:20 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 16:43:20 +0200 Message-ID: <48EA2408.3050103@ericsson.com> Date: Mon, 06 Oct 2008 16:43:20 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <200810040301.m9431dLh016060@idle.juniper.net> <48E6F0FD.5070008@netconfcentral.com><20081004.093647.142220504.mbj@tail-f.com> <48E77CE8.5030707@netconfcentral.com> <48E86B3F.5050702@netconfcentral.com> <48E8CA20.5000402@netconfcentral.com> In-Reply-To: <48E8CA20.5000402@netconfcentral.com> X-OriginalArrivalTime: 06 Oct 2008 14:43:20.0761 (UTC) FILETIME=[E0A15290:01C927C1] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: [netmod] Conformance versus limits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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, A simple question/example: If we do not specify the cardinality of a list, the upper bound is infinite. If we allow the device to specify a real limit that is: - good because at least we know what we get - bad because every module will have some deviations, as no one really implements infinity - is not a deviation, because there is no limitation just a resource-temporarily-not-available error :-) always Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 07:44: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 129273A6932; Mon, 6 Oct 2008 07:44: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 396383A67B4 for ; Mon, 6 Oct 2008 07:44:12 -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 FpPVm9rQtR8a for ; Mon, 6 Oct 2008 07:44:08 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 67FAC3A6932 for ; Mon, 6 Oct 2008 07:44:08 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0D9252144E; Mon, 6 Oct 2008 16:43:59 +0200 (CEST) X-AuditID: c1b4fb3e-ab68abb000007a96-bc-48ea242ea9b9 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E3A2221448; Mon, 6 Oct 2008 16:43:58 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 16:43:58 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 16:43:57 +0200 Message-ID: <48EA242D.6080609@ericsson.com> Date: Mon, 06 Oct 2008 16:43:57 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <200810040301.m9431dLh016060@idle.juniper.net> <48E6F0FD.5070008@netconfcentral.com> <20081004.093647.142220504.mbj@tail-f.com> In-Reply-To: <20081004.093647.142220504.mbj@tail-f.com> X-OriginalArrivalTime: 06 Oct 2008 14:43:57.0775 (UTC) FILETIME=[F6B135F0:01C927C1] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] 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 IMHO if you claim conformance you can say: - I claim full conformance- means NO deviations are allowed - I claim partial conformance with the deviations documented in ... Is it so? Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 07:57: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 1594B3A6A4A; Mon, 6 Oct 2008 07:57: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 253623A6A4A for ; Mon, 6 Oct 2008 07:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.874 X-Spam-Level: X-Spam-Status: No, score=-0.874 tagged_above=-999 required=5 tests=[AWL=0.376, 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 bG0GmF8Ge8Ji for ; Mon, 6 Oct 2008 07:57:12 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id AFFE43A6ACD for ; Mon, 6 Oct 2008 07:57:12 -0700 (PDT) Received: from [195.113.228.115] (missotis.w2lan.cesnet.cz [195.113.228.115]) by office2.cesnet.cz (Postfix) with ESMTP id 7BF80D800BD; Mon, 6 Oct 2008 16:57:46 +0200 (CEST) From: Ladislav Lhotka To: Balazs Lengyel In-Reply-To: <48EA2313.2070900@ericsson.com> References: <20081003.085450.158213844.mbj@tail-f.com> <1223103308.8412.20.camel@missotis> <48EA2313.2070900@ericsson.com> Organization: CESNET Date: Mon, 06 Oct 2008 16:57:46 +0200 Message-Id: <1223305066.6327.82.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] conformance and augment X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org QmFsYXpzIExlbmd5ZWwgcMOtxaFlIHYgUG8gMDYuIDEwLiAyMDA4IHYgMTY6MzkgKzAyMDA6Cj4g Cj4gTGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+ID4gSGksCj4gPiAKPiA+IDEuIENvdWxkIHRoZSBm dW5jdGlvbmFsaXR5IG9mICJub24tbG9jYWwiIHRvcC1sZXZlbCBhdWdtZW50IHBlcmhhcHMgYmUK PiA+IG1vdmVkIHVuZGVyICJkZXZpYXRpb24iPy4gSXQgaGFzIHRoZSBzYW1lIHB1cnBvc2UsIGlm IEkgdW5kZXJzdGFuZCBpdAo+ID4gY29ycmVjdGx5Lgo+IEJBTEFaUzogTk8uIFRvcCBsZXZlbCBj b25mb3JtYW5jZSBpcyBub3QgYSBkZXZpYXRpb24gaXQgaXMgYW4gZXh0ZW5zaW9uIG1lY2hhbmlz bS4gSSBoYXZlIGEgCj4gYmFzZSBtb2RlbCwgYW5kIEkgd2FudCB0byBleHRlbmQgaXQgd2l0aCBz b21lIGFkZGl0aW9uYWwgc3R1ZmYgdGhhdCBtaWdodCBiZSBwcm9wcmlldGFyeSBvciAKPiBldmVu IHN0YW5kYXJkIGFjY29yZGluZyB0byBhIHNlcGFyYXRlIFJGQy4gU28gYXVnbWVudCBpcyBORUVE RUQuCj4gQXVnbWVudCBkb2VzIG5vdCBicmVhayB0aGUgb3JpZ2luYWwgY29udHJhY3QgKG1vZHVs ZSBkZWZpbml0aW9uKSwgZGV2aWF0aW9ucyB1c3VhbGx5IGRvLgoKSSBkb24ndCB3YW50IHRvIGFk dm9jYXRlIGRldmlhdGlvbnMsIG15IG1haW4gcG9pbnQgd2FzIHRoYXQgdGhlIHByb3Bvc2VkCm1l Y2hhbmlzbSBob3cgZGV2aWF0aW9ucyBhcmUgYXBwbGllZCBpcyBJTU8gYmV0dGVyIHRoYW4gdGhl IG9uZSBmb3IKbm9uLWxvY2FsIGF1Z21lbnQ6IHRoZSBiYXNlIG1vZHVsZSBpcyBhZHZlcnRpc2Vk IHRvZ2V0aGVyIHdpdGggYSAicGF0Y2gKbW9kdWxlIi4gVGhlIG1vZHVsZSB0aGF0IGF1Z21lbnRz IGEgZm9yZWlnbiBtb2R1bGUgaXMgcHJvYmFibHkgbmV2ZXIKaW50ZW5kZWQgdG8gYmUgdXNlZCB3 aXRob3V0IHRoZSBmb3JlaWduIG1vZHVsZSwgc28gdGhpcyByZWxhdGlvbnNoaXAKc2hvdWxkIGJl IGV4cGxpY2l0bHkgc3RhdGVkLgoKTGFkYQoKPiAKPiBCYWxhenMKLS0gCkxhZGlzbGF2IExob3Rr YSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9y ZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Mon Oct 6 08:07: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 C6F8C3A67B4; Mon, 6 Oct 2008 08:07: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 EEB1D3A69BC for ; Mon, 6 Oct 2008 08:07:28 -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_74=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 zzpqnssPKbFI for ; Mon, 6 Oct 2008 08:07:27 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 88C7E3A67B4 for ; Mon, 6 Oct 2008 08:07:27 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F0CE02055F; Mon, 6 Oct 2008 17:08:02 +0200 (CEST) X-AuditID: c1b4fb3e-ab68abb000007a96-25-48ea29d20ad1 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D1866212E4; Mon, 6 Oct 2008 17:08:02 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 17:08:02 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 17:08:01 +0200 Message-ID: <48EA29D1.1030300@ericsson.com> Date: Mon, 06 Oct 2008 17:08:01 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <48E94E66.3080202@netconfcentral.com> <20081006.093241.33474258.mbj@tail-f.com> <48E9D37F.8050000@netconfcentral.com> <20081006.131300.172045470.mbj@tail-f.com> <48EA22E2.3010806@netconfcentral.com> In-Reply-To: <48EA22E2.3010806@netconfcentral.com> X-OriginalArrivalTime: 06 Oct 2008 15:08:01.0883 (UTC) FILETIME=[53729AB0:01C927C5] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] 7.13.4 -- put back the element X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, When we send the rpc-reply - Can we send back both an rfc4741 error and the output parameters? IMHO yes, as this is needed for partial errors - Can we send back both an rfc4741 OK and the output parameters? IMHO this should be specified, but I don't care, maybe no. Or if there is anything defined in for the rpc output, then rfc4741 OK or the rfc4741 standard errors are unusable? Actually I like Andy's idea, using the node answers all these questions. All output parameters would be encoded inside the data element. Balazs Andy Bierman wrote: > Martin Bjorklund wrote: >> Andy Bierman wrote: >>> The draft mentions that the namespace URI defined by RFC 4741 >>> is reserved and can not ever be used in a YANG module? >> >> No of course not. It would be very useful if we had a netconf.yang >> module published. The operation could be something like: >> >> rpc get { >> input { >> anyxml filter; >> } >> output { >> anyxml data; >> } >> } >> > > What about the element? > What about the element? > If any RPC method in the fictitious netconf.yang module > had a node named 'ok' or 'rpc-error' in the output section, > then the missing element becomes a problem. > Any future common child nodes of would > also be problematic. > > I prefer the YANG mapping to NETCONF to be 100% deterministic, > such that any possible QName could be used in the NETCONF content > layer. > >> >> >> /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 Mon Oct 6 08:30:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D56C93A6AE0; Mon, 6 Oct 2008 08:30:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C15E83A6AE0 for ; Mon, 6 Oct 2008 08:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.231 X-Spam-Level: X-Spam-Status: No, score=-6.231 tagged_above=-999 required=5 tests=[AWL=0.018, 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 gGL8PuXEzpX4 for ; Mon, 6 Oct 2008 08:30:56 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 6852528C1FB for ; Mon, 6 Oct 2008 08:30:25 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BC0FB20FE2; Mon, 6 Oct 2008 17:31:00 +0200 (CEST) X-AuditID: c1b4fb3e-a6680bb000007a96-b2-48ea2f34b99d Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 94618207AB; Mon, 6 Oct 2008 17:31:00 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 17:31:00 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 17:30:59 +0200 Message-ID: <48EA2F33.6060408@ericsson.com> Date: Mon, 06 Oct 2008 17:30:59 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <200810040301.m9431dLh016060@idle.juniper.net> <48E6F0FD.5070008@netconfcentral.com><20081004.093647.142220504.mbj@tail-f.com> <48E77CE8.5030707@netconfcentral.com> <48E86B3F.5050702@netconfcentral.com> <48E8CA20.5000402@netconfcentral.com> In-Reply-To: <48E8CA20.5000402@netconfcentral.com> X-OriginalArrivalTime: 06 Oct 2008 15:30:59.0531 (UTC) FILETIME=[889701B0:01C927C8] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, IMHO by using the same statements in base YANG and inside the deviation statement the rules become understandable. However what is the difference between not-supported and delete in deviations. In both cases the addressed statement is considered to be non-existent, as I understand. Balazs Andy Bierman wrote: > Romascanu, Dan (Dan) wrote: >> >> >>> -----Original Message----- >>> From: Andy Bierman [mailto:andy@netconfcentral.com] If the agent >>> could replace a standard leaf with a proprietary leaf in such a way >>> that the derivation-stmt could solve the variation, then why can't >>> the agent implement the standard leaf correctly, and simply translate >>> the proprietary leaf into the standard leaf within the agent itself? >>> Why move that automatic translation to the manager? If it isn't >>> automatic, then it isn't any better than the DESCRIPTION clause >>> approach we have now. >>> >>> >>>> Dan >>> Andy >>> >> >> Let me try to answer with a couple of examples based on my experience >> with AGENT-CAPABILITIES (allow me to acronym this by A-C). I should say >> that in the old days many vendors were reluctant to use A-C because it >> was documenting their holes in implementations that were supposed to >> claim standards compliance. This should be made even more clear and >> crisp if we do agree to define something like this in YANG. One of the >> reasons in SMI we used A-C was that agents were dealing with sub-agents >> that were not under their control and came with their own variants that >> had to be dealt with and exposed to managers using SMUX or Emanate or >> AGENTX. In such cases a manager could deal with situations like 'in this >> enumerated object only five of the seven enumerated values are >> implemented, but we added this other three' and 'I am not implementing >> this standard knob, but my older proprietary knob with identical >> semantics'. > > If the YANG proposal was constrained like AGENT-CAPABILITIES, > then I would not object to it. It is one thing to implement > the range 1-8 when the real knob is 1-10, or subset the > number of buffers requested. It is quite another to replace > the standard knob when N vendor knobs that may or may not > have anything to do with the original semantics. > > >> Dan >> >> >> > > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 08:47: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 001093A6AD2; Mon, 6 Oct 2008 08:47: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 41F913A688C for ; Mon, 6 Oct 2008 08:47:50 -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 ORFIuTfqR24d for ; Mon, 6 Oct 2008 08:47:44 -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 B93F128C1B7 for ; Mon, 6 Oct 2008 08:47:44 -0700 (PDT) Received: (qmail 93689 invoked from network); 6 Oct 2008 15:48:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.69.54 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 6 Oct 2008 15:48:02 -0000 X-YMail-OSG: DeMeeO4VM1mknfHVFuSR1ALOR2p9fxoKkIcQpqwwn6yqVA7Z924gjjJ5YITVx.za0ssExcbiLKKAHDeLpyQQdWa26MOQvgXAL_VfYQhmUSzv7kTBPUiQ_wTp.c_w6sEGjcFB.dIre7nOVdbXvOkJmgfJ X-Yahoo-Newman-Property: ymail-3 Message-ID: <48EA3330.2000703@netconfcentral.com> Date: Mon, 06 Oct 2008 08:48:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Balazs Lengyel References: <200810040301.m9431dLh016060@idle.juniper.net> <48E6F0FD.5070008@netconfcentral.com><20081004.093647.142220504.mbj@tail-f.com> <48E77CE8.5030707@netconfcentral.com> <48E86B3F.5050702@netconfcentral.com> <48E8CA20.5000402@netconfcentral.com> <48EA2F33.6060408@ericsson.com> In-Reply-To: <48EA2F33.6060408@ericsson.com> Cc: netmod@ietf.org Subject: Re: [netmod] 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 Balazs Lengyel wrote: > Hello, > IMHO by using the same statements in base YANG and inside the deviation > statement the rules become understandable. > There is a big difference between using compatible syntax and having the deviation-stmt inside the YANG module. Most vendors understand that maintaining the platform-specific and even platform/version/hw-option specific deviations is best done with separate files, rather than polluting the data model source file. I agree that a mechanism similar to AGENT-CAPABILITIES, but better, would help YANG deployment. I also think the IETF needs to take a real hard look at how it thinks standards-based configuration management is supposed to work. Without that common understanding, arguing over the details of this proposal is mostly worthless. There is a huge difference between a missing or restricted knob, and an architecture that presumes to patch and plug the API with a secondary transform layer. If each implementor of the ipfix-psamp data model can decide they do not like the 'tcpReceiver' container that the WG defined, so they replace it with their own 'acmeTcpSuperRcv' container -- I just don't see the standards value in that. I see standards value preserved in the old school AUGMENT model, but not this one. > However what is the difference between not-supported and delete in > deviations. In both cases the addressed statement is considered to be > non-existent, as I understand. > Balazs Andy > > Andy Bierman wrote: >> Romascanu, Dan (Dan) wrote: >>> >>> >>>> -----Original Message----- >>>> From: Andy Bierman [mailto:andy@netconfcentral.com] If the agent >>>> could replace a standard leaf with a proprietary leaf in such a way >>>> that the derivation-stmt could solve the variation, then why can't >>>> the agent implement the standard leaf correctly, and simply >>>> translate the proprietary leaf into the standard leaf within the >>>> agent itself? Why move that automatic translation to the manager? >>>> If it isn't automatic, then it isn't any better than the DESCRIPTION >>>> clause approach we have now. >>>> >>>> >>>>> Dan >>>> Andy >>>> >>> >>> Let me try to answer with a couple of examples based on my experience >>> with AGENT-CAPABILITIES (allow me to acronym this by A-C). I should say >>> that in the old days many vendors were reluctant to use A-C because it >>> was documenting their holes in implementations that were supposed to >>> claim standards compliance. This should be made even more clear and >>> crisp if we do agree to define something like this in YANG. One of the >>> reasons in SMI we used A-C was that agents were dealing with sub-agents >>> that were not under their control and came with their own variants that >>> had to be dealt with and exposed to managers using SMUX or Emanate or >>> AGENTX. In such cases a manager could deal with situations like 'in this >>> enumerated object only five of the seven enumerated values are >>> implemented, but we added this other three' and 'I am not implementing >>> this standard knob, but my older proprietary knob with identical >>> semantics'. >> >> If the YANG proposal was constrained like AGENT-CAPABILITIES, >> then I would not object to it. It is one thing to implement >> the range 1-8 when the real knob is 1-10, or subset the >> number of buffers requested. It is quite another to replace >> the standard knob when N vendor knobs that may or may not >> have anything to do with the original semantics. >> >> >>> Dan >>> >>> >>> >> >> Andy >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 09:24: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 DDBC73A6811; Mon, 6 Oct 2008 09:24: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 D6D4A3A6970 for ; Mon, 6 Oct 2008 09:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzzjPxHqa07i for ; Mon, 6 Oct 2008 09:24:15 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id BCCE43A6811 for ; Mon, 6 Oct 2008 09:24:13 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Mon, 06 Oct 2008 09:23:44 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Oct 2008 09:23:44 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Oct 2008 09:23:44 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Oct 2008 09:23: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 m96GNhM59709; Mon, 6 Oct 2008 09:23: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 m96GJReG029192; Mon, 6 Oct 2008 16:19:27 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200810061619.m96GJReG029192@idle.juniper.net> To: Andy Bierman In-reply-to: <48EA3330.2000703@netconfcentral.com> Date: Mon, 06 Oct 2008 12:19:27 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 Oct 2008 16:23:44.0116 (UTC) FILETIME=[E6D45B40:01C927CF] Cc: netmod@ietf.org Subject: Re: [netmod] 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: , 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: >Most vendors understand that maintaining the platform-specific >and even platform/version/hw-option specific deviations is >best done with separate files, rather than polluting the >data model source file. I think you are missing something here. A vendors doesn't change the data model source file. They publish their deviations in a distinct vendor-specific module. Trying to republish a standard module is unworkable, as is having the standard modeler track all vendor deviations. Instead, we have the vendor publish a distinct module containing their deviations, and have a mechanism for attaching these modules to the base module via the message. Please reread the spec and let me know if this isn't clear. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 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 082873A6811; Mon, 6 Oct 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 F20CA3A6A27 for ; Mon, 6 Oct 2008 09:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[AWL=-2.714, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_29=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jh9flUdURQz3 for ; Mon, 6 Oct 2008 09:24:43 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 46F883A6811 for ; Mon, 6 Oct 2008 09:24:43 -0700 (PDT) Received: (qmail 3153 invoked from network); 6 Oct 2008 16:25:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.69.54 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 6 Oct 2008 16:25:03 -0000 X-YMail-OSG: BbldK8UVM1nXaMemvPsWMgPbwEPCw0N2XBn0Pta5muXEjl_BwLbqualWl1a2hg.WwemX_S8M49MoW3r6lCs6Auu9eWBbQs9w.jP3P1WS.K7j99jSinDN7wLJ_c8vproFkZ19ItRr_s6E8A2SQsVC67CK X-Yahoo-Newman-Property: ymail-3 Message-ID: <48EA3BDD.5040605@netconfcentral.com> Date: Mon, 06 Oct 2008 09:25:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Ladislav Lhotka References: <48E94E66.3080202@netconfcentral.com> <20081006.093241.33474258.mbj@tail-f.com> <48E9D37F.8050000@netconfcentral.com> <20081006.131300.172045470.mbj@tail-f.com> <1223292223.6327.32.camel@missotis> In-Reply-To: <1223292223.6327.32.camel@missotis> Content-Type: multipart/mixed; boundary="------------010000030904030503050101" Cc: netmod@ietf.org Subject: Re: [netmod] 7.13.4 -- put back the element X-BeenThere: netmod@ietf.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. --------------010000030904030503050101 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Ladislav Lhotka wrote: > Martin Bjorklund píše v Po 06. 10. 2008 v 13:13 +0200: >> Andy Bierman wrote: >>> The draft mentions that the namespace URI defined by RFC 4741 >>> is reserved and can not ever be used in a YANG module? >> No of course not. It would be very useful if we had a netconf.yang > > But can it be done? For one, YANG cannot model XML attributes. > I use an extension called 'metadata' for that. At first I hated the extension-stmt, now I think it's one of the best parts of YANG. I use the attached netconf.yang file in my data-driven tools. (Warning: may not be 100% debugged yet. It won't compile without the other modules too.) I want to be able to use the same 'rpc-reply' container for every RPC message, and not generate a 'foo-rpc-reply' container for every RPC method. The stable anyxml 'data' node is very useful for handling the RPC reply in a centralized dispatcher. I think the NETCONF WG got it right by clearing identifying the content payload in the . I no longer agree with the recent interpretation that the node in the XSD just applies to the RPC methods in RFC 4741. The WG clearly intended to create an XSD that applies to all RPCs. In order to represent the new rpc-reply in YANG, you would have the useless construct: anyxml rpc-reply { config false; } > Lada Andy > >> module published. The operation could be something like: >> >> rpc get { >> input { >> anyxml filter; >> } >> output { >> anyxml data; >> } >> } >> >> >> >> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod --------------010000030904030503050101 Content-Type: text/plain; name="netconf.yang" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="netconf.yang" bW9kdWxlIG5ldGNvbmYgewoKICAgbmFtZXNwYWNlICJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5z Om5ldGNvbmY6YmFzZToxLjAiOwoKICAgcHJlZml4ICJuYyI7CgogICAvLyBmb3IgWFNEIHR5 cGVzIGxpa2UgYW55VVJJCiAgIGltcG9ydCB4c2QgeyBwcmVmaXggInhzIjsgfQoKICAgLy8g Zm9yIE5DWCAnbWV0YWRhdGEnIGxhbmd1YWdlIGV4dGVuc2lvbgogICBpbXBvcnQgbmN4IHsg cHJlZml4ICJuY3giOyB9CgogICBkZXNjcmlwdGlvbiAKICAgICAgIk5FVENPTkYgUHJvdG9j b2wgCiAgICAgICAgKiBEYXRhIFR5cGVzCiAgICAgICAgKiBBYnN0cmFjdCBvYmplY3QgZm9y IFBEVSBjb21wb25lbnRzCiAgICAgICAgKiBSUENzCiAgICAgICBUcmFuc2xhdGVkIGZyb20g UkZDIDQ3NDEuIjsKCiAgIGNvbnRhY3QKICAgICAiVHJhbnNsYXRlZCBieSBBbmR5IEJpZXJt YW4uCiAgICAgIFNlbmQgY29tbWVudHMgdG8gPGFuZHlAbmV0Y29uZmNlbnRyYWwuY29tPi4i OwoKICAgcmV2aXNpb24gIjIwMDgtMDgtMzAiIHsKICAgICBkZXNjcmlwdGlvbiAKICAgICAg ICJBZGQgc29tZSBOQ1ggZXh0ZW5zaW9ucyB0byBhdXRvbWF0ZSBzb21lIGFnZW50IHByb2Nl c3NpbmcuIjsKICAgfQoKICAgcmV2aXNpb24gIjIwMDgtMDQtMjYiIHsKICAgICBkZXNjcmlw dGlvbiAKICAgICAgICJDaGFuZ2UgZ2V0LWNvbmZpZyBhbmQgZ2V0IG91dHB1dCBmcm9tICdj b25maWcnIHRvICdkYXRhJy4iOwogICB9CgogICByZXZpc2lvbiAiMjAwOC0wNC0xNiIgewog ICAgIGRlc2NyaXB0aW9uIAogICAgICAgIkluaXRpYWwgY29udmVyc2lvbiBmcm9tIG5ldGNv bmYubmN4IHZlcnNpb24gMC42LiI7CiAgIH0KCiAgIC8vIE5FVENPTkYgU2ltcGxlIFR5cGVz CgogICB0eXBlZGVmIExhbmd1YWdlIHsKICAgICBkZXNjcmlwdGlvbiAiWE1MIGxhbmd1YWdl IHR5cGUgZm9yIExhbmdTdHJpbmciOwogICAgIHR5cGUgc3RyaW5nIHsKICAgICAgIHBhdHRl cm4gJ1thLXpBLVpdezEsOH0oLVthLXpBLVowLTldezEsOH0pKic7CiAgICAgfQogICB9Cgog ICB0eXBlZGVmIFNlc3Npb25JZCB7CiAgICAgZGVzY3JpcHRpb24gIk5FVENPTkYgU2Vzc2lv biBJZCI7CiAgICAgdHlwZSB1aW50MzIgewogICAgICAgcmFuZ2UgIjEuLm1heCI7IAogICAg IH0KICAgfQoKICAgdHlwZWRlZiBTZXNzaW9uSWRPclplcm8gewogICAgIGRlc2NyaXB0aW9u IAogICAgICAgIk5FVENPTkYgU2Vzc2lvbiBJZCBvciBaZXJvIHRvIGluZGljYXRlIG5vbmUi OwogICAgIHR5cGUgdWludDMyOyAKICAgfQoKICAgdHlwZWRlZiBMYW5nU3RyaW5nIHsKICAg ICBkZXNjcmlwdGlvbiAiWE1MIHN0cmluZyB3aXRoIGEgbGFuZ3VhZ2UgYXR0cmlidXRlLiI7 CiAgICAgdHlwZSBzdHJpbmc7CiAgICAgbmN4Om1ldGFkYXRhICJMYW5ndWFnZSBsYW5nIjsK ICAgfQoKICAgdHlwZWRlZiBNZXNzYWdlSWQgewogICAgIGRlc2NyaXB0aW9uICJORVRDT05G IG1lc3NhZ2UtaWQgYXR0cmlidXRlIjsKICAgICB0eXBlICBzdHJpbmcgewogICAgICAgIGxl bmd0aCAiMS4uNDA5NSI7CiAgICAgfQogICB9CgogICB0eXBlZGVmIEVycm9yVHlwZSB7CiAg ICAgZGVzY3JpcHRpb24gIk5FVENPTkYgRXJyb3IgVHlwZSI7CiAgICAgdHlwZSBlbnVtZXJh dGlvbiB7CiAgICAgICBlbnVtIHRyYW5zcG9ydDsKICAgICAgIGVudW0gcnBjOwogICAgICAg ZW51bSBwcm90b2NvbDsKICAgICAgIGVudW0gYXBwbGljYXRpb247CiAgICAgfQogICB9Cgog ICB0eXBlZGVmIEVycm9yVGFnIHsKICAgICBkZXNjcmlwdGlvbiAiTkVUQ09ORiBFcnJvciBU YWciOwogICAgIHR5cGUgZW51bWVyYXRpb24geyAKICAgICAgIGVudW0gaW4tdXNlOwogICAg ICAgZW51bSBpbnZhbGlkLXZhbHVlOwogICAgICAgZW51bSB0b28tYmlnOwogICAgICAgZW51 bSBtaXNzaW5nLWF0dHJpYnV0ZTsKICAgICAgIGVudW0gYmFkLWF0dHJpYnV0ZTsKICAgICAg IGVudW0gdW5rbm93bi1hdHRyaWJ1dGU7CiAgICAgICBlbnVtIG1pc3NpbmctZWxlbWVudDsK ICAgICAgIGVudW0gYmFkLWVsZW1lbnQ7CiAgICAgICBlbnVtIHVua25vd24tZWxlbWVudDsK ICAgICAgIGVudW0gdW5rbm93bi1uYW1lc3BhY2U7CiAgICAgICBlbnVtIGFjY2Vzcy1kZW5p ZWQ7CiAgICAgICBlbnVtIGxvY2stZGVuaWVkOwogICAgICAgZW51bSByZXNvdXJjZS1kZW5p ZWQ7CiAgICAgICBlbnVtIHJvbGxiYWNrLWZhaWxlZDsKICAgICAgIGVudW0gZGF0YS1leGlz dHM7CiAgICAgICBlbnVtIGRhdGEtbWlzc2luZzsKICAgICAgIGVudW0gb3BlcmF0aW9uLW5v dC1zdXBwb3J0ZWQ7CiAgICAgICBlbnVtIG9wZXJhdGlvbi1mYWlsZWQ7CiAgICAgICBlbnVt IHBhcnRpYWwtb3BlcmF0aW9uOwogICAgIH0KICAgfQoKICAgdHlwZWRlZiBFcnJvclNldmVy aXR5IHsKICAgICBkZXNjcmlwdGlvbiAiTkVUQ09ORiBFcnJvciBTZXZlcml0eSI7CiAgICAg dHlwZSBlbnVtZXJhdGlvbiB7IAogICAgICAgZW51bSBlcnJvcjsKICAgICAgIGVudW0gd2Fy bmluZzsKICAgICB9CiAgIH0KCiAgIHR5cGVkZWYgVGVzdE9wdGlvblR5cGUgewogICAgIGRl c2NyaXB0aW9uIAogICAgICAgIk5FVENPTkYgJ3Rlc3Qtb3B0aW9uJyBFbGVtZW50IENvbnRl bnQuCiAgICAgICAgVGhpcyBpcyBleHRlbmRlZCB3aXRoIHRoZSB0ZXN0LW9ubHkgZW51bWVy YXRpb24uCiAgICAgICAgVGhlICdzZXQnIG9wdGlvbiBoYXMgbm8gcmVhbCBlZmZlY3Qgc2lu Y2UKICAgICAgICB0aGUgZW50aXJlIFBEVSBpcyBhbHdheXMgdmFsaWRhdGVkIGJlZm9yZSBh bnkKICAgICAgICBvZiBpdCBpcyBhcHBsaWVkIChhbHdheXMgdGVzdC10aGVuLXNldCkuIjsK ICAgICB0eXBlIGVudW1lcmF0aW9uIHsKICAgICAgIGVudW0gdGVzdC10aGVuLXNldDsKICAg ICAgIGVudW0gc2V0OwogICAgICAgZW51bSB0ZXN0LW9ubHk7CiAgICAgfQogICAgIGRlZmF1 bHQgInNldCI7CiAgIH0KCiAgIHR5cGVkZWYgRXJyb3JPcHRpb25UeXBlIHsKICAgICBkZXNj cmlwdGlvbiAiTkVUQ09ORiAnZXJyb3Itb3B0aW9uJyBFbGVtZW50IENvbnRlbnQiOwogICAg IHR5cGUgZW51bWVyYXRpb24geyAKICAgICAgIGVudW0gc3RvcC1vbi1lcnJvcjsKICAgICAg IGVudW0gY29udGludWUtb24tZXJyb3I7CiAgICAgICBlbnVtIHJvbGxiYWNrLW9uLWVycm9y OwogICAgIH0KICAgICBkZWZhdWx0ICJzdG9wLW9uLWVycm9yIjsKICAgfQoKICAgdHlwZWRl ZiBGaWx0ZXJUeXBlIHsKICAgICBkZXNjcmlwdGlvbiAiTkVUQ09ORiAnZmlsdGVyJyBBdHRy aWJ1dGUgQ29udGVudCI7CiAgICAgdHlwZSBlbnVtZXJhdGlvbiB7CiAgICAgICBlbnVtIHN1 YnRyZWU7CiAgICAgICBlbnVtIHhwYXRoOwogICAgIH0KICAgICBkZWZhdWx0ICJzdWJ0cmVl IjsKICAgfQoKICAgdHlwZWRlZiBFZGl0T3BlcmF0aW9uVHlwZSB7CiAgICAgZGVzY3JpcHRp b24gIk5FVENPTkYgJ29wZXJhdGlvbicgQXR0cmlidXRlIENvbnRlbnQiOwogICAgIHR5cGUg ZW51bWVyYXRpb24geyAKICAgICAgIGVudW0gbWVyZ2U7CiAgICAgICBlbnVtIHJlcGxhY2U7 CiAgICAgICBlbnVtIGNyZWF0ZTsKICAgICAgIGVudW0gZGVsZXRlOwogICAgIH0KICAgICBk ZWZhdWx0ICJtZXJnZSI7CiAgIH0KCiAgIHR5cGVkZWYgRGVmYXVsdE9wZXJhdGlvblR5cGUg ewogICAgIGRlc2NyaXB0aW9uICJORVRDT05GICdkZWZhdWx0LW9wZXJhdGlvbicgRWxlbWVu dCBDb250ZW50IjsKICAgICB0eXBlIGVudW1lcmF0aW9uIHsgCiAgICAgICBlbnVtIG1lcmdl OwogICAgICAgZW51bSByZXBsYWNlOwogICAgICAgZW51bSBub25lOwogICAgIH0KICAgICBk ZWZhdWx0ICJtZXJnZSI7CiAgIH0KCiAgIHR5cGVkZWYgQ29uZmlybVRpbWVvdXRUeXBlIHsK ICAgICBkZXNjcmlwdGlvbiAKICAgICAgICJORVRDT05GICdjb25maXJtLXRpbWVvdXQnIEVs ZW1lbnQgQ29udGVudCI7CiAgICAgdHlwZSB1aW50MzIgeyAKICAgICAgIHJhbmdlICIxLi5t YXgiOwogICAgIH0KICAgICB1bml0cyAic2Vjb25kcyI7CiAgICAgZGVmYXVsdCAiNjAwIjsg ICAvLyAxMCBtaW51dGVzCiAgIH0KCiAgIHR5cGVkZWYgQ29uZmlnVVJJVHlwZSB7CiAgICAg dHlwZSB4czphbnlVUkk7CiAgIH0KCiAgIC8vIE5FVENPTkYgSGVsbG8gUERVIERhdGEgVHlw ZXMKICAgIAogICBncm91cGluZyBOY0NhcGFiaWxpdGllcyB7CiAgICAgZGVzY3JpcHRpb24g IkdlbmVyaWMgQ2FwYWJpbGl0aWVzIExpc3QuIjsKCiAgICAgY29udGFpbmVyIGNhcGFiaWxp dGllcyB7IAogICAgICAgY29uZmlnIGZhbHNlOwogICAgICAgbGVhZi1saXN0IGNhcGFiaWxp dHkgewogICAgICAgICAgZGVzY3JpcHRpb24gIk9uZSBHZW5lcmljIENhcGFiaWxpdHkgVVJJ LiI7CiAgICAgICAgICB0eXBlIHhzOmFueVVSSTsKICAgICAgIH0KICAgICB9CiAgIH0KCiAg IGNvbnRhaW5lciBhZ2VudC1oZWxsbyB7CiAgICAgZGVzY3JpcHRpb24gIkdlbmVyaWMgQWdl bnQgSGVsbG8gTWVzc2FnZSBQYXJhbWV0ZXJzLiI7CgogICAgIHVzZXMgTmNDYXBhYmlsaXRp ZXM7CgogICAgIGxlYWYgc2Vzc2lvbi1pZCB7CiAgICAgICAgdHlwZSBTZXNzaW9uSWQ7CiAg ICAgICAgY29uZmlnIGZhbHNlOwogICAgIH0KCiAgICAgbmN4OmhpZGRlbjsKICAgICBuY3g6 YWJzdHJhY3Q7CiAgIH0KCiAgIGNvbnRhaW5lciBtZ3ItaGVsbG8gewoKICAgICBkZXNjcmlw dGlvbiAiR2VuZXJpYyBNYW5hZ2VyIEhlbGxvIE1lc3NhZ2UgUGFyYW1ldGVycy4iOwoKICAg ICB1c2VzIE5jQ2FwYWJpbGl0aWVzOwoKICAgICBuY3g6aGlkZGVuOwogICAgIG5jeDphYnN0 cmFjdDsKICAgfQoKICAgLy8gTkVUQ09ORiBPcGVyYXRpb25zIFBEVSBEYXRhIFR5cGVzCgog ICBncm91cGluZyBFcnJvckluZm9Db250ZW50IHsKICAgICBkZXNjcmlwdGlvbiAKICAgICAg ICJORVRDT05GIHN0YW5kYXJkICdlcnJvci1pbmZvJyBFbGVtZW50IENvbnRlbnQ7IjsKCiAg ICAgbGVhZi1saXN0IGJhZC1hdHRyaWJ1dGUgewogICAgICAgZGVzY3JpcHRpb24KICAgICAg ICAgIk5hbWUgb2YgdGhlIG1pc3Npbmcgb3IgaW52YWxpZCBYU0QgYXR0cmlidXRlLgogICAg ICAgICAgVXNlZCB3aXRoIG1pc3NpbmctYXR0cmlidXRlLCBiYWQtYXR0cmlidXRlLCBhbmQK ICAgICAgICAgIHVua25vd24tYXR0cmlidXRlIGVycm9yLXRhZyB2YWx1ZXMuIjsKICAgICAg IHR5cGUgICB4czpRTmFtZTsKICAgICAgIGNvbmZpZyBmYWxzZTsKICAgICB9CgogICAgIGxl YWYtbGlzdCBiYWQtZWxlbWVudCB7CiAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAiTmFt ZSBvZiB0aGUgZWxlbWVudCB0aGF0IGNvbnRhaW5zIChvciBzaG91bGQgY29udGFpbikKICAg ICAgICAgIGFuIGludmFsaWQgWFNEIGF0dHJpYnV0ZSB3aGVuIHVzZWQgd2l0aCBtaXNzaW5n LWF0dHJpYnV0ZSwKICAgICAgICAgIGJhZC1hdHRyaWJ1dGUsIHVua25vd24tYXR0cmlidXRl LCBlcnJvci10YWcgdmFsdWVzLgogICAgICAgICAgTmFtZSBvZiBhbiBpbnZhbGlkIG9yIG1p c3NpbmcgZWxlbWVudCB3aGVuIHVzZWQgd2l0aAogICAgICAgICAgdGhlbiBtaXNzaW5nLWVs ZW1lbnQsIGJhZC1lbGVtZW50LCB1bmtub3duLWVsZW1lbnQsCiAgICAgICAgICBhbmQgdW5r bm93bi1uYW1lc3BhY2UgZXJyb3ItdGFnIHZhbHVlcy4iOwogICAgICAgdHlwZSAgIHhzOlFO YW1lOwogICAgICAgY29uZmlnIGZhbHNlOwogICAgIH0KCiAgICAgbGVhZi1saXN0IG9rLWVs ZW1lbnQgewogICAgICAgZGVzY3JpcHRpb24gCiAgICAgICAgICJJZGVudGlmaWVzIGFuIGVs ZW1lbnQgaW4gdGhlIGRhdGEgbW9kZWwKICAgICAgICAgIGZvciB3aGljaCB0aGUgcmVxdWVz dGVkIG9wZXJhdGlvbiBoYXMgYmVlbiBjb21wbGV0ZWQKICAgICAgICAgIGZvciB0aGF0IG5v ZGUgYW5kIGFsbCBpdHMgY2hpbGQgbm9kZXMuICBUaGlzIGVsZW1lbnQKICAgICAgICAgIGNh biBhcHBlYXIgemVybyBvciBtb3JlIHRpbWVzIGluIHRoZSAnZXJyb3ItaW5mbycKICAgICAg ICAgIGNvbnRhaW5lci4gIFVzZWQgd2l0aCB0aGUgcGFydGlhbC1vcGVyYXRpb24gZXJyb3It dGFnCiAgICAgICAgICB2YWx1ZS4iOwogICAgICAgdHlwZSAgIHhzOlFOYW1lOwogICAgICAg Y29uZmlnIGZhbHNlOwogICAgIH0KCiAgICAgbGVhZi1saXN0IGVyci1lbGVtZW50IHsKICAg ICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICJJZGVudGlmaWVzIGFuIGVsZW1lbnQgaW4gdGhl IGRhdGEgbW9kZWwKICAgICAgICAgIGZvciB3aGljaCB0aGUgcmVxdWVzdGVkIG9wZXJhdGlv biBoYXMgZmFpbGVkIGZvciB0aGF0CiAgICAgICAgICBub2RlIGFuZCBhbGwgaXRzIGNoaWxk IG5vZGVzLiAgVGhpcyBlbGVtZW50CiAgICAgICAgICBjYW4gYXBwZWFyIHplcm8gb3IgbW9y ZSB0aW1lcyBpbiB0aGUgJ2Vycm9yLWluZm8nCiAgICAgICAgICBjb250YWluZXIuICAgVXNl ZCB3aXRoIHRoZSBwYXJ0aWFsLW9wZXJhdGlvbiBlcnJvci10YWcKICAgICAgICAgIHZhbHVl LiI7CiAgICAgICAgdHlwZSAgIHhzOlFOYW1lOwogICAgICAgIGNvbmZpZyBmYWxzZTsKICAg ICAgfQoKICAgICAgbGVhZi1saXN0IG5vb3AtZWxlbWVudCB7CiAgICAgICAgZGVzY3JpcHRp b24KICAgICAgICAgICJJZGVudGlmaWVzIGFuIGVsZW1lbnQgaW4gdGhlIGRhdGEgbW9kZWwK ICAgICAgICAgICBmb3Igd2hpY2ggdGhlIHJlcXVlc3RlZCBvcGVyYXRpb24gd2FzIG5vdCBh dHRlbXB0ZWQgZm9yCiAgICAgICAgICAgdGhhdCBub2RlIGFuZCBhbGwgaXRzIGNoaWxkIG5v ZGVzLiAgVGhpcyBlbGVtZW50CiAgICAgICAgICAgY2FuIGFwcGVhciB6ZXJvIG9yIG1vcmUg dGltZXMgaW4gdGhlIDxlcnJvci1pbmZvPgogICAgICAgICAgIGNvbnRhaW5lci4gICBVc2Vk IHdpdGggdGhlIHBhcnRpYWwtb3BlcmF0aW9uIGVycm9yLXRhZwogICAgICAgICAgIHZhbHVl LiI7CiAgICAgICAgdHlwZSAgIHhzOlFOYW1lOwogICAgICAgIGNvbmZpZyBmYWxzZTsKICAg ICAgfQoKICAgICAgbGVhZiBzZXNzaW9uLWlkIHsKICAgICAgIGRlc2NyaXB0aW9uCiAgICAg ICAgICJTZXNzaW9uIElEIG9mIHNlc3Npb24gaG9sZGluZyB0aGUKICAgICAgICAgIHJlcXVl c3RlZCBsb2NrLCBvciB6ZXJvIHRvIGluZGljYXRlIGEgbm9uLU5FVENPTkYKICAgICAgICAg IGVudGl0eSBob2xkcyB0aGUgbG9jay4iOwogICAgICAgIHR5cGUgU2Vzc2lvbklkT3JaZXJv OwogICAgICAgIGNvbmZpZyBmYWxzZTsKICAgICAgfQogICB9CgogICBncm91cGluZyBScGNF cnJvclR5cGUgewogICAgICBkZXNjcmlwdGlvbiAiTkVUQ09ORiAncnBjLWVycm9yJyBFbGVt ZW50IENvbnRlbnQiOwoKICAgICAgbGVhZiBlcnJvci10eXBlIHsKICAgICAgICBkZXNjcmlw dGlvbiAKICAgICAgICAgICJEZWZpbmVzIHRoZSBjb25jZXB0dWFsIGxheWVyIHRoYXQgdGhl IGVycm9yIG9jY3VycmVkLiI7CiAgICAgICAgdHlwZSBFcnJvclR5cGU7CiAgICAgICAgbWFu ZGF0b3J5IHRydWU7CiAgICAgIH0KCiAgICAgIGxlYWYgZXJyb3ItdGFnIHsKICAgICAgICBk ZXNjcmlwdGlvbgogICAgICAgICAgIkNvbnRhaW5zIGEgc3RyaW5nIGlkZW50aWZ5aW5nIHRo ZSBlcnJvciBjb25kaXRpb24uIjsKICAgICAgICB0eXBlIEVycm9yVGFnOwogICAgICAgIG1h bmRhdG9yeSB0cnVlOwogICAgICB9CgogICAgICBsZWFmIGVycm9yLXNldmVyaXR5IHsKICAg ICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgIkNvbnRhaW5zIGEgc3RyaW5nIGlkZW50aWZ5 aW5nIHRoZSBlcnJvciBzZXZlcml0eSwgYXMKICAgICAgICAgICBkZXRlcm1pbmVkIGJ5IHRo ZSBkZXZpY2UuIjsKICAgICAgICB0eXBlIEVycm9yU2V2ZXJpdHk7CiAgICAgICAgbWFuZGF0 b3J5IHRydWU7CiAgICAgIH0KCiAgICAgIGxlYWYgZXJyb3ItYXBwLXRhZyB7CiAgICAgICAg ZGVzY3JpcHRpb24KICAgICAgICAgICJDb250YWlucyBhIHN0cmluZyBpZGVudGlmeWluZyB0 aGUgZGF0YS1tb2RlbC1zcGVjaWZpYwogICAgICAgICAgIG9yIGltcGxlbWVudGF0aW9uLXNw ZWNpZmljIGVycm9yIGNvbmRpdGlvbiwgaWYgb25lIGV4aXN0cy4KICAgICAgICAgICBUaGlz IGVsZW1lbnQgd2lsbCBub3QgYmUgcHJlc2VudCBpZiBubyBhcHByb3ByaWF0ZSAKICAgICAg ICAgICBhcHBsaWNhdGlvbiBlcnJvciB0YWcgY2FuIGJlIGFzc29jaWF0ZWQgd2l0aCBhIHBh cnRpY3VsYXIKICAgICAgICAgICBlcnJvciBjb25kaXRpb24uIjsKICAgICAgICB0eXBlIHN0 cmluZzsKICAgICAgfQoKICAgICBsZWFmIGVycm9yLXBhdGggewogICAgICAgZGVzY3JpcHRp b24KICAgICAgICAgIkNvbnRhaW5zIHRoZSBhYnNvbHV0ZSBYUGF0aCBbMl0gZXhwcmVzc2lv biBpZGVudGlmeWluZwogICAgICAgICAgdGhlIGVsZW1lbnQgcGF0aCB0byB0aGUgbm9kZSB0 aGF0IGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgZXJyb3IKICAgICAgICAgIGJlaW5nIHJlcG9y dGVkIGluIGEgcGFydGljdWxhciBycGMtZXJyb3IgZWxlbWVudC4gIFRoaXMgZWxlbWVudAog ICAgICAgICB3aWxsIG5vdCBiZSBwcmVzZW50IGlmIG5vIGFwcHJvcHJpYXRlIHBheWxvYWQg ZWxlbWVudCBjYW4gYmUKICAgICAgICAgYXNzb2NpYXRlZCB3aXRoIGEgcGFydGljdWxhciBl cnJvciBjb25kaXRpb24sIG9yIGlmIHRoZQogICAgICAgICAnYmFkLWVsZW1lbnQnIFFTdHJp bmcgcmV0dXJuZWQgaW4gdGhlICdlcnJvci1pbmZvJyBjb250YWluZXIgaXMKICAgICAgICAg c3VmZmljaWVudCB0byBpZGVudGlmeSB0aGUgbm9kZSBhc3NvY2lhdGVkIHdpdGggdGhlIGVy cm9yLiAgV2hlbgogICAgICAgICB0aGUgWFBhdGggZXhwcmVzc2lvbiBpcyBpbnRlcnByZXRl ZCwgdGhlIHNldCBvZiBuYW1lc3BhY2UKICAgICAgICAgZGVjbGFyYXRpb25zIGFyZSB0aG9z ZSBpbiBzY29wZSBvbiB0aGUgcnBjLWVycm9yIGVsZW1lbnQsCiAgICAgICAgIGluY2x1ZGlu ZyB0aGUgZGVmYXVsdCBuYW1lc3BhY2UuIjsKICAgICAgIHR5cGUgc3RyaW5nOwogICAgIH0K CiAgICAgbGVhZiBlcnJvci1tZXNzYWdlIHsKICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAg ICJDb250YWlucyBhIHN0cmluZyBzdWl0YWJsZSBmb3IgaHVtYW4gZGlzcGxheSB0aGF0CiAg ICAgICAgICBkZXNjcmliZXMgdGhlIGVycm9yIGNvbmRpdGlvbi4gIFRoaXMgZWxlbWVudCB3 aWxsIG5vdCBiZSBwcmVzZW50CiAgICAgICAgICBpZiBubyBhcHByb3ByaWF0ZSBtZXNzYWdl IGlzIHByb3ZpZGVkIGZvciBhIHBhcnRpY3VsYXIgZXJyb3IKICAgICAgICAgIGNvbmRpdGlv bi4gIFRoaXMgZWxlbWVudCBTSE9VTEQgaW5jbHVkZSBhbiB4bWw6bGFuZyBhdHRyaWJ1dGUu IjsKICAgICAgICB0eXBlIExhbmdTdHJpbmc7CiAgICAgIH0KCiAgICAgIGFueXhtbCBlcnJv ci1pbmZvIHsKICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgIkNvbnRhaW5zIHByb3Rv Y29sLSBvciBkYXRhLW1vZGVsLXNwZWNpZmljIGVycm9yIGNvbnRlbnQuCiAgICAgICAgICAg VGhpcyBlbGVtZW50IHdpbGwgbm90IGJlIHByZXNlbnQgaWYgbm8gc3VjaCBlcnJvciBjb250 ZW50IGlzCiAgICAgICAgICAgcHJvdmlkZWQgZm9yIGEgcGFydGljdWxhciBlcnJvciBjb25k aXRpb24uICBUaGUgbGlzdCBpbiAKICAgICAgICAgICBSRkMgNDc0MSwgQXBwZW5kaXggQSwg ZGVmaW5lcyBhbnkgbWFuZGF0b3J5IGVycm9yLWluZm8gY29udGVudCAKICAgICAgICAgICBm b3IgZWFjaCBlcnJvci4gIEFmdGVyIGFueSBwcm90b2NvbC1tYW5kYXRlZCBjb250ZW50LCBh IAogICAgICAgICAgIGRhdGEgbW9kZWwgZGVmaW5pdGlvbiBtYXkgbWFuZGF0ZSB0aGF0IGNl cnRhaW4gYXBwbGljYXRpb24tbGF5ZXIKICAgICAgICAgICBlcnJvciBpbmZvcm1hdGlvbiBi ZSBpbmNsdWRlZCBpbiB0aGUgZXJyb3ItaW5mbyBjb250YWluZXIuIAogICAgICAgICAgIEFu IGltcGxlbWVudGF0aW9uIG1heSBpbmNsdWRlIGFkZGl0aW9uYWwgZWxlbWVudHMgdG8gCiAg ICAgICAgICAgcHJvdmlkZSBleHRlbmRlZCBhbmQvb3IgaW1wbGVtZW50YXRpb24tc3BlY2lm aWMgZGVidWdnaW5nIAogICAgICAgICAgIGluZm9ybWF0aW9uLiI7CiAgICAgIH0KICAgfQoK ICAgZ3JvdXBpbmcgUnBjRGF0YVJlcGx5VHlwZSB7CiAgICAgIGRlc2NyaXB0aW9uICJORVRD T05GICdycGMtcmVwbHknIEVycm9yIGFuZC9vciBEYXRhIENvbnRlbnQiOwoKICAgICAgbGlz dCBycGMtZXJyb3IgewogICAgICAgIGNvbmZpZyBmYWxzZTsKICAgICAgICB1c2VzIFJwY0Vy cm9yVHlwZTsKICAgICAgfQogICAgICBhbnl4bWwgZGF0YSB7CiAgICAgICAgY29uZmlnIGZh bHNlOwogICAgICB9CiAgIH0KCiAgIGdyb3VwaW5nIFJwY09rUmVwbHlUeXBlIHsKICAgICAg ZGVzY3JpcHRpb24gIk5FVENPTkYgJ3JwYy1yZXBseScgT0sgQ29udGVudC4iOwoKICAgICAg Y2hvaWNlIG9rLW9yLWVycm9yIHsKICAgICAgICBsZWFmIG9rIHsKICAgICAgICAgIGRlc2Ny aXB0aW9uCiAgICAgICAgICAgICJTZW50IGluICdycGMtcmVwbHknIG1lc3NhZ2VzIGlmIG5v IGVycm9ycyBvcgogICAgICAgICAgICAgd2FybmluZ3Mgb2NjdXJyZWQgZHVyaW5nIHRoZSBw cm9jZXNzaW5nIG9mIGFuICdycGMnIHJlcXVlc3QuIjsKICAgICAgICAgIHR5cGUgZW1wdHk7 CiAgICAgICAgICBjb25maWcgZmFsc2U7CiAgICAgICAgfQoKICAgICAgICBsaXN0IHJwYy1l cnJvciB7CiAgICAgICAgICBjb25maWcgZmFsc2U7CiAgICAgICAgICB1c2VzIFJwY0Vycm9y VHlwZTsKICAgICAgICB9CiAgICAgIH0KICAgfQoKICAgZ3JvdXBpbmcgUnBjUmVwbHlUeXBl IHsKICAgICAgZGVzY3JpcHRpb24gIkdlbmVyaWMgTkVUQ09ORiAncnBjLXJlcGx5JyBjb250 ZW50LiAiOwoKICAgICAgY2hvaWNlIG9rLW9yLWRhdGEtZXJyb3IgewogICAgICAgIG1hbmRh dG9yeSB0cnVlOwogICAgICAgIGNvbmZpZyBmYWxzZTsKCiAgICAgICAgbGVhZiBvayB7CiAg ICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAiU2VudCBpbiAncnBjLXJlcGx5JyBt ZXNzYWdlcyBpZiBubyBlcnJvcnMgb3IKICAgICAgICAgICAgIHdhcm5pbmdzIG9jY3VycmVk IGR1cmluZyB0aGUgcHJvY2Vzc2luZyBvZiBhbiAncnBjJyByZXF1ZXN0LiI7CiAgICAgICAg ICB0eXBlIGVtcHR5OwogICAgICAgIH0KCiAgICAgICAgY2FzZSBkYXRhLWVycm9yIHsKICAg ICAgICAgICB1c2VzIFJwY0RhdGFSZXBseVR5cGU7CiAgICAgICAgfQogICAgICB9CiAgIH0K CiAgIGdyb3VwaW5nIENvbW1vbkNvbmZpZ1NvdXJjZVR5cGUgewogICAgICBkZXNjcmlwdGlv biAiQ29tbW9uIE5FVENPTkYgY29uZmlnIHBhcmFtZXRlciBjb250ZW50cy4iOwoKICAgICAg Y2hvaWNlIGNvbmZpZy1zb3VyY2UgewogICAgICAgIG1hbmRhdG9yeSB0cnVlOwoKICAgICAg ICBsZWFmIGNhbmRpZGF0ZSB7CiAgICAgICAgICBkZXNjcmlwdGlvbiAKICAgICAgICAgICAg Ik9ubHkgYXZhaWxhYmxlIGlmICdjYW5kaWRhdGUnIGNhcGFiaWxpdHkgc3VwcG9ydGVkLiI7 CiAgICAgICAgICB0eXBlIGVtcHR5OwogICAgICAgIH0KICAgICAgICBsZWFmIHJ1bm5pbmcg ewogICAgICAgICAgdHlwZSBlbXB0eTsKICAgICAgICB9CiAgICAgICAgbGVhZiBzdGFydHVw IHsKICAgICAgICAgIGRlc2NyaXB0aW9uIAogICAgICAgICAgICAiT25seSBhdmFpbGFibGUg aWYgJ3N0YXJ0dXAnIGNhcGFiaWxpdHkgc3VwcG9ydGVkLiI7CiAgICAgICAgICB0eXBlIGVt cHR5OwogICAgICAgIH0KICAgICAgfQogICB9CgogICBncm91cGluZyBHZXRDb25maWdTb3Vy Y2VUeXBlIHsKICAgICAgZGVzY3JpcHRpb24gIk5FVENPTkYgY29uZmlnICdzb3VyY2UnIFBh cmFtZXRlciBjb250ZW50cy4iOwoKICAgICAgdXNlcyBDb21tb25Db25maWdTb3VyY2VUeXBl OwoKICAgICAgYXVnbWVudCBjb25maWctc291cmNlIHsKICAgICAgICBsZWFmIHVybCB7CiAg ICAgICAgICBkZXNjcmlwdGlvbiAKICAgICAgICAgICAgIlVSTCBwb2ludGluZyB0byBjb25m aWcgZGF0YS4gT25seSBhdmFpbGFibGUKICAgICAgICAgICAgIGlmICd1cmwnIGNhcGFiaWxp dHkgc3VwcG9ydGVkLiI7CiAgICAgICAgICB0eXBlIENvbmZpZ1VSSVR5cGU7CiAgICAgICAg fQogICAgICB9CiAgIH0KCiAgIGdyb3VwaW5nIFJwY09wZXJhdGlvblNvdXJjZVR5cGUgewog ICAgICBkZXNjcmlwdGlvbiAiTkVUQ09ORiAnc291cmNlJyBQYXJhbWV0ZXIgY29udGVudHMu IjsKCiAgICAgIHVzZXMgQ29tbW9uQ29uZmlnU291cmNlVHlwZTsKICAgICAgYXVnbWVudCBj b25maWctc291cmNlIHsKICAgICAgICBsZWFmIHVybCB7CiAgICAgICAgICBkZXNjcmlwdGlv biAKICAgICAgICAgICAgIlVSTCBwb2ludGluZyB0byBjb25maWcgZGF0YS4gT25seSBhdmFp bGFibGUKICAgICAgICAgICAgIGlmICd1cmwnIGNhcGFiaWxpdHkgc3VwcG9ydGVkLiI7CiAg ICAgICAgICB0eXBlIENvbmZpZ1VSSVR5cGU7CiAgICAgICAgfQoKICAgICAgICBjb250YWlu ZXIgY29uZmlnIHsKICAgICAgICAgIGRlc2NyaXB0aW9uICJJbmxpbmUgY29uZmlndXJhdGlv biBkYXRhIjsKCSAgbmN4OnJvb3Q7CiAgICAgICAgfQogICAgICB9CiAgIH0KCiAgIGdyb3Vw aW5nIFJwY09wZXJhdGlvblRhcmdldFR5cGUgewogICAgICBkZXNjcmlwdGlvbiAiTkVUQ09O RiAndGFyZ2V0JyBQYXJhbWV0ZXIgY29udGVudHMuIjsKCiAgICAgIHVzZXMgQ29tbW9uQ29u ZmlnU291cmNlVHlwZTsKICAgICAgYXVnbWVudCBjb25maWctc291cmNlIHsKICAgICAgICBs ZWFmIHVybCB7CiAgICAgICAgICBkZXNjcmlwdGlvbiAKICAgICAgICAgICAgIlVSTCBwb2lu dGluZyB0byBkZXNpcmVkIGNvbmZpZyBkYXRhIG91dHB1dC4gT25seSAKICAgICAgICAgICAg IGF2YWlsYWJsZSBpZiAndXJsJyBjYXBhYmlsaXR5IHN1cHBvcnRlZC4iOwogICAgICAgICAg dHlwZSBDb25maWdVUklUeXBlOwogICAgICAgIH0KICAgICAgfQogICB9CgogICAvLyBORVRD T05GIG9wZXJhdGlvbiBhdHRyaWJ1dGUKICAgbGVhZiBvcGVyYXRpb24gewogICAgIGRlc2Ny aXB0aW9uIAogICAgICAgIkludGVybmFsIG9iamVjdCBmb3IgdGhlIG5jOm9wZXJhdGlvbiBh dHRyaWJ1dGUuIjsKICAgICB0eXBlIEVkaXRPcGVyYXRpb25UeXBlOwogICAgIG5jeDphYnN0 cmFjdDsKICAgICBuY3g6aGlkZGVuOwogICB9CgogICAvLyBORVRDT05GIEdlbmVyaWMgUlBD IE1lc3NhZ2VzCgogICBjb250YWluZXIgcnBjIHsKICAgICBkZXNjcmlwdGlvbiAiUmVtb3Rl IFByb2NlZHVyZSBDYWxsIHJlcXVlc3QgbWVzc2FnZSI7CiAgIAogICAgIHJlZmVyZW5jZSAi UkZDIDQ3NDEsIHNlY3Rpb24gNC4xIjsKCiAgICAgLy8gZG8gbm90IHRyZWF0IG1pc3Npbmcg bWVzc2FnZS1pZCBhcyBhbiBlcnJvcgogICAgIG5jeDptZXRhZGF0YSAgIk1lc3NhZ2VJZCBt ZXNzYWdlLWlkIjsKICAgICBuY3g6YWJzdHJhY3Q7CiAgIH0KCiAgIGNvbnRhaW5lciBycGMt cmVwbHkgewogICAgIGRlc2NyaXB0aW9uICJSZW1vdGUgUHJvY2VkdXJlIENhbGwgcmVzcG9u c2UgbWVzc2FnZSI7CgogICAgIHJlZmVyZW5jZSAiUkZDIDQ3NDEsIHNlY3Rpb24gNC4yIjsK CiAgICAgdXNlcyBScGNSZXBseVR5cGU7CgogICAgIC8vIGRvIG5vdCB0cmVhdCBtaXNzaW5n IG1lc3NhZ2UtaWQgYXMgYW4gZXJyb3IKICAgICBuY3g6bWV0YWRhdGEgICJNZXNzYWdlSWQg bWVzc2FnZS1pZCI7CiAgICAgbmN4OmFic3RyYWN0OwogICB9CgogICAvLyBORVRDT05GIFN0 YW5kYXJkIFJQQyBNZXRob2RzCgogICBycGMgZ2V0LWNvbmZpZyB7CiAgICAgIGRlc2NyaXB0 aW9uCiAgICAgICAgIlJldHJpZXZlIGFsbCBvciBwYXJ0IG9mIGEgc3BlY2lmaWVkIGNvbmZp Z3VyYXRpb24uIjsKCiAgICAgIHJlZmVyZW5jZSAiUkZDIDQ3NDEsIHNlY3Rpb24gNy4yIjsK CiAgICAgIG5jeDpycGMtdHlwZSAibW9uaXRvciI7CgogICAgICBpbnB1dCB7CiAgICAgICAg Y29udGFpbmVyIHNvdXJjZSB7CiAgICAgICAgICBkZXNjcmlwdGlvbiAiUGFydGljdWxhciBj b25maWd1cmF0aW9uIHRvIHJldHJpZXZlLiI7CiAgICAgICAgICB1c2VzIEdldENvbmZpZ1Nv dXJjZVR5cGU7CiAgICAgICAgfQoKICAgICAgICBhbnl4bWwgZmlsdGVyIHsKICAgICAgICAg IGRlc2NyaXB0aW9uICJTdWJ0cmVlIG9yIFhwYXRoIGZpbHRlciB0byB1c2UuIjsKICAgICAg ICAgIG5jeDptZXRhZGF0YSAiRmlsdGVyVHlwZSB0eXBlIjsKICAgICAgICAgIG5jeDptZXRh ZGF0YSAic3RyaW5nIHNlbGVjdCI7CiAgICAgICAgfQogICAgICB9CgogICAgICBvdXRwdXQg ewogICAgICAgIGFueXhtbCBkYXRhIHsKICAgICAgICAgIGRlc2NyaXB0aW9uIAogICAgICAg ICAgICAiQ29weSBvZiB0aGUgc291cmNlIGRhdGFiYXNlIHN1YnNldCB3aGljaCBtYXRjaGVk CiAgICAgICAgICAgICB0aGUgZmlsdGVyIGNyaXRlcmlhIChpZiBhbnkpLiI7CiAgICAgICB9 CiAgICAgfQogICB9CgogICBycGMgZWRpdC1jb25maWcgewogICAgICBkZXNjcmlwdGlvbgog ICAgICAgICJUaGUgJ2VkaXQtY29uZmlnJyBvcGVyYXRpb24gbG9hZHMgYWxsIG9yIHBhcnQg b2YgYSBzcGVjaWZpZWQKICAgICAgICAgY29uZmlndXJhdGlvbiB0byB0aGUgc3BlY2lmaWVk IHRhcmdldCBjb25maWd1cmF0aW9uLiAgVGhpcwogICAgICAgICBvcGVyYXRpb24gYWxsb3dz IHRoZSBuZXcgY29uZmlndXJhdGlvbiB0byBiZSBleHByZXNzZWQgaW4gc2V2ZXJhbAogICAg ICAgICB3YXlzLCBzdWNoIGFzIHVzaW5nIGEgbG9jYWwgZmlsZSwgYSByZW1vdGUgZmlsZSwg b3IgaW5saW5lLiAgSWYKICAgICAgICAgdGhlIHRhcmdldCBjb25maWd1cmF0aW9uIGRvZXMg bm90IGV4aXN0LCBpdCB3aWxsIGJlIGNyZWF0ZWQuICBJZiBhCiAgICAgICAgIE5FVENPTkYg cGVlciBzdXBwb3J0cyB0aGUgOnVybCBjYXBhYmlsaXR5IChTZWN0aW9uIDguOCksIHRoZSA8 dXJsPgogICAgICAgICBlbGVtZW50IGNhbiBhcHBlYXIgaW5zdGVhZCBvZiB0aGUgPGNvbmZp Zz4gcGFyYW1ldGVyIGFuZCBzaG91bGQKICAgICAgICAgaWRlbnRpZnkgYSBsb2NhbCBjb25m aWd1cmF0aW9uIGZpbGUuCgogICAgICAgICBUaGUgZGV2aWNlIGFuYWx5emVzIHRoZSBzb3Vy Y2UgYW5kIHRhcmdldCBjb25maWd1cmF0aW9ucyBhbmQKICAgICAgICAgcGVyZm9ybXMgdGhl IHJlcXVlc3RlZCBjaGFuZ2VzLiAgVGhlIHRhcmdldCBjb25maWd1cmF0aW9uIGlzIG5vdAog ICAgICAgICBuZWNlc3NhcmlseSByZXBsYWNlZCwgYXMgd2l0aCB0aGUgPGNvcHktY29uZmln PiBtZXNzYWdlLiAgSW5zdGVhZCwKICAgICAgICAgdGhlIHRhcmdldCBjb25maWd1cmF0aW9u IGlzIGNoYW5nZWQgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZQogICAgICAgICBzb3VyY2UncyBk YXRhIGFuZCByZXF1ZXN0ZWQgb3BlcmF0aW9ucy4iOwoKICAgICAgcmVmZXJlbmNlICJSRkMg NDc0MSwgc2VjdGlvbiA3LjIiOwoKICAgICAgbmN4OnJwYy10eXBlICJjb25maWciOwoKICAg ICAgaW5wdXQgewogICAgICAgIGNvbnRhaW5lciB0YXJnZXQgewogICAgICAgICAgZGVzY3Jp cHRpb24gIlBhcnRpY3VsYXIgY29uZmlndXJhdGlvbiB0byBlZGl0LiI7CiAgICAgICAgICAv LyBtYW5kYXRvcnkgdHJ1ZTsgIAogICAgICAgICAgdXNlcyBScGNPcGVyYXRpb25UYXJnZXRU eXBlOwogICAgICAgIH0KCiAgICAgICAgbGVhZiBkZWZhdWx0LW9wZXJhdGlvbiB7CiAgICAg ICAgICBkZXNjcmlwdGlvbiAKICAgICAgICAgICAgIkRlZmF1bHQgb3BlcmF0aW9uIHRvIGFw cGx5IGlmIG5vdCBleHBsaWNpdGx5IHNldC4iOwogICAgICAgICAgdHlwZSBEZWZhdWx0T3Bl cmF0aW9uVHlwZTsKICAgICAgICB9CgogICAgICAgIGxlYWYgdGVzdC1vcHRpb24gewogICAg ICAgICAgZGVzY3JpcHRpb24gCiAgICAgICAgICAgICJUZXN0IG9wdGlvbiBpZiB2YWxpZGF0 ZSBjYXBhYmlsaXR5IHN1cHBvcnRlZC4KICAgICAgICAgICAgIFRoZSAndmFsaWRhdGUnIGNh cGFiaWxpdHkgbXVzdCBiZSBwcmVzZW50IHRvIHNldAogICAgICAgICAgICAgdGhpcyBvYmpl Y3QgdG8gJ3Rlc3QtdGhlbi1zZXQnLiI7CiAgICAgICAgICB0eXBlIFRlc3RPcHRpb25UeXBl OwogICAgICAgIH0KCiAgICAgICAgbGVhZiBlcnJvci1vcHRpb24gewogICAgICAgICAgZGVz Y3JpcHRpb24gIkVycm9yIHJlY292ZXJ5IG9wdGlvbi4iOwogICAgICAgICAgdHlwZSBFcnJv ck9wdGlvblR5cGU7CiAgICAgICAgfQoKICAgICAgICBjaG9pY2UgZWRpdC1jb250ZW50IHsK ICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOwogICAgICAgICAgY29udGFpbmVyIGNvbmZpZyB7 CiAgICAgICAgICAgIGRlc2NyaXB0aW9uIAogICAgICAgICAgICAgICJJbmxpbmUgQ29uZmln IGNvbnRlbnQ6ICdjb25maWcnIGVsZW1lbnQuIjsKICAgICAgICAgICAgbmN4OnJvb3Q7CiAg ICAgICAgICB9CiAgICAgICAgICBsZWFmIHVybCB7CiAgICAgICAgICAgIGRlc2NyaXB0aW9u IAogICAgICAgICAgICAgICJQb2ludGVyIHRvIENvbmZpZyBjb250ZW50OiAndXJsJyBlbGVt ZW50LiI7CiAgICAgICAgICAgIHR5cGUgQ29uZmlnVVJJVHlwZTsKICAgICAgICAgIH0KICAg ICAgICB9CiAgICAgIH0KICAgfQoKICAgcnBjIGNvcHktY29uZmlnIHsKICAgICAgZGVzY3Jp cHRpb24KICAgICAgICAiQ3JlYXRlIG9yIHJlcGxhY2UgYW4gZW50aXJlIGNvbmZpZ3VyYXRp b24gZGF0YXN0b3JlIHdpdGggdGhlCiAgICAgICAgIGNvbnRlbnRzIG9mIGFub3RoZXIgY29t cGxldGUgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUuICBJZiB0aGUKICAgICAgICAgdGFyZ2V0 IGRhdGFzdG9yZSBleGlzdHMsIGl0IGlzIG92ZXJ3cml0dGVuLiAgT3RoZXJ3aXNlLCBhIG5l dyBvbmUKICAgICAgICAgaXMgY3JlYXRlZCwgaWYgYWxsb3dlZC4KCiAgICAgICAgIElmIGEg TkVUQ09ORiBwZWVyIHN1cHBvcnRzIHRoZSA6dXJsIGNhcGFiaWxpdHkgKFNlY3Rpb24gOC44 KSwgdGhlCiAgICAgICAgICd1cmwnIGVsZW1lbnQgY2FuIGFwcGVhciBhcyB0aGUgPHNvdXJj ZT4gb3IgPHRhcmdldD4gcGFyYW1ldGVyLgoKICAgICAgICAgRXZlbiBpZiBpdCBhZHZlcnRp c2VzIHRoZSA6d3JpdGFibGUtcnVubmluZyBjYXBhYmlsaXR5LCBhIGRldmljZQogICAgICAg ICBtYXkgY2hvb3NlIG5vdCB0byBzdXBwb3J0IHRoZSA8cnVubmluZy8+IGNvbmZpZ3VyYXRp b24gZGF0YXN0b3JlCiAgICAgICAgIGFzIHRoZSA8dGFyZ2V0PiBwYXJhbWV0ZXIgb2YgYSA8 Y29weS1jb25maWc+IG9wZXJhdGlvbi4gIEEgZGV2aWNlCiAgICAgICAgIG1heSBjaG9vc2Ug bm90IHRvIHN1cHBvcnQgcmVtb3RlLXRvLXJlbW90ZSBjb3B5IG9wZXJhdGlvbnMsIHdoZXJl CiAgICAgICAgIGJvdGggdGhlIDxzb3VyY2U+IGFuZCA8dGFyZ2V0PiBwYXJhbWV0ZXJzIHVz ZSB0aGUgPHVybD4gZWxlbWVudC4KCiAgICAgICAgSWYgdGhlIHNvdXJjZSBhbmQgdGFyZ2V0 IHBhcmFtZXRlcnMgaWRlbnRpZnkgdGhlIHNhbWUgVVJMIG9yCiAgICAgICAgY29uZmlndXJh dGlvbiBkYXRhc3RvcmUsIGFuIGVycm9yIE1VU1QgYmUgcmV0dXJuZWQgd2l0aCBhbiBlcnJv ci0KICAgICAgICB0YWcgY29udGFpbmluZyBpbnZhbGlkLXZhbHVlLiI7CgogICAgICByZWZl cmVuY2UgIlJGQyA0NzQxLCBzZWN0aW9uIDcuMyI7CgogICAgICBuY3g6cnBjLXR5cGUgImNv bmZpZyI7CgogICAgICBpbnB1dCB7CiAgICAgICAgY29udGFpbmVyIHRhcmdldCB7CiAgICAg ICAgICBkZXNjcmlwdGlvbiAiUGFydGljdWxhciBjb25maWd1cmF0aW9uIHRvIGNvcHkgdG8u IjsKICAgICAgICAgIC8vIG1hbmRhdG9yeSB0cnVlOwogICAgICAgICAgdXNlcyBScGNPcGVy YXRpb25UYXJnZXRUeXBlOwogICAgICAgIH0KCiAgICAgICAgY29udGFpbmVyIHNvdXJjZSB7 CiAgICAgICAgICBkZXNjcmlwdGlvbiAiUGFydGljdWxhciBjb25maWd1cmF0aW9uIHRvIGNv cHkgZnJvbS4iOwogICAgICAgICAgLy8gbWFuZGF0b3J5IHRydWU7CiAgICAgICAgICB1c2Vz IFJwY09wZXJhdGlvblNvdXJjZVR5cGU7CiAgICAgICAgfQogICAgICB9CiAgIH0KCiAgIHJw YyBkZWxldGUtY29uZmlnIHsKICAgICAgZGVzY3JpcHRpb24KICAgICAgICAiRGVsZXRlIGEg Y29uZmlndXJhdGlvbiBkYXRhc3RvcmUuICBUaGUgJ3J1bm5pbmcnIGNvbmZpZ3VyYXRpb24K ICAgICAgICAgZGF0YXN0b3JlIGNhbm5vdCBiZSBkZWxldGVkLgoKICAgICAgICAgSWYgYSBO RVRDT05GIHBlZXIgc3VwcG9ydHMgdGhlIDp1cmwgY2FwYWJpbGl0eSAoU2VjdGlvbiA4Ljgp LCB0aGUKICAgICAgICAgJ3VybCcgZWxlbWVudCBjYW4gYXBwZWFyIGFzIHRoZSA8dGFyZ2V0 PiBwYXJhbWV0ZXIuIjsKCiAgICAgIHJlZmVyZW5jZSAiUkZDIDQ3NDEsIHNlY3Rpb24gNy40 IjsKCiAgICAgIG5jeDpycGMtdHlwZSAiY29uZmlnIjsKCiAgICAgIGlucHV0IHsKICAgICAg ICBjb250YWluZXIgdGFyZ2V0IHsKICAgICAgICAgIGRlc2NyaXB0aW9uICJQYXJ0aWN1bGFy IGNvbmZpZ3VyYXRpb24gdG8gZGVsZXRlLiI7CiAgICAgICAgICB1c2VzIFJwY09wZXJhdGlv blRhcmdldFR5cGU7CiAgICAgICAgfQogICAgICB9CiAgIH0KCiAgIHJwYyBsb2NrIHsKICAg ICAgZGVzY3JpcHRpb24KICAgICAgICAiVGhlIGxvY2sgb3BlcmF0aW9uIGFsbG93cyB0aGUg Y2xpZW50IHRvIGxvY2sgdGhlIGNvbmZpZ3VyYXRpb24KICAgICAgICAgc3lzdGVtIG9mIGEg ZGV2aWNlLiAgU3VjaCBsb2NrcyBhcmUgaW50ZW5kZWQgdG8gYmUgc2hvcnQtbGl2ZWQgYW5k CiAgICAgICAgIGFsbG93IGEgY2xpZW50IHRvIG1ha2UgYSBjaGFuZ2Ugd2l0aG91dCBmZWFy IG9mIGludGVyYWN0aW9uIHdpdGgKICAgICAgICAgb3RoZXIgTkVUQ09ORiBjbGllbnRzLCBu b24tTkVUQ09ORiBjbGllbnRzIChlLmcuLCBTTk1QIGFuZCBjb21tYW5kCiAgICAgICAgIGxp bmUgaW50ZXJmYWNlIChDTEkpIHNjcmlwdHMpLCBhbmQgaHVtYW4gdXNlcnMuIC4uLiI7Cgog ICAgICByZWZlcmVuY2UgIlJGQyA0NzQxLCBzZWN0aW9uIDcuNSI7CgogICAgICBuY3g6cnBj LXR5cGUgImNvbmZpZyI7CgogICAgICBpbnB1dCB7CiAgICAgICAgY29udGFpbmVyIHRhcmdl dCB7CiAgICAgICAgICBkZXNjcmlwdGlvbiAiUGFydGljdWxhciBjb25maWd1cmF0aW9uIHRv IGxvY2siOwogICAgICAgICAgLy8gbWFuZGF0b3J5IHRydWU7CiAgICAgICAgICB1c2VzIFJw Y09wZXJhdGlvblRhcmdldFR5cGU7CiAgICAgICAgfQogICAgICB9CiAgIH0KCiAgIHJwYyB1 bmxvY2sgewogICAgICBkZXNjcmlwdGlvbgogICAgICAgICJUaGUgdW5sb2NrIG9wZXJhdGlv biBpcyB1c2VkIHRvIHJlbGVhc2UgYSBjb25maWd1cmF0aW9uIGxvY2ssCiAgICAgICAgIHBy ZXZpb3VzbHkgb2J0YWluZWQgd2l0aCB0aGUgJ2xvY2snIG9wZXJhdGlvbi4KCiAgICAgICAg IEFuIHVubG9jayBvcGVyYXRpb24gd2lsbCBub3Qgc3VjY2VlZCBpZiBhbnkgb2YgdGhlIGZv bGxvd2luZwogICAgICAgICBjb25kaXRpb25zIGFyZSB0cnVlOgoKICAgICAgICAgKiAgdGhl IHNwZWNpZmllZCBsb2NrIGlzIG5vdCBjdXJyZW50bHkgYWN0aXZlCgogICAgICAgICAqICB0 aGUgc2Vzc2lvbiBpc3N1aW5nIHRoZSA8dW5sb2NrPiBvcGVyYXRpb24gaXMgbm90IHRoZSBz YW1lCiAgICAgICAgICAgIHNlc3Npb24gdGhhdCBvYnRhaW5lZCB0aGUgbG9jawoKICAgICAg ICAgVGhlIHNlcnZlciBNVVNUIHJlc3BvbmQgd2l0aCBlaXRoZXIgYW4gPG9rPiBlbGVtZW50 IG9yIGFuCiAgICAgICAgICdycGMtZXJyb3InLiI7CgogICAgICByZWZlcmVuY2UgIlJGQyA0 NzQxLCBzZWN0aW9uIDcuNiI7CgogICAgICBuY3g6cnBjLXR5cGUgImNvbmZpZyI7CgogICAg ICBpbnB1dCB7CiAgICAgICAgY29udGFpbmVyIHRhcmdldCB7CiAgICAgICAgICAvLyBtYW5k YXRvcnkgdHJ1ZTsKICAgICAgICAgIGRlc2NyaXB0aW9uICJQYXJ0aWN1bGFyIGNvbmZpZ3Vy YXRpb24gdG8gdW5sb2NrLiI7CiAgICAgICAgICB1c2VzIFJwY09wZXJhdGlvblRhcmdldFR5 cGU7CiAgICAgICAgfQogICAgICB9CiAgIH0KCiAgIHJwYyBnZXQgewogICAgICBkZXNjcmlw dGlvbgogICAgICAgICJSZXRyaWV2ZSBydW5uaW5nIGNvbmZpZ3VyYXRpb24gYW5kIGRldmlj ZSBzdGF0ZSBpbmZvcm1hdGlvbi4iOwoKICAgICAgcmVmZXJlbmNlICJSRkMgNDc0MSwgc2Vj dGlvbiA3LjciOwoKICAgICAgbmN4OnJwYy10eXBlICJtb25pdG9yIjsKCiAgICAgIGlucHV0 IHsKICAgICAgICBhbnl4bWwgZmlsdGVyIHsKICAgICAgICAgIGRlc2NyaXB0aW9uCiAgICAg ICAgICAgICJUaGlzIHBhcmFtZXRlciBzcGVjaWZpZXMgdGhlIHBvcnRpb24gb2YgdGhlIHN5 c3RlbQogICAgICAgICAgICAgY29uZmlndXJhdGlvbiBhbmQgc3RhdGUgZGF0YSB0byByZXRy aWV2ZS4gIElmIHRoaXMgcGFyYW1ldGVyIGlzCiAgICAgICAgICAgICBlbXB0eSwgYWxsIHRo ZSBkZXZpY2UgY29uZmlndXJhdGlvbiBhbmQgc3RhdGUgaW5mb3JtYXRpb24gaXMKICAgICAg ICAgICAgIHJldHVybmVkLgoKICAgICAgICAgICAgIFRoZSBmaWx0ZXIgZWxlbWVudCBtYXkg b3B0aW9uYWxseSBjb250YWluIGEgJ3R5cGUnIGF0dHJpYnV0ZS4KICAgICAgICAgICAgIFRo aXMgYXR0cmlidXRlIGluZGljYXRlcyB0aGUgdHlwZSBvZiBmaWx0ZXJpbmcgc3ludGF4IHVz ZWQKICAgICAgICAgICAgIHdpdGhpbiB0aGUgZmlsdGVyIGVsZW1lbnQuICBUaGUgZGVmYXVs dCBmaWx0ZXJpbmcgbWVjaGFuaXNtIGluCiAgICAgICAgICAgICBORVRDT05GIGlzIHJlZmVy cmVkIHRvIGFzIHN1YnRyZWUgZmlsdGVyaW5nIGFuZCBpcyBkZXNjcmliZWQgaW4KICAgICAg ICAgICAgIFNlY3Rpb24gNi4gIFRoZSB2YWx1ZSAnc3VidHJlZScgZXhwbGljaXRseSBpZGVu dGlmaWVzIHRoaXMgdHlwZQogICAgICAgICAgICAgb2YgZmlsdGVyaW5nLgoKICAgICAgICAg ICAgIElmIHRoZSBORVRDT05GIHBlZXIgc3VwcG9ydHMgdGhlIDp4cGF0aCBjYXBhYmlsaXR5 CiAgICAgICAgICAgICAoU2VjdGlvbiA4LjkpLCB0aGUgdmFsdWUgJ3hwYXRoJyBtYXkgYmUg dXNlZCB0byBpbmRpY2F0ZSB0aGF0CiAgICAgICAgICAgICB0aGUgc2VsZWN0IGF0dHJpYnV0 ZSBvZiB0aGUgZmlsdGVyIGVsZW1lbnQgY29udGFpbnMgYW4gWFBhdGgKICAgICAgICAgICAg IGV4cHJlc3Npb24uIjsKICAgICAgICAgIG5jeDptZXRhZGF0YSAiRmlsdGVyVHlwZSB0eXBl IjsKICAgICAgICAgIG5jeDptZXRhZGF0YSAic3RyaW5nIHNlbGVjdCI7CiAgICAgICAgfQog ICAgICB9CgogICAgICBvdXRwdXQgewogICAgICAgIGFueXhtbCBkYXRhIHsKICAgICAgICAg IGRlc2NyaXB0aW9uIAogICAgICAgICAgICAiQ29weSBvZiB0aGUgJ3J1bm5pbmcnIGRhdGFi YXNlIHN1YnNldCB3aGljaCBtYXRjaGVkCiAgICAgICAgICAgICB0aGUgZmlsdGVyIGNyaXRl cmlhIChpZiBhbnkpLiI7CiAgICAgICAgfQogICAgICB9CiAgIH0KCiAgIHJwYyBjbG9zZS1z ZXNzaW9uIHsKICAgICAgZGVzY3JpcHRpb24KICAgICAgICAiUmVxdWVzdCBncmFjZWZ1bCB0 ZXJtaW5hdGlvbiBvZiBhIE5FVENPTkYgc2Vzc2lvbi4KCiAgICAgICAgIFdoZW4gYSBORVRD T05GIHNlcnZlciByZWNlaXZlcyBhIDxjbG9zZS1zZXNzaW9uPiByZXF1ZXN0LCBpdCB3aWxs CiAgICAgICAgIGdyYWNlZnVsbHkgY2xvc2UgdGhlIHNlc3Npb24uICBUaGUgc2VydmVyIHdp bGwgcmVsZWFzZSBhbnkgbG9ja3MKICAgICAgICAgYW5kIHJlc291cmNlcyBhc3NvY2lhdGVk IHdpdGggdGhlIHNlc3Npb24gYW5kIGdyYWNlZnVsbHkgY2xvc2UgYW55CiAgICAgICAgIGFz c29jaWF0ZWQgY29ubmVjdGlvbnMuICBBbnkgTkVUQ09ORiByZXF1ZXN0cyByZWNlaXZlZCBh ZnRlciBhCiAgICAgICAgICdjbG9zZS1zZXNzaW9uJyByZXF1ZXN0IHdpbGwgYmUgaWdub3Jl ZC4iOwoKICAgICAgcmVmZXJlbmNlICJSRkMgNDc0MSwgc2VjdGlvbiA3LjgiOwoKICAgICAg bmN4OnJwYy10eXBlICJvdGhlciI7CiAgIH0KCiAgIHJwYyBraWxsLXNlc3Npb24gewogICAg ICBkZXNjcmlwdGlvbgogICAgICAgICJGb3JjZSB0aGUgdGVybWluYXRpb24gb2YgYSBORVRD T05GIHNlc3Npb24uCgogICAgICAgICBXaGVuIGEgTkVUQ09ORiBlbnRpdHkgcmVjZWl2ZXMg YSA8a2lsbC1zZXNzaW9uPiByZXF1ZXN0IGZvciBhbgogICAgICAgICBvcGVuIHNlc3Npb24s IGl0IHdpbGwgYWJvcnQgYW55IG9wZXJhdGlvbnMgY3VycmVudGx5IGluIHByb2Nlc3MsCiAg ICAgICAgIHJlbGVhc2UgYW55IGxvY2tzIGFuZCByZXNvdXJjZXMgYXNzb2NpYXRlZCB3aXRo IHRoZSBzZXNzaW9uLCBhbmQKICAgICAgICAgY2xvc2UgYW55IGFzc29jaWF0ZWQgY29ubmVj dGlvbnMuCgogICAgICAgICBJZiBhIE5FVENPTkYgc2VydmVyIHJlY2VpdmVzIGEgPGtpbGwt c2Vzc2lvbj4gcmVxdWVzdCB3aGlsZQogICAgICAgICBwcm9jZXNzaW5nIGEgY29uZmlybWVk IGNvbW1pdCAoU2VjdGlvbiA4LjQpLCBpdCBtdXN0IHJlc3RvcmUgdGhlCiAgICAgICAgIGNv bmZpZ3VyYXRpb24gdG8gaXRzIHN0YXRlIGJlZm9yZSB0aGUgY29uZmlybWVkIGNvbW1pdCB3 YXMgaXNzdWVkLgoKICAgICAgICAgT3RoZXJ3aXNlLCB0aGUgPGtpbGwtc2Vzc2lvbj4gb3Bl cmF0aW9uIGRvZXMgbm90IHJvbGwgYmFjawogICAgICAgICBjb25maWd1cmF0aW9uIG9yIG90 aGVyIGRldmljZSBzdGF0ZSBtb2RpZmljYXRpb25zIG1hZGUgYnkgdGhlCiAgICAgICAgIGVu dGl0eSBob2xkaW5nIHRoZSBsb2NrLiI7CgogICAgICByZWZlcmVuY2UgIlJGQyA0NzQxLCBz ZWN0aW9uIDcuOSI7CgogICAgICBuY3g6cnBjLXR5cGUgImV4ZWMiOwoKICAgICAgaW5wdXQg ewogICAgICAgIGxlYWYgc2Vzc2lvbi1pZCB7CiAgICAgICAgICBkZXNjcmlwdGlvbiAiUGFy dGljdWxhciBzZXNzaW9uIHRvIGtpbGwuIjsKICAgICAgICAgIHR5cGUgU2Vzc2lvbklkOwog ICAgICAgICAgbWFuZGF0b3J5IHRydWU7CiAgICAgICAgfQogICAgICB9CiAgIH0KCiAgIHJw YyBjb21taXQgewogICAgICBkZXNjcmlwdGlvbgogICAgICAgICJPbmx5IGF2YWlsYWJsZSBp ZiAnY2FuZGlkYXRlJyBjYXBhYmlsaXR5IGlzIHN1cHBvcnRlZC4KCiAgICAgICAgIFdoZW4g YSBjYW5kaWRhdGUgY29uZmlndXJhdGlvbidzIGNvbnRlbnQgaXMgY29tcGxldGUsIHRoZQog ICAgICAgICBjb25maWd1cmF0aW9uIGRhdGEgY2FuIGJlIGNvbW1pdHRlZCwgcHVibGlzaGlu ZyB0aGUgZGF0YSBzZXQgdG8KICAgICAgICAgdGhlIHJlc3Qgb2YgdGhlIGRldmljZSBhbmQg cmVxdWVzdGluZyB0aGUgZGV2aWNlIHRvIGNvbmZvcm0gdG8KICAgICAgICAgdGhlIGJlaGF2 aW9yIGRlc2NyaWJlZCBpbiB0aGUgbmV3IGNvbmZpZ3VyYXRpb24uCgogICAgICAgICBUbyBj b21taXQgdGhlIGNhbmRpZGF0ZSBjb25maWd1cmF0aW9uIGFzIHRoZSBkZXZpY2UncyBuZXcK ICAgICAgICAgY3VycmVudCBjb25maWd1cmF0aW9uLCB1c2UgdGhlIDxjb21taXQ+IG9wZXJh dGlvbi4KCiAgICAgICAgIFRoZSAnY29tbWl0JyBvcGVyYXRpb24gaW5zdHJ1Y3RzIHRoZSBk ZXZpY2UgdG8gaW1wbGVtZW50IHRoZQogICAgICAgICBjb25maWd1cmF0aW9uIGRhdGEgY29u dGFpbmVkIGluIHRoZSBjYW5kaWRhdGUgY29uZmlndXJhdGlvbi4KICAgICAgICAgSWYgdGhl IGRldmljZSBpcyB1bmFibGUgdG8gY29tbWl0IGFsbCBvZiB0aGUgY2hhbmdlcyBpbiB0aGUK ICAgICAgICAgY2FuZGlkYXRlIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlLCB0aGVuIHRoZSBy dW5uaW5nCiAgICAgICAgIGNvbmZpZ3VyYXRpb24gTVVTVCByZW1haW4gdW5jaGFuZ2VkLiAg SWYgdGhlIGRldmljZSBkb2VzCiAgICAgICAgIHN1Y2NlZWQgaW4gY29tbWl0dGluZywgdGhl IHJ1bm5pbmcgY29uZmlndXJhdGlvbiBNVVNUIGJlCiAgICAgICAgIHVwZGF0ZWQgd2l0aCB0 aGUgY29udGVudHMgb2YgdGhlIGNhbmRpZGF0ZSBjb25maWd1cmF0aW9uLgoKICAgICAgICAg SWYgdGhlIHN5c3RlbSBkb2VzIG5vdCBoYXZlIHRoZSA6Y2FuZGlkYXRlIGNhcGFiaWxpdHks IHRoZQogICAgICAgICAnY29tbWl0JyBvcGVyYXRpb24gaXMgbm90IGF2YWlsYWJsZS4iOwoK ICAgICAgcmVmZXJlbmNlICJSRkMgNDc0MSwgc2VjdGlvbiA4LjMuNC4xIjsKCiAgICAgIG5j eDpycGMtdHlwZSAiY29uZmlnIjsKCiAgICAgIGlucHV0IHsKICAgICAgICBsZWFmIGNvbmZp cm1lZCB7CiAgICAgICAgICBkZXNjcmlwdGlvbiAKICAgICAgICAgICAgIlJlcXVlc3QgYSBj b25maXJtZWQgY29tbWl0LiAgT25seSBhdmFpbGFibGUgaWYgCiAgICAgICAgICAgICAnY29u ZmlybWVkLWNvbW1pdCcgY2FwYWJpbGl0eSBpcyBzdXBwb3J0ZWQuIjsKICAgICAgICAgIHJl ZmVyZW5jZSAiUkZDIDQ3NDEsIHNlY3Rpb24gOC40LjUuMSI7CiAgICAgICAgICB0eXBlIGVt cHR5OwogICAgICAgIH0KCiAgICAgICAgbGVhZiBjb25maXJtLXRpbWVvdXQgewogICAgICAg ICAgZGVzY3JpcHRpb24gCiAgICAgICAgICAgICJSZXF1ZXN0IGEgc3BlY2lmaWMgdGltZW91 dCBwZXJpb2QgZm9yIGEgY29uZmlybWVkIGNvbW1pdAogICAgICAgICAgICAgaWYgJ2NvbmZp cm1lZC1jb21taXQnIGNhcGFiaWxpdHkgc3VwcG9ydGVkLiI7CiAgICAgICAgICByZWZlcmVu Y2UgIlJGQyA0NzQxLCBzZWN0aW9uIDguNC41LjEiOwogICAgICAgICAgdHlwZSBDb25maXJt VGltZW91dFR5cGU7CiAgICAgICAgfQogICAgICB9CiAgIH0KCiAgIHJwYyBkaXNjYXJkLWNo YW5nZXMgewogICAgICBkZXNjcmlwdGlvbgogICAgICAgICJPbmx5IGF2YWlsYWJsZSBpZiAn Y2FuZGlkYXRlJyBjYXBhYmlsaXR5IGlzIHN1cHBvcnRlZC4KCiAgICAgICAgIElmIHRoZSBj bGllbnQgZGVjaWRlcyB0aGF0IHRoZSBjYW5kaWRhdGUgY29uZmlndXJhdGlvbiBzaG91bGQg bm90IGJlCiAgICAgICAgIGNvbW1pdHRlZCwgdGhlICdkaXNjYXJkLWNoYW5nZXMnIG9wZXJh dGlvbiBjYW4gYmUgdXNlZCB0byByZXZlcnQgdGhlCiAgICAgICAgIGNhbmRpZGF0ZSBjb25m aWd1cmF0aW9uIHRvIHRoZSBjdXJyZW50IHJ1bm5pbmcgY29uZmlndXJhdGlvbi4KCiAgICAg ICAgIFRoaXMgb3BlcmF0aW9uIGRpc2NhcmRzIGFueSB1bmNvbW1pdHRlZCBjaGFuZ2VzIGJ5 IHJlc2V0dGluZyB0aGUKICAgICAgICAgY2FuZGlkYXRlIGNvbmZpZ3VyYXRpb24gd2l0aCB0 aGUgY29udGVudCBvZiB0aGUgcnVubmluZwogICAgICAgICBjb25maWd1cmF0aW9uLiI7Cgog ICAgICByZWZlcmVuY2UgIlJGQyA0NzQxLCBzZWN0aW9uIDguMy40LjIiOwoKICAgICAgbmN4 OnJwYy10eXBlICJjb25maWciOwoKICAgfQoKICAgcnBjIHZhbGlkYXRlIHsKICAgICAgZGVz Y3JpcHRpb24KICAgICAgICAgIk9ubHkgYXZhaWxhYmxlIGlmICd2YWxpZGF0ZScgY2FwYWJp bGl0eSBpcyBzdXBwb3J0ZWQuCgogICAgICAgICAgVmFsaWRhdGVzIHRoZSBjb250ZW50cyBv ZiB0aGUgc3BlY2lmaWVkIGNvbmZpZ3VyYXRpb24uIjsKCiAgICAgIHJlZmVyZW5jZSAiUkZD IDQ3NDEsIHNlY3Rpb24gOC42LjQuMSI7CgogICAgICBuY3g6cnBjLXR5cGUgImNvbmZpZyI7 CgogICAgICBpbnB1dCB7CiAgICAgICAgY29udGFpbmVyIHNvdXJjZSB7CiAgICAgICAgICBk ZXNjcmlwdGlvbiAiUGFydGljdWxhciBjb25maWd1cmF0aW9uIHRvIHZhbGlkYXRlLiI7CiAg ICAgICAgICAvLyBtYW5kYXRvcnkgdHJ1ZTsKICAgICAgICAgIHVzZXMgUnBjT3BlcmF0aW9u U291cmNlVHlwZTsKICAgICAgICB9CiAgICAgIH0KICAgfQoKICAgY29udGFpbmVyIGNvbmZp ZyB7CiAgICAgZGVzY3JpcHRpb24gCiAgICAgICAiVXNlZCBhcyB0aGUgY29udGFpbmVyIGZv ciBORVRDT05GIG9iamVjdCBkZWZpbml0aW9ucy4iOwogICAgIG5jeDpyb290OwogICAgIG5j eDphYnN0cmFjdDsKICAgfQogICAgICAgIAp9CgoK --------------010000030904030503050101 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 --------------010000030904030503050101-- From netmod-bounces@ietf.org Mon Oct 6 09:25: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 2356F28C1F7; Mon, 6 Oct 2008 09:25:13 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 051C23A6811 for ; Mon, 6 Oct 2008 09:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 9mviaY8z74We for ; Mon, 6 Oct 2008 09:25:05 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id 1457328C1F8 for ; Mon, 6 Oct 2008 09:25:01 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Mon, 06 Oct 2008 09:22:07 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Oct 2008 09:25:16 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Oct 2008 09:25:15 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Oct 2008 09:25:15 -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 m96GPEM60357; Mon, 6 Oct 2008 09:25:14 -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 m96GKwbo029214; Mon, 6 Oct 2008 16:20:58 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200810061620.m96GKwbo029214@idle.juniper.net> To: Balazs Lengyel In-reply-to: <48EA242D.6080609@ericsson.com> Date: Mon, 06 Oct 2008 12:20:58 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 Oct 2008 16:25:15.0378 (UTC) FILETIME=[1D39D520:01C927D0] Cc: netmod@ietf.org Subject: Re: [netmod] 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: , 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: >IMHO if you claim conformance you can say: >- I claim full conformance- means NO deviations are allowed >- I claim partial conformance with the deviations documented in ... >Is it so? Yes, exactly. And the buyer can examine the deviations and say "this is hokey; you dudes are snakes and I'm not buying your products" if the "partial" claim in nonsense. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 09:26: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 E08803A67DD; Mon, 6 Oct 2008 09:26: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 B6AE03A67DD for ; Mon, 6 Oct 2008 09:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kujIN74DdrgB for ; Mon, 6 Oct 2008 09:26:51 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id C3A1F3A6811 for ; Mon, 6 Oct 2008 09:26:48 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Mon, 06 Oct 2008 09:26:06 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Oct 2008 09:27:13 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Oct 2008 09:27:12 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Oct 2008 09:27: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 m96GRBM61151; Mon, 6 Oct 2008 09:27: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 m96GMtNp029258; Mon, 6 Oct 2008 16:22:55 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200810061622.m96GMtNp029258@idle.juniper.net> To: Andy Bierman In-reply-to: <48EA2351.1000709@netconfcentral.com> Date: Mon, 06 Oct 2008 12:22:55 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 Oct 2008 16:27:12.0046 (UTC) FILETIME=[62C3F4E0:01C927D0] Cc: netmod@ietf.org Subject: Re: [netmod] 7.13.4 -- put back the element X-BeenThere: netmod@ietf.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: >Turning this around for a second... >What problem is solved by removing the element? >It saves 13 bytes on the wire? Big deal? In XML terms, >that's one drop in the bucket. Turning it around again (and trimming the quoted noise).... What problem is solved by having the element? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 09:40: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 576533A69F6; Mon, 6 Oct 2008 09:40: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 F41AB3A6AE0 for ; Mon, 6 Oct 2008 09:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.425, 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 mTv+xrrGRasv for ; Mon, 6 Oct 2008 09:40:22 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 31A033A69F6 for ; Mon, 6 Oct 2008 09:40:22 -0700 (PDT) Received: (qmail 43918 invoked from network); 6 Oct 2008 16:40:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.69.54 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 6 Oct 2008 16:40:23 -0000 X-YMail-OSG: GUvH9f0VM1npg4d5hyiVXbrBbJoFslNdrl_sN4nVL1RFgiXV0YzyYqyPs.k44Zwg5aTi1gh2fGNRi0JOJtx9b9..oX_iWVkZ26aLQ4pRJvaE8Oken3JU48cM0T7WVdXX4jg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48EA3F75.6030105@netconfcentral.com> Date: Mon, 06 Oct 2008 09:40:21 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Phil Shafer References: <200810061619.m96GJReG029192@idle.juniper.net> In-Reply-To: <200810061619.m96GJReG029192@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] 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 Phil Shafer wrote: > Andy Bierman writes: >> Most vendors understand that maintaining the platform-specific >> and even platform/version/hw-option specific deviations is >> best done with separate files, rather than polluting the >> data model source file. > > I think you are missing something here. A vendors doesn't change > the data model source file. They publish their deviations in a > distinct vendor-specific module. > > Trying to republish a standard module is unworkable, as is having > the standard modeler track all vendor deviations. > > Instead, we have the vendor publish a distinct module containing > their deviations, and have a mechanism for attaching these modules > to the base module via the message. > > Please reread the spec and let me know if this isn't clear. > I have some concerns with the NETMOD WG process here. Integrating your solution proposal into the WG draft presumes the WG understands and has agreed upon the problem that needs to be solved. I do not agree that there is any standards value in an approach that assumes vendors will not implement the standard data model faithfully, so they should be able to change and replace the standard however they choose. I don't think this approach will ever work for standards-based configuration management. I think the WG would better serve the standards community by improving data modeling practices and even WG data model development processes, so that vendors can more easily comply with the standard. For example, you should never hard-wire memory requirements into the API if there is any concern over resources on any possible platform. Use a buffersRequested/buffersGranted design (like RMON) instead. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 09:43:32 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7533E3A6ADA; Mon, 6 Oct 2008 09:43:32 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E3CC3A6ADA for ; Mon, 6 Oct 2008 09:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.141, 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 RmBfFHCXE6FV for ; Mon, 6 Oct 2008 09:43:27 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id AEDC53A6AFE for ; Mon, 6 Oct 2008 09:43:27 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 66AF861600B; Mon, 6 Oct 2008 18:43:38 +0200 (CEST) Date: Mon, 06 Oct 2008 18:46:06 +0200 (CEST) Message-Id: <20081006.184606.66034389.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48EA2351.1000709@netconfcentral.com> References: <48E94E66.3080202@netconfcentral.com> <20081006.093241.33474258.mbj@tail-f.com> <48EA2351.1000709@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.13.4 -- put back the element X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: > Turning this around for a second... > > What problem is solved by removing the element? > It saves 13 bytes on the wire? Big deal? In XML terms, > that's one drop in the bucket. Personally I can live with either solution. My original interpretation of 4741 was that had to be there, so that's what I have in my code... But then I re-read section 4.2 which says: The response name and response data are encoded as the contents of the element. ... and I asked the question to the list if the text or XSD is correct. Usually in these cases the text is right and the XSD wrong. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 09:47: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 2FD133A6B08; Mon, 6 Oct 2008 09:47: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 B0BB03A6B08 for ; Mon, 6 Oct 2008 09:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.764 X-Spam-Level: X-Spam-Status: No, score=-0.764 tagged_above=-999 required=5 tests=[AWL=-1.018, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MANGLED_TOOL=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 DfT7QYqRwGDf for ; Mon, 6 Oct 2008 09:46:59 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id DDE863A6B10 for ; Mon, 6 Oct 2008 09:46:58 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id B7C6E616001; Mon, 6 Oct 2008 18:47:01 +0200 (CEST) Date: Mon, 06 Oct 2008 18:49:28 +0200 (CEST) Message-Id: <20081006.184928.10128207.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48EA3F75.6030105@netconfcentral.com> References: <200810061619.m96GJReG029192@idle.juniper.net> <48EA3F75.6030105@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] 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 Andy Bierman wrote: > I have some concerns with the NETMOD WG process here. > Integrating your solution proposal into the WG draft > presumes the WG understands and has agreed upon > the problem that needs to be solved. We will of course not publish anything that the WG does not decide to publish. We wrote it in this form (as a diff to -01) to make the proposal complete and hoped it would be easier to understand this way. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 09:56: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 A8F673A6A48; Mon, 6 Oct 2008 09:56: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 62FA83A6A48 for ; Mon, 6 Oct 2008 09:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[AWL=-1.072, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=0.6, MANGLED_TOOL=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 69Vd96G0u4bq for ; Mon, 6 Oct 2008 09:56:53 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id A8BDE3A6AFC for ; Mon, 6 Oct 2008 09:56:53 -0700 (PDT) Received: (qmail 63907 invoked from network); 6 Oct 2008 16:57:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.69.54 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 6 Oct 2008 16:57:27 -0000 X-YMail-OSG: bTzCxAUVM1k6ILj5AEDBghTwpBKklz9S1BZPQ.P.jwzUkZyqvpipT3JjByRRmYfNBd313ok3cSFwsjsC_sVDdjm.8do6U1rOo7ZA_b3lY58wcFcjXlc.uGwJtEj1q2VLzQcfmwOqA9LL_Yo25VfuuoU7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48EA4376.4090802@netconfcentral.com> Date: Mon, 06 Oct 2008 09:57:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <200810061619.m96GJReG029192@idle.juniper.net> <48EA3F75.6030105@netconfcentral.com> <20081006.184928.10128207.mbj@tail-f.com> In-Reply-To: <20081006.184928.10128207.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> I have some concerns with the NETMOD WG process here. >> Integrating your solution proposal into the WG draft >> presumes the WG understands and has agreed upon >> the problem that needs to be solved. > > We will of course not publish anything that the WG does not decide to > publish. We wrote it in this form (as a diff to -01) to make the > proposal complete and hoped it would be easier to understand this way. > Of course, but the WG discussed the if-feature part of the proposal, and (I think) has consensus on that part. But the deviation stuff has not been discussed by the WG. I do not agree that the "DM + DM-patch" approach is going to work. I do not think semantic equivalence will be preserved, and if the problem is purely semantic, then the agent should handle the patch in the NETCONF implementation. Presuming that every application should use a different foo.yang for every single platform it wants to manage doesn't seem like "standards-based" to me. > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 10:54: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 21C573A6AFF; Mon, 6 Oct 2008 10:54: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 9DB7D3A6B0C for ; Mon, 6 Oct 2008 10:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 yHBwyo-KEkk4 for ; Mon, 6 Oct 2008 10:54:01 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id E1DC33A6AEC for ; Mon, 6 Oct 2008 10:53:59 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Mon, 06 Oct 2008 10:53:11 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Oct 2008 10:53:15 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Oct 2008 10:53:15 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 10:53:14 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m96HrDM04675; Mon, 6 Oct 2008 10: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 m96HmvsU030192; Mon, 6 Oct 2008 17:48:57 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200810061748.m96HmvsU030192@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20081006.184606.66034389.mbj@tail-f.com> Date: Mon, 06 Oct 2008 13:48:57 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 Oct 2008 17:53:14.0460 (UTC) FILETIME=[67CDD1C0:01C927DC] Cc: netmod@ietf.org Subject: Re: [netmod] 7.13.4 -- put back the element X-BeenThere: netmod@ietf.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: >Usually in these cases the text is right and the XSD wrong. Amen. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 10:54: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 416CB3A67FC; Mon, 6 Oct 2008 10:54: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 B2B713A6AE7 for ; Mon, 6 Oct 2008 10:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 i2YcsEnNpYp4 for ; Mon, 6 Oct 2008 10:54:22 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id BE2AE3A67FC for ; Mon, 6 Oct 2008 10:54:20 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Mon, 06 Oct 2008 10:54:00 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, 6 Oct 2008 10:52:57 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Oct 2008 10:52:57 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 10:52:56 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m96HquM04505; Mon, 6 Oct 2008 10:52:56 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m96HmedU030171; Mon, 6 Oct 2008 17:48:40 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200810061748.m96HmedU030171@idle.juniper.net> To: Andy Bierman In-reply-to: <48EA4376.4090802@netconfcentral.com> Date: Mon, 06 Oct 2008 13:48:40 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 Oct 2008 17:52:56.0757 (UTC) FILETIME=[5D408E50:01C927DC] Cc: netmod@ietf.org Subject: Re: [netmod] 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: , 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: >Of course, but the WG discussed the if-feature part of the proposal, >and (I think) has consensus on that part. But the deviation stuff >has not been discussed by the WG. Can we call for concensus? The architecture on the table allows for three levels of conformance: - basic modeling - modeler-defined options (features) - vendor deviations from the standard model (deviations) IMHO assuming all vendors faithfully implement standards flies in the face of historical evidence. Even for the normal "I don't implement that" and "my default isn't the standards" and "I only support 15 peers instead of an unlimited number" sorts of deviations, it is incredibly valuable to have this knowledge at hand. >I do not think semantic equivalence will be preserved, >and if the problem is purely semantic, then the agent should >handle the patch in the NETCONF implementation. It's not equivance. We're not talking about removing leafs and replacing them with proprietary clones. We're talking about what to do when you can't, say, support the byte counter because your hardware doesn't have byte counters, or you can't support the unix permission bits because some architect decided to base your router-os on windows. Or you support a "better" way of storing your arp cache that the standard doesn't allow for. Or you have a fixed number of BGP peers instead of infinite. Or you only support one user login. Or your interfaces are fixed. Or anyone of a thousand realities that might lie outside the standard model. Sorry, but the world aighn't flat. We can bend to match the curve or we can decide not to solve a very real problem. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 11:14: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 87D1628C10D; Mon, 6 Oct 2008 11:14: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 CB29628C146 for ; Mon, 6 Oct 2008 11:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[AWL=0.485, 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 TXto6CTwA3eX for ; Mon, 6 Oct 2008 11:14:44 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 0650728C111 for ; Mon, 6 Oct 2008 11:14:44 -0700 (PDT) Received: (qmail 26910 invoked from network); 6 Oct 2008 18:14:20 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.69.54 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 6 Oct 2008 18:14:19 -0000 X-YMail-OSG: WZgQPYMVM1lYPIiiIDmjalPTO4LzC74btPqA7bnRhufB90dcYZl6gRM_E1yUKRJYHrFd6gOaKlwpkINxw3oeljoVqA1KHf5Z_y79DjdN88juNaJCmg9s4GCOBG2CivIndcs- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48EA5579.7080007@netconfcentral.com> Date: Mon, 06 Oct 2008 11:14:17 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Phil Shafer References: <200810061748.m96HmedU030171@idle.juniper.net> In-Reply-To: <200810061748.m96HmedU030171@idle.juniper.net> Cc: netmod@ietf.org Subject: Re: [netmod] 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 Phil Shafer wrote: > Andy Bierman writes: >> Of course, but the WG discussed the if-feature part of the proposal, >> and (I think) has consensus on that part. But the deviation stuff >> has not been discussed by the WG. > > Can we call for concensus? The architecture on the table allows > for three levels of conformance: > > - basic modeling > - modeler-defined options (features) > - vendor deviations from the standard model (deviations) > > IMHO assuming all vendors faithfully implement standards flies in > the face of historical evidence. Even for the normal "I don't > implement that" and "my default isn't the standards" and "I only > support 15 peers instead of an unlimited number" sorts of deviations, > it is incredibly valuable to have this knowledge at hand. > >> I do not think semantic equivalence will be preserved, >> and if the problem is purely semantic, then the agent should >> handle the patch in the NETCONF implementation. > > It's not equivance. We're not talking about removing leafs and > replacing them with proprietary clones. We're talking about what > to do when you can't, say, support the byte counter because your > hardware doesn't have byte counters, or you can't support the unix > permission bits because some architect decided to base your router-os > on windows. Or you support a "better" way of storing your arp cache > that the standard doesn't allow for. Or you have a fixed number > of BGP peers instead of infinite. Or you only support one user > login. Or your interfaces are fixed. Or anyone of a thousand > realities that might lie outside the standard model. > I think data model design and feature-based conformance can be used to address these issues. Documenting the platform restrictions wrt/ data model is fine. I think the ABNF in the proposal allows for fairly arbitrary 'adjustment' to the data model, which goes beyond missing or restricted knobs. Replacing parts of the standard with your 'better' proprietary solution is not OK. Augmenting the standard solution with your better solution, so both are available, is OK. > Sorry, but the world aighn't flat. We can bend to match the curve > or we can decide not to solve a very real problem. > Several years ago, during the OPS-NM road-show phase of requirements gathering, one clear message seemed to have consensus -- which is that "standards-based" means "doing common things in a common way". There aren't any standard NETCONF config models yet, and it seems premature to conclude that vendors will not be able to implement the YANG data models that WGs produce in the future. > Thanks, > Phil > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 6 20:03:58 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FE173A682B; Mon, 6 Oct 2008 20:03:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F7DE3A682B for ; Mon, 6 Oct 2008 20:03:56 -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 IcPmW7QQdExw for ; Mon, 6 Oct 2008 20:03:55 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 3A5F43A6B2C for ; Mon, 6 Oct 2008 20:03:53 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Mon, 06 Oct 2008 20:03:47 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Oct 2008 20:03:20 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Oct 2008 20:03:20 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 19:55: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 m972tkM49872; Mon, 6 Oct 2008 19:55: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 m972pTNx032872; Tue, 7 Oct 2008 02:51:29 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200810070251.m972pTNx032872@idle.juniper.net> To: Andy Bierman In-reply-to: <48EA5579.7080007@netconfcentral.com> Date: Mon, 06 Oct 2008 22:51:29 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 Oct 2008 02:55:46.0550 (UTC) FILETIME=[325C9160:01C92828] Cc: netmod@ietf.org Subject: Re: [netmod] 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: , 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 data model design and feature-based conformance >can be used to address these issues. Documenting >the platform restrictions wrt/ data model is fine. Deviations document the platform restrictions wrt/ data models in a formal grammar that allows apps to learn these restrictions. >I think the ABNF in the proposal allows for fairly >arbitrary 'adjustment' to the data model, which goes >beyond missing or restricted knobs. Replacing parts >of the standard with your 'better' proprietary solution >is not OK. Augmenting the standard solution with your >better solution, so both are available, is OK. I'm not saying if it's okay or not. I'm not making value judgements. I'm saying that these sorts of engineering trade-offs are made all the time and compliance to standards is not always the winner. This has certainly been the way the world worked in the past, it's definitely the way the world works now, and as much as I see goodness and light in a YANG/NETCONF world, I don't see it changing the basic calculus that "time to market", "cost of goods", and plain ole dumbness aren't going to be vanquished by our specs. This is a real problem. Are we going to solve it? Are we going to avoid it? If we avoid it, are we really helping interoperability by not equiping apps with the tools needed for the real world? Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Oct 7 08:55:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A23C53A689C; Tue, 7 Oct 2008 08:55:20 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6DB53A6951 for ; Tue, 7 Oct 2008 08:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.664, 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 q-U0ZHwKcSp7 for ; Tue, 7 Oct 2008 08:55:15 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id E88583A689C for ; Tue, 7 Oct 2008 08:55:15 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id Pq7l1a00E0mlR8UA4rvuEo; Tue, 07 Oct 2008 15:55:54 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id Prvq1a00T4HwxpC8XrvrNf; Tue, 07 Oct 2008 15:55:54 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=CU4Spq6YbfsirOKLitAA:9 a=1ByucW3sSlbtYhChGi8A:7 a=hMG4xxxTFPLMa9RejAuLFuaFneYA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Phil Shafer'" , "'Andy Bierman'" References: <48EA5579.7080007@netconfcentral.com> <200810070251.m972pTNx032872@idle.juniper.net> Date: Tue, 7 Oct 2008 11:55:50 -0400 Message-ID: <00d501c92895$2dc122c0$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: <200810070251.m972pTNx032872@idle.juniper.net> Thread-Index: AckoKW6I6C6jVfaxTOiIQ3XT3ws4gQAa0BYg Cc: netmod@ietf.org Subject: Re: [netmod] 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, My real world experience says that vendors don't want to publish how their implementations differ from the standard; that could hurt their ability to sell their products and you don't market your "flaws". AGENT-CAPABILITIES in SNMPv3 went nowhere. dbh > -----Original Message----- > From: netmod-bounces@ietf.org > [mailto:netmod-bounces@ietf.org] On Behalf Of Phil Shafer > Sent: Monday, October 06, 2008 10:51 PM > To: Andy Bierman > Cc: netmod@ietf.org > Subject: Re: [netmod] conformance > > Andy Bierman writes: > >I think data model design and feature-based conformance > >can be used to address these issues. Documenting > >the platform restrictions wrt/ data model is fine. > > Deviations document the platform restrictions wrt/ data models in > a formal grammar that allows apps to learn these restrictions. > > >I think the ABNF in the proposal allows for fairly > >arbitrary 'adjustment' to the data model, which goes > >beyond missing or restricted knobs. Replacing parts > >of the standard with your 'better' proprietary solution > >is not OK. Augmenting the standard solution with your > >better solution, so both are available, is OK. > > I'm not saying if it's okay or not. I'm not making value judgements. > I'm saying that these sorts of engineering trade-offs are made all > the time and compliance to standards is not always the winner. This > has certainly been the way the world worked in the past, it's > definitely the way the world works now, and as much as I see goodness > and light in a YANG/NETCONF world, I don't see it changing the basic > calculus that "time to market", "cost of goods", and plain ole > dumbness aren't going to be vanquished by our specs. > > This is a real problem. Are we going to solve it? Are we going > to avoid it? If we avoid it, are we really helping interoperability > by not equiping apps with the tools needed for the real world? > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Oct 7 10:01: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 DC4973A6AEA; Tue, 7 Oct 2008 10:01: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 5B6283A690B for ; Tue, 7 Oct 2008 10:01:10 -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 ZvDOoWwOCqZ6 for ; Tue, 7 Oct 2008 10:01:06 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 573E63A6AEA for ; Tue, 7 Oct 2008 10:01:06 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Tue, 07 Oct 2008 10:01:20 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, 7 Oct 2008 10:01:30 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 10:01:29 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Oct 2008 10:01: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 m97H1SM29533; Tue, 7 Oct 2008 10:01:28 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m97Gv9Nq037416; Tue, 7 Oct 2008 16:57:09 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200810071657.m97Gv9Nq037416@idle.juniper.net> To: "David Harrington" In-reply-to: <00d501c92895$2dc122c0$0600a8c0@china.huawei.com> Date: Tue, 07 Oct 2008 12:57:09 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 Oct 2008 17:01:29.0027 (UTC) FILETIME=[573C1930:01C9289E] Cc: netmod@ietf.org Subject: Re: [netmod] 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: , 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: >My real world experience says that vendors don't want to publish how >their implementations differ from the standard; that could hurt their >ability to sell their products and you don't market your "flaws". Wise app writers would arrange an "out of band" mechanism for associating deviations modules with devices. But the standard should still have a proper mechanism for doing this. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 8 04:23:58 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2318F3A681B; Wed, 8 Oct 2008 04:23:58 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B32C3A6841 for ; Wed, 8 Oct 2008 04:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVbIs003CR+v for ; Wed, 8 Oct 2008 04:23: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 5BA7B3A681B for ; Wed, 8 Oct 2008 04:23:52 -0700 (PDT) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id QAeB1a00S0cQ2SLA2BPsAo; Wed, 08 Oct 2008 11:23:52 +0000 Received: from Harrington73653 ([208.253.76.35]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id QBPh1a00C0lhtQY8WBPkJt; Wed, 08 Oct 2008 11:23:49 +0000 X-Authority-Analysis: v=1.0 c=1 a=tWGVwseMt6IaghbwJaUA:9 a=mally0DZASkD14PXIsaOJGy6ZxAA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Wed, 8 Oct 2008 07:23:41 -0400 Message-ID: <004f01c92938$55c23c70$efa911ac@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: AckpOFEXktMPS7pZTViCU2/N4sO74w== Subject: [netmod] carpooling X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, For those at the interim and staying at the Homestead, I have a car that will hold 5. I am in room 255. Let me know if you want a ride. 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 Oct 8 04:35:05 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C1A73A6809; Wed, 8 Oct 2008 04:35:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64C443A693F for ; Wed, 8 Oct 2008 04:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 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 jKnmsaugH4ZM for ; Wed, 8 Oct 2008 04:35:03 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id B8F423A6841 for ; Wed, 8 Oct 2008 04:35:03 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id QAk81a00A0x6nqcA7BblU9; Wed, 08 Oct 2008 11:35:45 +0000 Received: from Harrington73653 ([208.253.76.35]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id QBbb1a00B0lhtQY8YBbett; Wed, 08 Oct 2008 11:35:42 +0000 X-Authority-Analysis: v=1.0 c=1 a=MgEvFt6Ljs5twP1wYZYA:9 a=Q3_vRIgTVlJp03yWoYyaQM9PJlcA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=oqs56FR1YJwA:10 From: "David Harrington" To: Date: Wed, 8 Oct 2008 07:35:35 -0400 Message-ID: <005101c92939$feed77a0$efa911ac@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: AckpOfp8UD/mMQWnRN6+cn58yuJSoA== Subject: [netmod] carpooling X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 to do this on the ML, but we didn't set up an interim ML. Most attendees are meeting at the Chick-filet (or whatever) across fomr the front of the hotel. See you there, or see you at Juniper. 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 Oct 8 14:41: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 BE97D3A67DB; Wed, 8 Oct 2008 14:41: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 04CD63A68A1 for ; Wed, 8 Oct 2008 14:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=0.017, 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 YPV3oCkkI0WL for ; Wed, 8 Oct 2008 14:41:43 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id EA3073A689E for ; Wed, 8 Oct 2008 14:41:42 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D68952023D for ; Wed, 8 Oct 2008 23:42:23 +0200 (CEST) X-AuditID: c1b4fb3c-ad0ccbb0000015b5-24-48ed293f14f0 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C3C5520850 for ; Wed, 8 Oct 2008 23:42:23 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Oct 2008 23:42:22 +0200 Received: from [127.0.0.1] ([159.107.197.237]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Oct 2008 23:42:21 +0200 Message-ID: <48ED2593.4070809@ericsson.com> Date: Wed, 08 Oct 2008 23:26:43 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netmod@ietf.org X-OriginalArrivalTime: 08 Oct 2008 21:42:22.0103 (UTC) FILETIME=[BEDD2A70:01C9298E] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Change control rules minutes - provisional (!!!!) 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 2008-10-08 Datatypes, normalization, lexical/value representation ------------------------------------------------------ For all data types have a normailzed lexical form Data is compared in value format edit-config + get-config: might bring back a different lexical form netconf server must send back data in the normalized form description of the lexical space of each type will be in plain english it will be in description clause or a separate normalization clause check which datatypes need the normalization explained both for base yang draft and the datatypes draft Update rules ------------------------------------------------------ Protect old clients, Protect old importing modules Allowed: new typedefs new groupings expand value range remove must add new optional stuff allow new rpc allow new notifications allow new data in existing notifications allow new optional parameters to rpc input(?) allow new parameters to rpc output(?) remove mandatory reference (update) description (semantic equivalence) status (in one direction) length add default(?) add new bits add new enum values at the end of the list config false ->true - Not allowed: delete nodes leaf order changes (due to strict encoding order) change basic type uint8 -> int8 change length restriction of string make a type into union no new mandatory nodes change datatype of a leaf (underlying datatype at the base of the type hierarchy) add new membertypes to a union change units change default add iffeature change the value of enum add enums in the middle - Ericsson Question ================== Why do we allow extension of value range? Why is the exact versioning good? Doesn't it result in too many version _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Oct 10 03:36:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F7BA3A6955; Fri, 10 Oct 2008 03:36:46 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72873A6990 for ; Fri, 10 Oct 2008 03:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.193 X-Spam-Level: * X-Spam-Status: No, score=1.193 tagged_above=-999 required=5 tests=[AWL=-1.808, BAYES_50=0.001, J_CHICKENPOX_29=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bOGupq+oUoB for ; Fri, 10 Oct 2008 03:36: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 8B1203A6955 for ; Fri, 10 Oct 2008 03:36:38 -0700 (PDT) X-Trace: 145448521/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.144.25 X-SBRS: None X-RemoteIP: 62.188.144.25 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEAGfN7kg+vJAZ/2dsb2JhbACDUz+IZLBbBYFn X-IronPort-AV: E=Sophos;i="4.33,389,1220223600"; d="scan'208";a="145448521" X-IP-Direction: IN Received: from 1cust25.tnt15.lnd4.gbr.da.uu.net (HELO allison) ([62.188.144.25]) by smtp.pipex.tiscali.co.uk with SMTP; 10 Oct 2008 11:36:08 +0100 Message-ID: <030901c92aba$8d026d80$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" References: <48E94E66.3080202@netconfcentral.com> <20081006.093241.33474258.mbj@tail-f.com> <48E9D37F.8050000@netconfcentral.com> <20081006.131300.172045470.mbj@tail-f.com><1223292223.6327.32.camel@missotis> <48EA3BDD.5040605@netconfcentral.com> Date: Fri, 10 Oct 2008 11:27:23 +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] 7.13.4 -- put back the element X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SSBhZ3JlZSB3aXRoIEFuZHkgb24gdGhpcy4KCkJhY2sgb24gMjFzdCBBdWd1c3QsIG9uIHRoZSBO ZXRjb25mIGxpc3QsIEJlcnQgYXNrZWQgZm9yIHRleHQgb24gd2hhdCBJIHRha2UgdG8KYmUgdGhp cyBpc3N1ZSB0byBkaXNjdXNzIGFuZCBJIGRvIG5vdCByZWNhbGwgc2VlaW5nIHRoaXMgdGV4dCBv ciB0aGUgZGlzY3Vzc2lvbi4KCklmIDcuMTMuNCBpcyB0aGlzIHRleHQsIHRoZW4gSSBhbSBhZ2Fp bnN0IGl0LgoKQW5kIHNob3VsZCB0aGlzIGRpc2N1c3Npb24gYmUgb24gdGhlIE5ldGNvbmYgbGlz dCBpbnN0ZWFkIG9yIGFzIHdlbGw/CgpUb20gUGV0Y2gKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0KRnJvbTogIkFuZHkgQmllcm1hbiIgPGFuZHlAbmV0Y29uZmNlbnRyYWwuY29tPgpUbzog IkxhZGlzbGF2IExob3RrYSIgPGxob3RrYUBjZXNuZXQuY3o+CkNjOiA8bmV0bW9kQGlldGYub3Jn PgpTZW50OiBNb25kYXksIE9jdG9iZXIgMDYsIDIwMDggNjoyNSBQTQpTdWJqZWN0OiBSZTogW25l dG1vZF0gNy4xMy40IC0tIHB1dCBiYWNrIHRoZSA8ZGF0YT4gZWxlbWVudAoKCj4gTGFkaXNsYXYg TGhvdGthIHdyb3RlOgo+ID4gTWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBQbyAwNi4gMTAuIDIw MDggdiAxMzoxMyArMDIwMDoKPiA+PiBBbmR5IEJpZXJtYW4gPGFuZHlAbmV0Y29uZmNlbnRyYWwu Y29tPiB3cm90ZToKPiA+Pj4gVGhlIGRyYWZ0IG1lbnRpb25zIHRoYXQgdGhlIG5hbWVzcGFjZSBV UkkgZGVmaW5lZCBieSBSRkMgNDc0MQo+ID4+PiBpcyByZXNlcnZlZCBhbmQgY2FuIG5vdCBldmVy IGJlIHVzZWQgaW4gYSBZQU5HIG1vZHVsZT8KPiA+PiBObyBvZiBjb3Vyc2Ugbm90LiAgSXQgd291 bGQgYmUgdmVyeSB1c2VmdWwgaWYgd2UgaGFkIGEgbmV0Y29uZi55YW5nCj4gPgo+ID4gQnV0IGNh biBpdCBiZSBkb25lPyBGb3Igb25lLCBZQU5HIGNhbm5vdCBtb2RlbCBYTUwgYXR0cmlidXRlcy4K PiA+Cj4KPiBJIHVzZSBhbiBleHRlbnNpb24gY2FsbGVkICdtZXRhZGF0YScgZm9yIHRoYXQuCj4g QXQgZmlyc3QgSSBoYXRlZCB0aGUgZXh0ZW5zaW9uLXN0bXQsIG5vdyBJIHRoaW5rIGl0J3MKPiBv bmUgb2YgdGhlIGJlc3QgcGFydHMgb2YgWUFORy4KPgo+IEkgdXNlIHRoZSBhdHRhY2hlZCBuZXRj b25mLnlhbmcgZmlsZSBpbiBteSBkYXRhLWRyaXZlbgo+IHRvb2xzLiAgKFdhcm5pbmc6IG1heSBu b3QgYmUgMTAwJSBkZWJ1Z2dlZCB5ZXQuCj4gSXQgd29uJ3QgY29tcGlsZSB3aXRob3V0IHRoZSBv dGhlciBtb2R1bGVzIHRvby4pCj4KPiBJIHdhbnQgdG8gYmUgYWJsZSB0byB1c2UgdGhlIHNhbWUg J3JwYy1yZXBseScgY29udGFpbmVyCj4gZm9yIGV2ZXJ5IFJQQyBtZXNzYWdlLCBhbmQgbm90IGdl bmVyYXRlIGEgJ2Zvby1ycGMtcmVwbHknCj4gY29udGFpbmVyIGZvciBldmVyeSBSUEMgbWV0aG9k LiAgVGhlIHN0YWJsZSBhbnl4bWwgJ2RhdGEnCj4gbm9kZSBpcyB2ZXJ5IHVzZWZ1bCBmb3IgaGFu ZGxpbmcgdGhlIFJQQyByZXBseSBpbiBhIGNlbnRyYWxpemVkCj4gZGlzcGF0Y2hlci4KPgo+IEkg dGhpbmsgdGhlIE5FVENPTkYgV0cgZ290IGl0IHJpZ2h0IGJ5IGNsZWFyaW5nIGlkZW50aWZ5aW5n Cj4gdGhlIGNvbnRlbnQgcGF5bG9hZCBpbiB0aGUgPHJwYy1yZXBseT4uICBJIG5vIGxvbmdlciBh Z3JlZQo+IHdpdGggdGhlIHJlY2VudCBpbnRlcnByZXRhdGlvbiB0aGF0IHRoZSA8ZGF0YT4gbm9k ZSBpbiB0aGUgWFNECj4ganVzdCBhcHBsaWVzIHRvIHRoZSBSUEMgbWV0aG9kcyBpbiBSRkMgNDc0 MS4gIFRoZSBXRyBjbGVhcmx5Cj4gaW50ZW5kZWQgdG8gY3JlYXRlIGFuIFhTRCB0aGF0IGFwcGxp ZXMgdG8gYWxsIFJQQ3MuCj4KPiBJbiBvcmRlciB0byByZXByZXNlbnQgdGhlIG5ldyBycGMtcmVw bHkgaW4gWUFORywgeW91IHdvdWxkCj4gaGF2ZSB0aGUgdXNlbGVzcyBjb25zdHJ1Y3Q6Cj4KPiAg ICAgYW55eG1sIHJwYy1yZXBseSB7Cj4gICAgICAgICBjb25maWcgZmFsc2U7Cj4gICAgIH0KPgo+ Cj4KPgo+ID4gTGFkYQo+Cj4KPiBBbmR5Cj4KPiA+Cj4gPj4gbW9kdWxlIHB1Ymxpc2hlZC4gIFRo ZSA8Z2V0PiBvcGVyYXRpb24gY291bGQgYmUgc29tZXRoaW5nIGxpa2U6Cj4gPj4KPiA+PiAgIHJw YyBnZXQgewo+ID4+ICAgIGlucHV0IHsKPiA+PiAgICAgIGFueXhtbCBmaWx0ZXI7Cj4gPj4gICAg fQo+ID4+ICAgIG91dHB1dCB7Cj4gPj4gICAgICBhbnl4bWwgZGF0YTsKPiA+PiAgICB9Cj4gPj4g IH0KPiA+Pgo+ID4+Cj4gPj4KPiA+PiAvbWFydGluCj4gPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KPiA+PiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4gPj4g bmV0bW9kQGlldGYub3JnCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QKPgo+CgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCgo+IG1vZHVsZSBuZXRjb25m IHsKPgo+ICAgIG5hbWVzcGFjZSAidXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6 MS4wIjsKPgo+ICAgIHByZWZpeCAibmMiOwo+Cj4gICAgLy8gZm9yIFhTRCB0eXBlcyBsaWtlIGFu eVVSSQo+ICAgIGltcG9ydCB4c2QgeyBwcmVmaXggInhzIjsgfQo+Cj4gICAgLy8gZm9yIE5DWCAn bWV0YWRhdGEnIGxhbmd1YWdlIGV4dGVuc2lvbgo+ICAgIGltcG9ydCBuY3ggeyBwcmVmaXggIm5j eCI7IH0KPgo+ICAgIGRlc2NyaXB0aW9uCj4gICAgICAgIk5FVENPTkYgUHJvdG9jb2wKPiAgICAg ICAgICogRGF0YSBUeXBlcwo+ICAgICAgICAgKiBBYnN0cmFjdCBvYmplY3QgZm9yIFBEVSBjb21w b25lbnRzCj4gICAgICAgICAqIFJQQ3MKPiAgICAgICAgVHJhbnNsYXRlZCBmcm9tIFJGQyA0NzQx LiI7Cj4KPiAgICBjb250YWN0Cj4gICAgICAiVHJhbnNsYXRlZCBieSBBbmR5IEJpZXJtYW4uCj4g ICAgICAgU2VuZCBjb21tZW50cyB0byA8YW5keUBuZXRjb25mY2VudHJhbC5jb20+LiI7Cj4KPiAg ICByZXZpc2lvbiAiMjAwOC0wOC0zMCIgewo+ICAgICAgZGVzY3JpcHRpb24KPiAgICAgICAgIkFk ZCBzb21lIE5DWCBleHRlbnNpb25zIHRvIGF1dG9tYXRlIHNvbWUgYWdlbnQgcHJvY2Vzc2luZy4i Owo+ICAgIH0KPgo+ICAgIHJldmlzaW9uICIyMDA4LTA0LTI2IiB7Cj4gICAgICBkZXNjcmlwdGlv bgo+ICAgICAgICAiQ2hhbmdlIGdldC1jb25maWcgYW5kIGdldCBvdXRwdXQgZnJvbSAnY29uZmln JyB0byAnZGF0YScuIjsKPiAgICB9Cj4KPiAgICByZXZpc2lvbiAiMjAwOC0wNC0xNiIgewo+ICAg ICAgZGVzY3JpcHRpb24KPiAgICAgICAgIkluaXRpYWwgY29udmVyc2lvbiBmcm9tIG5ldGNvbmYu bmN4IHZlcnNpb24gMC42LiI7Cj4gICAgfQo+Cj4gICAgLy8gTkVUQ09ORiBTaW1wbGUgVHlwZXMK Pgo+ICAgIHR5cGVkZWYgTGFuZ3VhZ2Ugewo+ICAgICAgZGVzY3JpcHRpb24gIlhNTCBsYW5ndWFn ZSB0eXBlIGZvciBMYW5nU3RyaW5nIjsKPiAgICAgIHR5cGUgc3RyaW5nIHsKPiAgICAgICAgcGF0 dGVybiAnW2EtekEtWl17MSw4fSgtW2EtekEtWjAtOV17MSw4fSkqJzsKPiAgICAgIH0KPiAgICB9 Cj4KPiAgICB0eXBlZGVmIFNlc3Npb25JZCB7Cj4gICAgICBkZXNjcmlwdGlvbiAiTkVUQ09ORiBT ZXNzaW9uIElkIjsKPiAgICAgIHR5cGUgdWludDMyIHsKPiAgICAgICAgcmFuZ2UgIjEuLm1heCI7 Cj4gICAgICB9Cj4gICAgfQo+Cj4gICAgdHlwZWRlZiBTZXNzaW9uSWRPclplcm8gewo+ICAgICAg ZGVzY3JpcHRpb24KPiAgICAgICAgIk5FVENPTkYgU2Vzc2lvbiBJZCBvciBaZXJvIHRvIGluZGlj YXRlIG5vbmUiOwo+ICAgICAgdHlwZSB1aW50MzI7Cj4gICAgfQo+Cj4gICAgdHlwZWRlZiBMYW5n U3RyaW5nIHsKPiAgICAgIGRlc2NyaXB0aW9uICJYTUwgc3RyaW5nIHdpdGggYSBsYW5ndWFnZSBh dHRyaWJ1dGUuIjsKPiAgICAgIHR5cGUgc3RyaW5nOwo+ICAgICAgbmN4Om1ldGFkYXRhICJMYW5n dWFnZSBsYW5nIjsKPiAgICB9Cj4KPiAgICB0eXBlZGVmIE1lc3NhZ2VJZCB7Cj4gICAgICBkZXNj cmlwdGlvbiAiTkVUQ09ORiBtZXNzYWdlLWlkIGF0dHJpYnV0ZSI7Cj4gICAgICB0eXBlICBzdHJp bmcgewo+ICAgICAgICAgbGVuZ3RoICIxLi40MDk1IjsKPiAgICAgIH0KPiAgICB9Cj4KPiAgICB0 eXBlZGVmIEVycm9yVHlwZSB7Cj4gICAgICBkZXNjcmlwdGlvbiAiTkVUQ09ORiBFcnJvciBUeXBl IjsKPiAgICAgIHR5cGUgZW51bWVyYXRpb24gewo+ICAgICAgICBlbnVtIHRyYW5zcG9ydDsKPiAg ICAgICAgZW51bSBycGM7Cj4gICAgICAgIGVudW0gcHJvdG9jb2w7Cj4gICAgICAgIGVudW0gYXBw bGljYXRpb247Cj4gICAgICB9Cj4gICAgfQo+Cj4gICAgdHlwZWRlZiBFcnJvclRhZyB7Cj4gICAg ICBkZXNjcmlwdGlvbiAiTkVUQ09ORiBFcnJvciBUYWciOwo+ICAgICAgdHlwZSBlbnVtZXJhdGlv biB7Cj4gICAgICAgIGVudW0gaW4tdXNlOwo+ICAgICAgICBlbnVtIGludmFsaWQtdmFsdWU7Cj4g ICAgICAgIGVudW0gdG9vLWJpZzsKPiAgICAgICAgZW51bSBtaXNzaW5nLWF0dHJpYnV0ZTsKPiAg ICAgICAgZW51bSBiYWQtYXR0cmlidXRlOwo+ICAgICAgICBlbnVtIHVua25vd24tYXR0cmlidXRl Owo+ICAgICAgICBlbnVtIG1pc3NpbmctZWxlbWVudDsKPiAgICAgICAgZW51bSBiYWQtZWxlbWVu dDsKPiAgICAgICAgZW51bSB1bmtub3duLWVsZW1lbnQ7Cj4gICAgICAgIGVudW0gdW5rbm93bi1u YW1lc3BhY2U7Cj4gICAgICAgIGVudW0gYWNjZXNzLWRlbmllZDsKPiAgICAgICAgZW51bSBsb2Nr LWRlbmllZDsKPiAgICAgICAgZW51bSByZXNvdXJjZS1kZW5pZWQ7Cj4gICAgICAgIGVudW0gcm9s bGJhY2stZmFpbGVkOwo+ICAgICAgICBlbnVtIGRhdGEtZXhpc3RzOwo+ICAgICAgICBlbnVtIGRh dGEtbWlzc2luZzsKPiAgICAgICAgZW51bSBvcGVyYXRpb24tbm90LXN1cHBvcnRlZDsKPiAgICAg ICAgZW51bSBvcGVyYXRpb24tZmFpbGVkOwo+ICAgICAgICBlbnVtIHBhcnRpYWwtb3BlcmF0aW9u Owo+ICAgICAgfQo+ICAgIH0KPgo+ICAgIHR5cGVkZWYgRXJyb3JTZXZlcml0eSB7Cj4gICAgICBk ZXNjcmlwdGlvbiAiTkVUQ09ORiBFcnJvciBTZXZlcml0eSI7Cj4gICAgICB0eXBlIGVudW1lcmF0 aW9uIHsKPiAgICAgICAgZW51bSBlcnJvcjsKPiAgICAgICAgZW51bSB3YXJuaW5nOwo+ICAgICAg fQo+ICAgIH0KPgo+ICAgIHR5cGVkZWYgVGVzdE9wdGlvblR5cGUgewo+ICAgICAgZGVzY3JpcHRp b24KPiAgICAgICAgIk5FVENPTkYgJ3Rlc3Qtb3B0aW9uJyBFbGVtZW50IENvbnRlbnQuCj4gICAg ICAgICBUaGlzIGlzIGV4dGVuZGVkIHdpdGggdGhlIHRlc3Qtb25seSBlbnVtZXJhdGlvbi4KPiAg ICAgICAgIFRoZSAnc2V0JyBvcHRpb24gaGFzIG5vIHJlYWwgZWZmZWN0IHNpbmNlCj4gICAgICAg ICB0aGUgZW50aXJlIFBEVSBpcyBhbHdheXMgdmFsaWRhdGVkIGJlZm9yZSBhbnkKPiAgICAgICAg IG9mIGl0IGlzIGFwcGxpZWQgKGFsd2F5cyB0ZXN0LXRoZW4tc2V0KS4iOwo+ICAgICAgdHlwZSBl bnVtZXJhdGlvbiB7Cj4gICAgICAgIGVudW0gdGVzdC10aGVuLXNldDsKPiAgICAgICAgZW51bSBz ZXQ7Cj4gICAgICAgIGVudW0gdGVzdC1vbmx5Owo+ICAgICAgfQo+ICAgICAgZGVmYXVsdCAic2V0 IjsKPiAgICB9Cj4KPiAgICB0eXBlZGVmIEVycm9yT3B0aW9uVHlwZSB7Cj4gICAgICBkZXNjcmlw dGlvbiAiTkVUQ09ORiAnZXJyb3Itb3B0aW9uJyBFbGVtZW50IENvbnRlbnQiOwo+ICAgICAgdHlw ZSBlbnVtZXJhdGlvbiB7Cj4gICAgICAgIGVudW0gc3RvcC1vbi1lcnJvcjsKPiAgICAgICAgZW51 bSBjb250aW51ZS1vbi1lcnJvcjsKPiAgICAgICAgZW51bSByb2xsYmFjay1vbi1lcnJvcjsKPiAg ICAgIH0KPiAgICAgIGRlZmF1bHQgInN0b3Atb24tZXJyb3IiOwo+ICAgIH0KPgo+ICAgIHR5cGVk ZWYgRmlsdGVyVHlwZSB7Cj4gICAgICBkZXNjcmlwdGlvbiAiTkVUQ09ORiAnZmlsdGVyJyBBdHRy aWJ1dGUgQ29udGVudCI7Cj4gICAgICB0eXBlIGVudW1lcmF0aW9uIHsKPiAgICAgICAgZW51bSBz dWJ0cmVlOwo+ICAgICAgICBlbnVtIHhwYXRoOwo+ICAgICAgfQo+ICAgICAgZGVmYXVsdCAic3Vi dHJlZSI7Cj4gICAgfQo+Cj4gICAgdHlwZWRlZiBFZGl0T3BlcmF0aW9uVHlwZSB7Cj4gICAgICBk ZXNjcmlwdGlvbiAiTkVUQ09ORiAnb3BlcmF0aW9uJyBBdHRyaWJ1dGUgQ29udGVudCI7Cj4gICAg ICB0eXBlIGVudW1lcmF0aW9uIHsKPiAgICAgICAgZW51bSBtZXJnZTsKPiAgICAgICAgZW51bSBy ZXBsYWNlOwo+ICAgICAgICBlbnVtIGNyZWF0ZTsKPiAgICAgICAgZW51bSBkZWxldGU7Cj4gICAg ICB9Cj4gICAgICBkZWZhdWx0ICJtZXJnZSI7Cj4gICAgfQo+Cj4gICAgdHlwZWRlZiBEZWZhdWx0 T3BlcmF0aW9uVHlwZSB7Cj4gICAgICBkZXNjcmlwdGlvbiAiTkVUQ09ORiAnZGVmYXVsdC1vcGVy YXRpb24nIEVsZW1lbnQgQ29udGVudCI7Cj4gICAgICB0eXBlIGVudW1lcmF0aW9uIHsKPiAgICAg ICAgZW51bSBtZXJnZTsKPiAgICAgICAgZW51bSByZXBsYWNlOwo+ICAgICAgICBlbnVtIG5vbmU7 Cj4gICAgICB9Cj4gICAgICBkZWZhdWx0ICJtZXJnZSI7Cj4gICAgfQo+Cj4gICAgdHlwZWRlZiBD b25maXJtVGltZW91dFR5cGUgewo+ICAgICAgZGVzY3JpcHRpb24KPiAgICAgICAgIk5FVENPTkYg J2NvbmZpcm0tdGltZW91dCcgRWxlbWVudCBDb250ZW50IjsKPiAgICAgIHR5cGUgdWludDMyIHsK PiAgICAgICAgcmFuZ2UgIjEuLm1heCI7Cj4gICAgICB9Cj4gICAgICB1bml0cyAic2Vjb25kcyI7 Cj4gICAgICBkZWZhdWx0ICI2MDAiOyAgIC8vIDEwIG1pbnV0ZXMKPiAgICB9Cj4KPiAgICB0eXBl ZGVmIENvbmZpZ1VSSVR5cGUgewo+ICAgICAgdHlwZSB4czphbnlVUkk7Cj4gICAgfQo+Cj4gICAg Ly8gTkVUQ09ORiBIZWxsbyBQRFUgRGF0YSBUeXBlcwo+Cj4gICAgZ3JvdXBpbmcgTmNDYXBhYmls aXRpZXMgewo+ICAgICAgZGVzY3JpcHRpb24gIkdlbmVyaWMgQ2FwYWJpbGl0aWVzIExpc3QuIjsK Pgo+ICAgICAgY29udGFpbmVyIGNhcGFiaWxpdGllcyB7Cj4gICAgICAgIGNvbmZpZyBmYWxzZTsK PiAgICAgICAgbGVhZi1saXN0IGNhcGFiaWxpdHkgewo+ICAgICAgICAgICBkZXNjcmlwdGlvbiAi T25lIEdlbmVyaWMgQ2FwYWJpbGl0eSBVUkkuIjsKPiAgICAgICAgICAgdHlwZSB4czphbnlVUkk7 Cj4gICAgICAgIH0KPiAgICAgIH0KPiAgICB9Cj4KPiAgICBjb250YWluZXIgYWdlbnQtaGVsbG8g ewo+ICAgICAgZGVzY3JpcHRpb24gIkdlbmVyaWMgQWdlbnQgSGVsbG8gTWVzc2FnZSBQYXJhbWV0 ZXJzLiI7Cj4KPiAgICAgIHVzZXMgTmNDYXBhYmlsaXRpZXM7Cj4KPiAgICAgIGxlYWYgc2Vzc2lv bi1pZCB7Cj4gICAgICAgICB0eXBlIFNlc3Npb25JZDsKPiAgICAgICAgIGNvbmZpZyBmYWxzZTsK PiAgICAgIH0KPgo+ICAgICAgbmN4OmhpZGRlbjsKPiAgICAgIG5jeDphYnN0cmFjdDsKPiAgICB9 Cj4KPiAgICBjb250YWluZXIgbWdyLWhlbGxvIHsKPgo+ICAgICAgZGVzY3JpcHRpb24gIkdlbmVy aWMgTWFuYWdlciBIZWxsbyBNZXNzYWdlIFBhcmFtZXRlcnMuIjsKPgo+ICAgICAgdXNlcyBOY0Nh cGFiaWxpdGllczsKPgo+ICAgICAgbmN4OmhpZGRlbjsKPiAgICAgIG5jeDphYnN0cmFjdDsKPiAg ICB9Cj4KPiAgICAvLyBORVRDT05GIE9wZXJhdGlvbnMgUERVIERhdGEgVHlwZXMKPgo+ICAgIGdy b3VwaW5nIEVycm9ySW5mb0NvbnRlbnQgewo+ICAgICAgZGVzY3JpcHRpb24KPiAgICAgICAgIk5F VENPTkYgc3RhbmRhcmQgJ2Vycm9yLWluZm8nIEVsZW1lbnQgQ29udGVudDsiOwo+Cj4gICAgICBs ZWFmLWxpc3QgYmFkLWF0dHJpYnV0ZSB7Cj4gICAgICAgIGRlc2NyaXB0aW9uCj4gICAgICAgICAg Ik5hbWUgb2YgdGhlIG1pc3Npbmcgb3IgaW52YWxpZCBYU0QgYXR0cmlidXRlLgo+ICAgICAgICAg ICBVc2VkIHdpdGggbWlzc2luZy1hdHRyaWJ1dGUsIGJhZC1hdHRyaWJ1dGUsIGFuZAo+ICAgICAg ICAgICB1bmtub3duLWF0dHJpYnV0ZSBlcnJvci10YWcgdmFsdWVzLiI7Cj4gICAgICAgIHR5cGUg ICB4czpRTmFtZTsKPiAgICAgICAgY29uZmlnIGZhbHNlOwo+ICAgICAgfQo+Cj4gICAgICBsZWFm LWxpc3QgYmFkLWVsZW1lbnQgewo+ICAgICAgICBkZXNjcmlwdGlvbgo+ICAgICAgICAgICJOYW1l IG9mIHRoZSBlbGVtZW50IHRoYXQgY29udGFpbnMgKG9yIHNob3VsZCBjb250YWluKQo+ICAgICAg ICAgICBhbiBpbnZhbGlkIFhTRCBhdHRyaWJ1dGUgd2hlbiB1c2VkIHdpdGggbWlzc2luZy1hdHRy aWJ1dGUsCj4gICAgICAgICAgIGJhZC1hdHRyaWJ1dGUsIHVua25vd24tYXR0cmlidXRlLCBlcnJv ci10YWcgdmFsdWVzLgo+ICAgICAgICAgICBOYW1lIG9mIGFuIGludmFsaWQgb3IgbWlzc2luZyBl bGVtZW50IHdoZW4gdXNlZCB3aXRoCj4gICAgICAgICAgIHRoZW4gbWlzc2luZy1lbGVtZW50LCBi YWQtZWxlbWVudCwgdW5rbm93bi1lbGVtZW50LAo+ICAgICAgICAgICBhbmQgdW5rbm93bi1uYW1l c3BhY2UgZXJyb3ItdGFnIHZhbHVlcy4iOwo+ICAgICAgICB0eXBlICAgeHM6UU5hbWU7Cj4gICAg ICAgIGNvbmZpZyBmYWxzZTsKPiAgICAgIH0KPgo+ICAgICAgbGVhZi1saXN0IG9rLWVsZW1lbnQg ewo+ICAgICAgICBkZXNjcmlwdGlvbgo+ICAgICAgICAgICJJZGVudGlmaWVzIGFuIGVsZW1lbnQg aW4gdGhlIGRhdGEgbW9kZWwKPiAgICAgICAgICAgZm9yIHdoaWNoIHRoZSByZXF1ZXN0ZWQgb3Bl cmF0aW9uIGhhcyBiZWVuIGNvbXBsZXRlZAo+ICAgICAgICAgICBmb3IgdGhhdCBub2RlIGFuZCBh bGwgaXRzIGNoaWxkIG5vZGVzLiAgVGhpcyBlbGVtZW50Cj4gICAgICAgICAgIGNhbiBhcHBlYXIg emVybyBvciBtb3JlIHRpbWVzIGluIHRoZSAnZXJyb3ItaW5mbycKPiAgICAgICAgICAgY29udGFp bmVyLiAgVXNlZCB3aXRoIHRoZSBwYXJ0aWFsLW9wZXJhdGlvbiBlcnJvci10YWcKPiAgICAgICAg ICAgdmFsdWUuIjsKPiAgICAgICAgdHlwZSAgIHhzOlFOYW1lOwo+ICAgICAgICBjb25maWcgZmFs c2U7Cj4gICAgICB9Cj4KPiAgICAgIGxlYWYtbGlzdCBlcnItZWxlbWVudCB7Cj4gICAgICAgIGRl c2NyaXB0aW9uCj4gICAgICAgICAgIklkZW50aWZpZXMgYW4gZWxlbWVudCBpbiB0aGUgZGF0YSBt b2RlbAo+ICAgICAgICAgICBmb3Igd2hpY2ggdGhlIHJlcXVlc3RlZCBvcGVyYXRpb24gaGFzIGZh aWxlZCBmb3IgdGhhdAo+ICAgICAgICAgICBub2RlIGFuZCBhbGwgaXRzIGNoaWxkIG5vZGVzLiAg VGhpcyBlbGVtZW50Cj4gICAgICAgICAgIGNhbiBhcHBlYXIgemVybyBvciBtb3JlIHRpbWVzIGlu IHRoZSAnZXJyb3ItaW5mbycKPiAgICAgICAgICAgY29udGFpbmVyLiAgIFVzZWQgd2l0aCB0aGUg cGFydGlhbC1vcGVyYXRpb24gZXJyb3ItdGFnCj4gICAgICAgICAgIHZhbHVlLiI7Cj4gICAgICAg ICB0eXBlICAgeHM6UU5hbWU7Cj4gICAgICAgICBjb25maWcgZmFsc2U7Cj4gICAgICAgfQo+Cj4g ICAgICAgbGVhZi1saXN0IG5vb3AtZWxlbWVudCB7Cj4gICAgICAgICBkZXNjcmlwdGlvbgo+ICAg ICAgICAgICAiSWRlbnRpZmllcyBhbiBlbGVtZW50IGluIHRoZSBkYXRhIG1vZGVsCj4gICAgICAg ICAgICBmb3Igd2hpY2ggdGhlIHJlcXVlc3RlZCBvcGVyYXRpb24gd2FzIG5vdCBhdHRlbXB0ZWQg Zm9yCj4gICAgICAgICAgICB0aGF0IG5vZGUgYW5kIGFsbCBpdHMgY2hpbGQgbm9kZXMuICBUaGlz IGVsZW1lbnQKPiAgICAgICAgICAgIGNhbiBhcHBlYXIgemVybyBvciBtb3JlIHRpbWVzIGluIHRo ZSA8ZXJyb3ItaW5mbz4KPiAgICAgICAgICAgIGNvbnRhaW5lci4gICBVc2VkIHdpdGggdGhlIHBh cnRpYWwtb3BlcmF0aW9uIGVycm9yLXRhZwo+ICAgICAgICAgICAgdmFsdWUuIjsKPiAgICAgICAg IHR5cGUgICB4czpRTmFtZTsKPiAgICAgICAgIGNvbmZpZyBmYWxzZTsKPiAgICAgICB9Cj4KPiAg ICAgICBsZWFmIHNlc3Npb24taWQgewo+ICAgICAgICBkZXNjcmlwdGlvbgo+ICAgICAgICAgICJT ZXNzaW9uIElEIG9mIHNlc3Npb24gaG9sZGluZyB0aGUKPiAgICAgICAgICAgcmVxdWVzdGVkIGxv Y2ssIG9yIHplcm8gdG8gaW5kaWNhdGUgYSBub24tTkVUQ09ORgo+ICAgICAgICAgICBlbnRpdHkg aG9sZHMgdGhlIGxvY2suIjsKPiAgICAgICAgIHR5cGUgU2Vzc2lvbklkT3JaZXJvOwo+ICAgICAg ICAgY29uZmlnIGZhbHNlOwo+ICAgICAgIH0KPiAgICB9Cj4KPiAgICBncm91cGluZyBScGNFcnJv clR5cGUgewo+ICAgICAgIGRlc2NyaXB0aW9uICJORVRDT05GICdycGMtZXJyb3InIEVsZW1lbnQg Q29udGVudCI7Cj4KPiAgICAgICBsZWFmIGVycm9yLXR5cGUgewo+ICAgICAgICAgZGVzY3JpcHRp b24KPiAgICAgICAgICAgIkRlZmluZXMgdGhlIGNvbmNlcHR1YWwgbGF5ZXIgdGhhdCB0aGUgZXJy b3Igb2NjdXJyZWQuIjsKPiAgICAgICAgIHR5cGUgRXJyb3JUeXBlOwo+ICAgICAgICAgbWFuZGF0 b3J5IHRydWU7Cj4gICAgICAgfQo+Cj4gICAgICAgbGVhZiBlcnJvci10YWcgewo+ICAgICAgICAg ZGVzY3JpcHRpb24KPiAgICAgICAgICAgIkNvbnRhaW5zIGEgc3RyaW5nIGlkZW50aWZ5aW5nIHRo ZSBlcnJvciBjb25kaXRpb24uIjsKPiAgICAgICAgIHR5cGUgRXJyb3JUYWc7Cj4gICAgICAgICBt YW5kYXRvcnkgdHJ1ZTsKPiAgICAgICB9Cj4KPiAgICAgICBsZWFmIGVycm9yLXNldmVyaXR5IHsK PiAgICAgICAgIGRlc2NyaXB0aW9uCj4gICAgICAgICAgICJDb250YWlucyBhIHN0cmluZyBpZGVu dGlmeWluZyB0aGUgZXJyb3Igc2V2ZXJpdHksIGFzCj4gICAgICAgICAgICBkZXRlcm1pbmVkIGJ5 IHRoZSBkZXZpY2UuIjsKPiAgICAgICAgIHR5cGUgRXJyb3JTZXZlcml0eTsKPiAgICAgICAgIG1h bmRhdG9yeSB0cnVlOwo+ICAgICAgIH0KPgo+ICAgICAgIGxlYWYgZXJyb3ItYXBwLXRhZyB7Cj4g ICAgICAgICBkZXNjcmlwdGlvbgo+ICAgICAgICAgICAiQ29udGFpbnMgYSBzdHJpbmcgaWRlbnRp ZnlpbmcgdGhlIGRhdGEtbW9kZWwtc3BlY2lmaWMKPiAgICAgICAgICAgIG9yIGltcGxlbWVudGF0 aW9uLXNwZWNpZmljIGVycm9yIGNvbmRpdGlvbiwgaWYgb25lIGV4aXN0cy4KPiAgICAgICAgICAg IFRoaXMgZWxlbWVudCB3aWxsIG5vdCBiZSBwcmVzZW50IGlmIG5vIGFwcHJvcHJpYXRlCj4gICAg ICAgICAgICBhcHBsaWNhdGlvbiBlcnJvciB0YWcgY2FuIGJlIGFzc29jaWF0ZWQgd2l0aCBhIHBh cnRpY3VsYXIKPiAgICAgICAgICAgIGVycm9yIGNvbmRpdGlvbi4iOwo+ICAgICAgICAgdHlwZSBz dHJpbmc7Cj4gICAgICAgfQo+Cj4gICAgICBsZWFmIGVycm9yLXBhdGggewo+ICAgICAgICBkZXNj cmlwdGlvbgo+ICAgICAgICAgICJDb250YWlucyB0aGUgYWJzb2x1dGUgWFBhdGggWzJdIGV4cHJl c3Npb24gaWRlbnRpZnlpbmcKPiAgICAgICAgICAgdGhlIGVsZW1lbnQgcGF0aCB0byB0aGUgbm9k ZSB0aGF0IGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgZXJyb3IKPiAgICAgICAgICAgYmVpbmcgcmVw b3J0ZWQgaW4gYSBwYXJ0aWN1bGFyIHJwYy1lcnJvciBlbGVtZW50LiAgVGhpcyBlbGVtZW50Cj4g ICAgICAgICAgd2lsbCBub3QgYmUgcHJlc2VudCBpZiBubyBhcHByb3ByaWF0ZSBwYXlsb2FkIGVs ZW1lbnQgY2FuIGJlCj4gICAgICAgICAgYXNzb2NpYXRlZCB3aXRoIGEgcGFydGljdWxhciBlcnJv ciBjb25kaXRpb24sIG9yIGlmIHRoZQo+ICAgICAgICAgICdiYWQtZWxlbWVudCcgUVN0cmluZyBy ZXR1cm5lZCBpbiB0aGUgJ2Vycm9yLWluZm8nIGNvbnRhaW5lciBpcwo+ICAgICAgICAgIHN1ZmZp Y2llbnQgdG8gaWRlbnRpZnkgdGhlIG5vZGUgYXNzb2NpYXRlZCB3aXRoIHRoZSBlcnJvci4gIFdo ZW4KPiAgICAgICAgICB0aGUgWFBhdGggZXhwcmVzc2lvbiBpcyBpbnRlcnByZXRlZCwgdGhlIHNl dCBvZiBuYW1lc3BhY2UKPiAgICAgICAgICBkZWNsYXJhdGlvbnMgYXJlIHRob3NlIGluIHNjb3Bl IG9uIHRoZSBycGMtZXJyb3IgZWxlbWVudCwKPiAgICAgICAgICBpbmNsdWRpbmcgdGhlIGRlZmF1 bHQgbmFtZXNwYWNlLiI7Cj4gICAgICAgIHR5cGUgc3RyaW5nOwo+ICAgICAgfQo+Cj4gICAgICBs ZWFmIGVycm9yLW1lc3NhZ2Ugewo+ICAgICAgICBkZXNjcmlwdGlvbgo+ICAgICAgICAgICJDb250 YWlucyBhIHN0cmluZyBzdWl0YWJsZSBmb3IgaHVtYW4gZGlzcGxheSB0aGF0Cj4gICAgICAgICAg IGRlc2NyaWJlcyB0aGUgZXJyb3IgY29uZGl0aW9uLiAgVGhpcyBlbGVtZW50IHdpbGwgbm90IGJl IHByZXNlbnQKPiAgICAgICAgICAgaWYgbm8gYXBwcm9wcmlhdGUgbWVzc2FnZSBpcyBwcm92aWRl ZCBmb3IgYSBwYXJ0aWN1bGFyIGVycm9yCj4gICAgICAgICAgIGNvbmRpdGlvbi4gIFRoaXMgZWxl bWVudCBTSE9VTEQgaW5jbHVkZSBhbiB4bWw6bGFuZyBhdHRyaWJ1dGUuIjsKPiAgICAgICAgIHR5 cGUgTGFuZ1N0cmluZzsKPiAgICAgICB9Cj4KPiAgICAgICBhbnl4bWwgZXJyb3ItaW5mbyB7Cj4g ICAgICAgICBkZXNjcmlwdGlvbgo+ICAgICAgICAgICAiQ29udGFpbnMgcHJvdG9jb2wtIG9yIGRh dGEtbW9kZWwtc3BlY2lmaWMgZXJyb3IgY29udGVudC4KPiAgICAgICAgICAgIFRoaXMgZWxlbWVu dCB3aWxsIG5vdCBiZSBwcmVzZW50IGlmIG5vIHN1Y2ggZXJyb3IgY29udGVudCBpcwo+ICAgICAg ICAgICAgcHJvdmlkZWQgZm9yIGEgcGFydGljdWxhciBlcnJvciBjb25kaXRpb24uICBUaGUgbGlz dCBpbgo+ICAgICAgICAgICAgUkZDIDQ3NDEsIEFwcGVuZGl4IEEsIGRlZmluZXMgYW55IG1hbmRh dG9yeSBlcnJvci1pbmZvIGNvbnRlbnQKPiAgICAgICAgICAgIGZvciBlYWNoIGVycm9yLiAgQWZ0 ZXIgYW55IHByb3RvY29sLW1hbmRhdGVkIGNvbnRlbnQsIGEKPiAgICAgICAgICAgIGRhdGEgbW9k ZWwgZGVmaW5pdGlvbiBtYXkgbWFuZGF0ZSB0aGF0IGNlcnRhaW4gYXBwbGljYXRpb24tbGF5ZXIK PiAgICAgICAgICAgIGVycm9yIGluZm9ybWF0aW9uIGJlIGluY2x1ZGVkIGluIHRoZSBlcnJvci1p bmZvIGNvbnRhaW5lci4KPiAgICAgICAgICAgIEFuIGltcGxlbWVudGF0aW9uIG1heSBpbmNsdWRl IGFkZGl0aW9uYWwgZWxlbWVudHMgdG8KPiAgICAgICAgICAgIHByb3ZpZGUgZXh0ZW5kZWQgYW5k L29yIGltcGxlbWVudGF0aW9uLXNwZWNpZmljIGRlYnVnZ2luZwo+ICAgICAgICAgICAgaW5mb3Jt YXRpb24uIjsKPiAgICAgICB9Cj4gICAgfQo+Cj4gICAgZ3JvdXBpbmcgUnBjRGF0YVJlcGx5VHlw ZSB7Cj4gICAgICAgZGVzY3JpcHRpb24gIk5FVENPTkYgJ3JwYy1yZXBseScgRXJyb3IgYW5kL29y IERhdGEgQ29udGVudCI7Cj4KPiAgICAgICBsaXN0IHJwYy1lcnJvciB7Cj4gICAgICAgICBjb25m aWcgZmFsc2U7Cj4gICAgICAgICB1c2VzIFJwY0Vycm9yVHlwZTsKPiAgICAgICB9Cj4gICAgICAg YW55eG1sIGRhdGEgewo+ICAgICAgICAgY29uZmlnIGZhbHNlOwo+ICAgICAgIH0KPiAgICB9Cj4K PiAgICBncm91cGluZyBScGNPa1JlcGx5VHlwZSB7Cj4gICAgICAgZGVzY3JpcHRpb24gIk5FVENP TkYgJ3JwYy1yZXBseScgT0sgQ29udGVudC4iOwo+Cj4gICAgICAgY2hvaWNlIG9rLW9yLWVycm9y IHsKPiAgICAgICAgIGxlYWYgb2sgewo+ICAgICAgICAgICBkZXNjcmlwdGlvbgo+ICAgICAgICAg ICAgICJTZW50IGluICdycGMtcmVwbHknIG1lc3NhZ2VzIGlmIG5vIGVycm9ycyBvcgo+ICAgICAg ICAgICAgICB3YXJuaW5ncyBvY2N1cnJlZCBkdXJpbmcgdGhlIHByb2Nlc3Npbmcgb2YgYW4gJ3Jw YycgcmVxdWVzdC4iOwo+ICAgICAgICAgICB0eXBlIGVtcHR5Owo+ICAgICAgICAgICBjb25maWcg ZmFsc2U7Cj4gICAgICAgICB9Cj4KPiAgICAgICAgIGxpc3QgcnBjLWVycm9yIHsKPiAgICAgICAg ICAgY29uZmlnIGZhbHNlOwo+ICAgICAgICAgICB1c2VzIFJwY0Vycm9yVHlwZTsKPiAgICAgICAg IH0KPiAgICAgICB9Cj4gICAgfQo+Cj4gICAgZ3JvdXBpbmcgUnBjUmVwbHlUeXBlIHsKPiAgICAg ICBkZXNjcmlwdGlvbiAiR2VuZXJpYyBORVRDT05GICdycGMtcmVwbHknIGNvbnRlbnQuICI7Cj4K PiAgICAgICBjaG9pY2Ugb2stb3ItZGF0YS1lcnJvciB7Cj4gICAgICAgICBtYW5kYXRvcnkgdHJ1 ZTsKPiAgICAgICAgIGNvbmZpZyBmYWxzZTsKPgo+ICAgICAgICAgbGVhZiBvayB7Cj4gICAgICAg ICAgIGRlc2NyaXB0aW9uCj4gICAgICAgICAgICAgIlNlbnQgaW4gJ3JwYy1yZXBseScgbWVzc2Fn ZXMgaWYgbm8gZXJyb3JzIG9yCj4gICAgICAgICAgICAgIHdhcm5pbmdzIG9jY3VycmVkIGR1cmlu ZyB0aGUgcHJvY2Vzc2luZyBvZiBhbiAncnBjJyByZXF1ZXN0LiI7Cj4gICAgICAgICAgIHR5cGUg ZW1wdHk7Cj4gICAgICAgICB9Cj4KPiAgICAgICAgIGNhc2UgZGF0YS1lcnJvciB7Cj4gICAgICAg ICAgICB1c2VzIFJwY0RhdGFSZXBseVR5cGU7Cj4gICAgICAgICB9Cj4gICAgICAgfQo+ICAgIH0K Pgo+ICAgIGdyb3VwaW5nIENvbW1vbkNvbmZpZ1NvdXJjZVR5cGUgewo+ICAgICAgIGRlc2NyaXB0 aW9uICJDb21tb24gTkVUQ09ORiBjb25maWcgcGFyYW1ldGVyIGNvbnRlbnRzLiI7Cj4KPiAgICAg ICBjaG9pY2UgY29uZmlnLXNvdXJjZSB7Cj4gICAgICAgICBtYW5kYXRvcnkgdHJ1ZTsKPgo+ICAg ICAgICAgbGVhZiBjYW5kaWRhdGUgewo+ICAgICAgICAgICBkZXNjcmlwdGlvbgo+ICAgICAgICAg ICAgICJPbmx5IGF2YWlsYWJsZSBpZiAnY2FuZGlkYXRlJyBjYXBhYmlsaXR5IHN1cHBvcnRlZC4i Owo+ICAgICAgICAgICB0eXBlIGVtcHR5Owo+ICAgICAgICAgfQo+ICAgICAgICAgbGVhZiBydW5u aW5nIHsKPiAgICAgICAgICAgdHlwZSBlbXB0eTsKPiAgICAgICAgIH0KPiAgICAgICAgIGxlYWYg c3RhcnR1cCB7Cj4gICAgICAgICAgIGRlc2NyaXB0aW9uCj4gICAgICAgICAgICAgIk9ubHkgYXZh aWxhYmxlIGlmICdzdGFydHVwJyBjYXBhYmlsaXR5IHN1cHBvcnRlZC4iOwo+ICAgICAgICAgICB0 eXBlIGVtcHR5Owo+ICAgICAgICAgfQo+ICAgICAgIH0KPiAgICB9Cj4KPiAgICBncm91cGluZyBH ZXRDb25maWdTb3VyY2VUeXBlIHsKPiAgICAgICBkZXNjcmlwdGlvbiAiTkVUQ09ORiBjb25maWcg J3NvdXJjZScgUGFyYW1ldGVyIGNvbnRlbnRzLiI7Cj4KPiAgICAgICB1c2VzIENvbW1vbkNvbmZp Z1NvdXJjZVR5cGU7Cj4KPiAgICAgICBhdWdtZW50IGNvbmZpZy1zb3VyY2Ugewo+ICAgICAgICAg bGVhZiB1cmwgewo+ICAgICAgICAgICBkZXNjcmlwdGlvbgo+ICAgICAgICAgICAgICJVUkwgcG9p bnRpbmcgdG8gY29uZmlnIGRhdGEuIE9ubHkgYXZhaWxhYmxlCj4gICAgICAgICAgICAgIGlmICd1 cmwnIGNhcGFiaWxpdHkgc3VwcG9ydGVkLiI7Cj4gICAgICAgICAgIHR5cGUgQ29uZmlnVVJJVHlw ZTsKPiAgICAgICAgIH0KPiAgICAgICB9Cj4gICAgfQo+Cj4gICAgZ3JvdXBpbmcgUnBjT3BlcmF0 aW9uU291cmNlVHlwZSB7Cj4gICAgICAgZGVzY3JpcHRpb24gIk5FVENPTkYgJ3NvdXJjZScgUGFy YW1ldGVyIGNvbnRlbnRzLiI7Cj4KPiAgICAgICB1c2VzIENvbW1vbkNvbmZpZ1NvdXJjZVR5cGU7 Cj4gICAgICAgYXVnbWVudCBjb25maWctc291cmNlIHsKPiAgICAgICAgIGxlYWYgdXJsIHsKPiAg ICAgICAgICAgZGVzY3JpcHRpb24KPiAgICAgICAgICAgICAiVVJMIHBvaW50aW5nIHRvIGNvbmZp ZyBkYXRhLiBPbmx5IGF2YWlsYWJsZQo+ICAgICAgICAgICAgICBpZiAndXJsJyBjYXBhYmlsaXR5 IHN1cHBvcnRlZC4iOwo+ICAgICAgICAgICB0eXBlIENvbmZpZ1VSSVR5cGU7Cj4gICAgICAgICB9 Cj4KPiAgICAgICAgIGNvbnRhaW5lciBjb25maWcgewo+ICAgICAgICAgICBkZXNjcmlwdGlvbiAi SW5saW5lIGNvbmZpZ3VyYXRpb24gZGF0YSI7Cj4gICBuY3g6cm9vdDsKPiAgICAgICAgIH0KPiAg ICAgICB9Cj4gICAgfQo+Cj4gICAgZ3JvdXBpbmcgUnBjT3BlcmF0aW9uVGFyZ2V0VHlwZSB7Cj4g ICAgICAgZGVzY3JpcHRpb24gIk5FVENPTkYgJ3RhcmdldCcgUGFyYW1ldGVyIGNvbnRlbnRzLiI7 Cj4KPiAgICAgICB1c2VzIENvbW1vbkNvbmZpZ1NvdXJjZVR5cGU7Cj4gICAgICAgYXVnbWVudCBj b25maWctc291cmNlIHsKPiAgICAgICAgIGxlYWYgdXJsIHsKPiAgICAgICAgICAgZGVzY3JpcHRp b24KPiAgICAgICAgICAgICAiVVJMIHBvaW50aW5nIHRvIGRlc2lyZWQgY29uZmlnIGRhdGEgb3V0 cHV0LiBPbmx5Cj4gICAgICAgICAgICAgIGF2YWlsYWJsZSBpZiAndXJsJyBjYXBhYmlsaXR5IHN1 cHBvcnRlZC4iOwo+ICAgICAgICAgICB0eXBlIENvbmZpZ1VSSVR5cGU7Cj4gICAgICAgICB9Cj4g ICAgICAgfQo+ICAgIH0KPgo+ICAgIC8vIE5FVENPTkYgb3BlcmF0aW9uIGF0dHJpYnV0ZQo+ICAg IGxlYWYgb3BlcmF0aW9uIHsKPiAgICAgIGRlc2NyaXB0aW9uCj4gICAgICAgICJJbnRlcm5hbCBv YmplY3QgZm9yIHRoZSBuYzpvcGVyYXRpb24gYXR0cmlidXRlLiI7Cj4gICAgICB0eXBlIEVkaXRP cGVyYXRpb25UeXBlOwo+ICAgICAgbmN4OmFic3RyYWN0Owo+ICAgICAgbmN4OmhpZGRlbjsKPiAg ICB9Cj4KPiAgICAvLyBORVRDT05GIEdlbmVyaWMgUlBDIE1lc3NhZ2VzCj4KPiAgICBjb250YWlu ZXIgcnBjIHsKPiAgICAgIGRlc2NyaXB0aW9uICJSZW1vdGUgUHJvY2VkdXJlIENhbGwgcmVxdWVz dCBtZXNzYWdlIjsKPgo+ICAgICAgcmVmZXJlbmNlICJSRkMgNDc0MSwgc2VjdGlvbiA0LjEiOwo+ Cj4gICAgICAvLyBkbyBub3QgdHJlYXQgbWlzc2luZyBtZXNzYWdlLWlkIGFzIGFuIGVycm9yCj4g ICAgICBuY3g6bWV0YWRhdGEgICJNZXNzYWdlSWQgbWVzc2FnZS1pZCI7Cj4gICAgICBuY3g6YWJz dHJhY3Q7Cj4gICAgfQo+Cj4gICAgY29udGFpbmVyIHJwYy1yZXBseSB7Cj4gICAgICBkZXNjcmlw dGlvbiAiUmVtb3RlIFByb2NlZHVyZSBDYWxsIHJlc3BvbnNlIG1lc3NhZ2UiOwo+Cj4gICAgICBy ZWZlcmVuY2UgIlJGQyA0NzQxLCBzZWN0aW9uIDQuMiI7Cj4KPiAgICAgIHVzZXMgUnBjUmVwbHlU eXBlOwo+Cj4gICAgICAvLyBkbyBub3QgdHJlYXQgbWlzc2luZyBtZXNzYWdlLWlkIGFzIGFuIGVy cm9yCj4gICAgICBuY3g6bWV0YWRhdGEgICJNZXNzYWdlSWQgbWVzc2FnZS1pZCI7Cj4gICAgICBu Y3g6YWJzdHJhY3Q7Cj4gICAgfQo+Cj4gICAgLy8gTkVUQ09ORiBTdGFuZGFyZCBSUEMgTWV0aG9k cwo+Cj4gICAgcnBjIGdldC1jb25maWcgewo+ICAgICAgIGRlc2NyaXB0aW9uCj4gICAgICAgICAi UmV0cmlldmUgYWxsIG9yIHBhcnQgb2YgYSBzcGVjaWZpZWQgY29uZmlndXJhdGlvbi4iOwo+Cj4g ICAgICAgcmVmZXJlbmNlICJSRkMgNDc0MSwgc2VjdGlvbiA3LjIiOwo+Cj4gICAgICAgbmN4OnJw Yy10eXBlICJtb25pdG9yIjsKPgo+ICAgICAgIGlucHV0IHsKPiAgICAgICAgIGNvbnRhaW5lciBz b3VyY2Ugewo+ICAgICAgICAgICBkZXNjcmlwdGlvbiAiUGFydGljdWxhciBjb25maWd1cmF0aW9u IHRvIHJldHJpZXZlLiI7Cj4gICAgICAgICAgIHVzZXMgR2V0Q29uZmlnU291cmNlVHlwZTsKPiAg ICAgICAgIH0KPgo+ICAgICAgICAgYW55eG1sIGZpbHRlciB7Cj4gICAgICAgICAgIGRlc2NyaXB0 aW9uICJTdWJ0cmVlIG9yIFhwYXRoIGZpbHRlciB0byB1c2UuIjsKPiAgICAgICAgICAgbmN4Om1l dGFkYXRhICJGaWx0ZXJUeXBlIHR5cGUiOwo+ICAgICAgICAgICBuY3g6bWV0YWRhdGEgInN0cmlu ZyBzZWxlY3QiOwo+ICAgICAgICAgfQo+ICAgICAgIH0KPgo+ICAgICAgIG91dHB1dCB7Cj4gICAg ICAgICBhbnl4bWwgZGF0YSB7Cj4gICAgICAgICAgIGRlc2NyaXB0aW9uCj4gICAgICAgICAgICAg IkNvcHkgb2YgdGhlIHNvdXJjZSBkYXRhYmFzZSBzdWJzZXQgd2hpY2ggbWF0Y2hlZAo+ICAgICAg ICAgICAgICB0aGUgZmlsdGVyIGNyaXRlcmlhIChpZiBhbnkpLiI7Cj4gICAgICAgIH0KPiAgICAg IH0KPiAgICB9Cj4KPiAgICBycGMgZWRpdC1jb25maWcgewo+ICAgICAgIGRlc2NyaXB0aW9uCj4g ICAgICAgICAiVGhlICdlZGl0LWNvbmZpZycgb3BlcmF0aW9uIGxvYWRzIGFsbCBvciBwYXJ0IG9m IGEgc3BlY2lmaWVkCj4gICAgICAgICAgY29uZmlndXJhdGlvbiB0byB0aGUgc3BlY2lmaWVkIHRh cmdldCBjb25maWd1cmF0aW9uLiAgVGhpcwo+ICAgICAgICAgIG9wZXJhdGlvbiBhbGxvd3MgdGhl IG5ldyBjb25maWd1cmF0aW9uIHRvIGJlIGV4cHJlc3NlZCBpbiBzZXZlcmFsCj4gICAgICAgICAg d2F5cywgc3VjaCBhcyB1c2luZyBhIGxvY2FsIGZpbGUsIGEgcmVtb3RlIGZpbGUsIG9yIGlubGlu ZS4gIElmCj4gICAgICAgICAgdGhlIHRhcmdldCBjb25maWd1cmF0aW9uIGRvZXMgbm90IGV4aXN0 LCBpdCB3aWxsIGJlIGNyZWF0ZWQuICBJZiBhCj4gICAgICAgICAgTkVUQ09ORiBwZWVyIHN1cHBv cnRzIHRoZSA6dXJsIGNhcGFiaWxpdHkgKFNlY3Rpb24gOC44KSwgdGhlIDx1cmw+Cj4gICAgICAg ICAgZWxlbWVudCBjYW4gYXBwZWFyIGluc3RlYWQgb2YgdGhlIDxjb25maWc+IHBhcmFtZXRlciBh bmQgc2hvdWxkCj4gICAgICAgICAgaWRlbnRpZnkgYSBsb2NhbCBjb25maWd1cmF0aW9uIGZpbGUu Cj4KPiAgICAgICAgICBUaGUgZGV2aWNlIGFuYWx5emVzIHRoZSBzb3VyY2UgYW5kIHRhcmdldCBj b25maWd1cmF0aW9ucyBhbmQKPiAgICAgICAgICBwZXJmb3JtcyB0aGUgcmVxdWVzdGVkIGNoYW5n ZXMuICBUaGUgdGFyZ2V0IGNvbmZpZ3VyYXRpb24gaXMgbm90Cj4gICAgICAgICAgbmVjZXNzYXJp bHkgcmVwbGFjZWQsIGFzIHdpdGggdGhlIDxjb3B5LWNvbmZpZz4gbWVzc2FnZS4gIEluc3RlYWQs Cj4gICAgICAgICAgdGhlIHRhcmdldCBjb25maWd1cmF0aW9uIGlzIGNoYW5nZWQgaW4gYWNjb3Jk YW5jZSB3aXRoIHRoZQo+ICAgICAgICAgIHNvdXJjZSdzIGRhdGEgYW5kIHJlcXVlc3RlZCBvcGVy YXRpb25zLiI7Cj4KPiAgICAgICByZWZlcmVuY2UgIlJGQyA0NzQxLCBzZWN0aW9uIDcuMiI7Cj4K PiAgICAgICBuY3g6cnBjLXR5cGUgImNvbmZpZyI7Cj4KPiAgICAgICBpbnB1dCB7Cj4gICAgICAg ICBjb250YWluZXIgdGFyZ2V0IHsKPiAgICAgICAgICAgZGVzY3JpcHRpb24gIlBhcnRpY3VsYXIg Y29uZmlndXJhdGlvbiB0byBlZGl0LiI7Cj4gICAgICAgICAgIC8vIG1hbmRhdG9yeSB0cnVlOwo+ ICAgICAgICAgICB1c2VzIFJwY09wZXJhdGlvblRhcmdldFR5cGU7Cj4gICAgICAgICB9Cj4KPiAg ICAgICAgIGxlYWYgZGVmYXVsdC1vcGVyYXRpb24gewo+ICAgICAgICAgICBkZXNjcmlwdGlvbgo+ ICAgICAgICAgICAgICJEZWZhdWx0IG9wZXJhdGlvbiB0byBhcHBseSBpZiBub3QgZXhwbGljaXRs eSBzZXQuIjsKPiAgICAgICAgICAgdHlwZSBEZWZhdWx0T3BlcmF0aW9uVHlwZTsKPiAgICAgICAg IH0KPgo+ICAgICAgICAgbGVhZiB0ZXN0LW9wdGlvbiB7Cj4gICAgICAgICAgIGRlc2NyaXB0aW9u Cj4gICAgICAgICAgICAgIlRlc3Qgb3B0aW9uIGlmIHZhbGlkYXRlIGNhcGFiaWxpdHkgc3VwcG9y dGVkLgo+ICAgICAgICAgICAgICBUaGUgJ3ZhbGlkYXRlJyBjYXBhYmlsaXR5IG11c3QgYmUgcHJl c2VudCB0byBzZXQKPiAgICAgICAgICAgICAgdGhpcyBvYmplY3QgdG8gJ3Rlc3QtdGhlbi1zZXQn LiI7Cj4gICAgICAgICAgIHR5cGUgVGVzdE9wdGlvblR5cGU7Cj4gICAgICAgICB9Cj4KPiAgICAg ICAgIGxlYWYgZXJyb3Itb3B0aW9uIHsKPiAgICAgICAgICAgZGVzY3JpcHRpb24gIkVycm9yIHJl Y292ZXJ5IG9wdGlvbi4iOwo+ICAgICAgICAgICB0eXBlIEVycm9yT3B0aW9uVHlwZTsKPiAgICAg ICAgIH0KPgo+ICAgICAgICAgY2hvaWNlIGVkaXQtY29udGVudCB7Cj4gICAgICAgICAgIG1hbmRh dG9yeSB0cnVlOwo+ICAgICAgICAgICBjb250YWluZXIgY29uZmlnIHsKPiAgICAgICAgICAgICBk ZXNjcmlwdGlvbgo+ICAgICAgICAgICAgICAgIklubGluZSBDb25maWcgY29udGVudDogJ2NvbmZp ZycgZWxlbWVudC4iOwo+ICAgICAgICAgICAgIG5jeDpyb290Owo+ICAgICAgICAgICB9Cj4gICAg ICAgICAgIGxlYWYgdXJsIHsKPiAgICAgICAgICAgICBkZXNjcmlwdGlvbgo+ICAgICAgICAgICAg ICAgIlBvaW50ZXIgdG8gQ29uZmlnIGNvbnRlbnQ6ICd1cmwnIGVsZW1lbnQuIjsKPiAgICAgICAg ICAgICB0eXBlIENvbmZpZ1VSSVR5cGU7Cj4gICAgICAgICAgIH0KPiAgICAgICAgIH0KPiAgICAg ICB9Cj4gICAgfQo+Cj4gICAgcnBjIGNvcHktY29uZmlnIHsKPiAgICAgICBkZXNjcmlwdGlvbgo+ ICAgICAgICAgIkNyZWF0ZSBvciByZXBsYWNlIGFuIGVudGlyZSBjb25maWd1cmF0aW9uIGRhdGFz dG9yZSB3aXRoIHRoZQo+ICAgICAgICAgIGNvbnRlbnRzIG9mIGFub3RoZXIgY29tcGxldGUgY29u ZmlndXJhdGlvbiBkYXRhc3RvcmUuICBJZiB0aGUKPiAgICAgICAgICB0YXJnZXQgZGF0YXN0b3Jl IGV4aXN0cywgaXQgaXMgb3ZlcndyaXR0ZW4uICBPdGhlcndpc2UsIGEgbmV3IG9uZQo+ICAgICAg ICAgIGlzIGNyZWF0ZWQsIGlmIGFsbG93ZWQuCj4KPiAgICAgICAgICBJZiBhIE5FVENPTkYgcGVl ciBzdXBwb3J0cyB0aGUgOnVybCBjYXBhYmlsaXR5IChTZWN0aW9uIDguOCksIHRoZQo+ICAgICAg ICAgICd1cmwnIGVsZW1lbnQgY2FuIGFwcGVhciBhcyB0aGUgPHNvdXJjZT4gb3IgPHRhcmdldD4g cGFyYW1ldGVyLgo+Cj4gICAgICAgICAgRXZlbiBpZiBpdCBhZHZlcnRpc2VzIHRoZSA6d3JpdGFi bGUtcnVubmluZyBjYXBhYmlsaXR5LCBhIGRldmljZQo+ICAgICAgICAgIG1heSBjaG9vc2Ugbm90 IHRvIHN1cHBvcnQgdGhlIDxydW5uaW5nLz4gY29uZmlndXJhdGlvbiBkYXRhc3RvcmUKPiAgICAg ICAgICBhcyB0aGUgPHRhcmdldD4gcGFyYW1ldGVyIG9mIGEgPGNvcHktY29uZmlnPiBvcGVyYXRp b24uICBBIGRldmljZQo+ICAgICAgICAgIG1heSBjaG9vc2Ugbm90IHRvIHN1cHBvcnQgcmVtb3Rl LXRvLXJlbW90ZSBjb3B5IG9wZXJhdGlvbnMsIHdoZXJlCj4gICAgICAgICAgYm90aCB0aGUgPHNv dXJjZT4gYW5kIDx0YXJnZXQ+IHBhcmFtZXRlcnMgdXNlIHRoZSA8dXJsPiBlbGVtZW50Lgo+Cj4g ICAgICAgICBJZiB0aGUgc291cmNlIGFuZCB0YXJnZXQgcGFyYW1ldGVycyBpZGVudGlmeSB0aGUg c2FtZSBVUkwgb3IKPiAgICAgICAgIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlLCBhbiBlcnJvciBN VVNUIGJlIHJldHVybmVkIHdpdGggYW4gZXJyb3ItCj4gICAgICAgICB0YWcgY29udGFpbmluZyBp bnZhbGlkLXZhbHVlLiI7Cj4KPiAgICAgICByZWZlcmVuY2UgIlJGQyA0NzQxLCBzZWN0aW9uIDcu MyI7Cj4KPiAgICAgICBuY3g6cnBjLXR5cGUgImNvbmZpZyI7Cj4KPiAgICAgICBpbnB1dCB7Cj4g ICAgICAgICBjb250YWluZXIgdGFyZ2V0IHsKPiAgICAgICAgICAgZGVzY3JpcHRpb24gIlBhcnRp Y3VsYXIgY29uZmlndXJhdGlvbiB0byBjb3B5IHRvLiI7Cj4gICAgICAgICAgIC8vIG1hbmRhdG9y eSB0cnVlOwo+ICAgICAgICAgICB1c2VzIFJwY09wZXJhdGlvblRhcmdldFR5cGU7Cj4gICAgICAg ICB9Cj4KPiAgICAgICAgIGNvbnRhaW5lciBzb3VyY2Ugewo+ICAgICAgICAgICBkZXNjcmlwdGlv biAiUGFydGljdWxhciBjb25maWd1cmF0aW9uIHRvIGNvcHkgZnJvbS4iOwo+ICAgICAgICAgICAv LyBtYW5kYXRvcnkgdHJ1ZTsKPiAgICAgICAgICAgdXNlcyBScGNPcGVyYXRpb25Tb3VyY2VUeXBl Owo+ICAgICAgICAgfQo+ICAgICAgIH0KPiAgICB9Cj4KPiAgICBycGMgZGVsZXRlLWNvbmZpZyB7 Cj4gICAgICAgZGVzY3JpcHRpb24KPiAgICAgICAgICJEZWxldGUgYSBjb25maWd1cmF0aW9uIGRh dGFzdG9yZS4gIFRoZSAncnVubmluZycgY29uZmlndXJhdGlvbgo+ICAgICAgICAgIGRhdGFzdG9y ZSBjYW5ub3QgYmUgZGVsZXRlZC4KPgo+ICAgICAgICAgIElmIGEgTkVUQ09ORiBwZWVyIHN1cHBv cnRzIHRoZSA6dXJsIGNhcGFiaWxpdHkgKFNlY3Rpb24gOC44KSwgdGhlCj4gICAgICAgICAgJ3Vy bCcgZWxlbWVudCBjYW4gYXBwZWFyIGFzIHRoZSA8dGFyZ2V0PiBwYXJhbWV0ZXIuIjsKPgo+ICAg ICAgIHJlZmVyZW5jZSAiUkZDIDQ3NDEsIHNlY3Rpb24gNy40IjsKPgo+ICAgICAgIG5jeDpycGMt dHlwZSAiY29uZmlnIjsKPgo+ICAgICAgIGlucHV0IHsKPiAgICAgICAgIGNvbnRhaW5lciB0YXJn ZXQgewo+ICAgICAgICAgICBkZXNjcmlwdGlvbiAiUGFydGljdWxhciBjb25maWd1cmF0aW9uIHRv IGRlbGV0ZS4iOwo+ICAgICAgICAgICB1c2VzIFJwY09wZXJhdGlvblRhcmdldFR5cGU7Cj4gICAg ICAgICB9Cj4gICAgICAgfQo+ICAgIH0KPgo+ICAgIHJwYyBsb2NrIHsKPiAgICAgICBkZXNjcmlw dGlvbgo+ICAgICAgICAgIlRoZSBsb2NrIG9wZXJhdGlvbiBhbGxvd3MgdGhlIGNsaWVudCB0byBs b2NrIHRoZSBjb25maWd1cmF0aW9uCj4gICAgICAgICAgc3lzdGVtIG9mIGEgZGV2aWNlLiAgU3Vj aCBsb2NrcyBhcmUgaW50ZW5kZWQgdG8gYmUgc2hvcnQtbGl2ZWQgYW5kCj4gICAgICAgICAgYWxs b3cgYSBjbGllbnQgdG8gbWFrZSBhIGNoYW5nZSB3aXRob3V0IGZlYXIgb2YgaW50ZXJhY3Rpb24g d2l0aAo+ICAgICAgICAgIG90aGVyIE5FVENPTkYgY2xpZW50cywgbm9uLU5FVENPTkYgY2xpZW50 cyAoZS5nLiwgU05NUCBhbmQgY29tbWFuZAo+ICAgICAgICAgIGxpbmUgaW50ZXJmYWNlIChDTEkp IHNjcmlwdHMpLCBhbmQgaHVtYW4gdXNlcnMuIC4uLiI7Cj4KPiAgICAgICByZWZlcmVuY2UgIlJG QyA0NzQxLCBzZWN0aW9uIDcuNSI7Cj4KPiAgICAgICBuY3g6cnBjLXR5cGUgImNvbmZpZyI7Cj4K PiAgICAgICBpbnB1dCB7Cj4gICAgICAgICBjb250YWluZXIgdGFyZ2V0IHsKPiAgICAgICAgICAg ZGVzY3JpcHRpb24gIlBhcnRpY3VsYXIgY29uZmlndXJhdGlvbiB0byBsb2NrIjsKPiAgICAgICAg ICAgLy8gbWFuZGF0b3J5IHRydWU7Cj4gICAgICAgICAgIHVzZXMgUnBjT3BlcmF0aW9uVGFyZ2V0 VHlwZTsKPiAgICAgICAgIH0KPiAgICAgICB9Cj4gICAgfQo+Cj4gICAgcnBjIHVubG9jayB7Cj4g ICAgICAgZGVzY3JpcHRpb24KPiAgICAgICAgICJUaGUgdW5sb2NrIG9wZXJhdGlvbiBpcyB1c2Vk IHRvIHJlbGVhc2UgYSBjb25maWd1cmF0aW9uIGxvY2ssCj4gICAgICAgICAgcHJldmlvdXNseSBv YnRhaW5lZCB3aXRoIHRoZSAnbG9jaycgb3BlcmF0aW9uLgo+Cj4gICAgICAgICAgQW4gdW5sb2Nr IG9wZXJhdGlvbiB3aWxsIG5vdCBzdWNjZWVkIGlmIGFueSBvZiB0aGUgZm9sbG93aW5nCj4gICAg ICAgICAgY29uZGl0aW9ucyBhcmUgdHJ1ZToKPgo+ICAgICAgICAgICogIHRoZSBzcGVjaWZpZWQg bG9jayBpcyBub3QgY3VycmVudGx5IGFjdGl2ZQo+Cj4gICAgICAgICAgKiAgdGhlIHNlc3Npb24g aXNzdWluZyB0aGUgPHVubG9jaz4gb3BlcmF0aW9uIGlzIG5vdCB0aGUgc2FtZQo+ICAgICAgICAg ICAgIHNlc3Npb24gdGhhdCBvYnRhaW5lZCB0aGUgbG9jawo+Cj4gICAgICAgICAgVGhlIHNlcnZl ciBNVVNUIHJlc3BvbmQgd2l0aCBlaXRoZXIgYW4gPG9rPiBlbGVtZW50IG9yIGFuCj4gICAgICAg ICAgJ3JwYy1lcnJvcicuIjsKPgo+ICAgICAgIHJlZmVyZW5jZSAiUkZDIDQ3NDEsIHNlY3Rpb24g Ny42IjsKPgo+ICAgICAgIG5jeDpycGMtdHlwZSAiY29uZmlnIjsKPgo+ICAgICAgIGlucHV0IHsK PiAgICAgICAgIGNvbnRhaW5lciB0YXJnZXQgewo+ICAgICAgICAgICAvLyBtYW5kYXRvcnkgdHJ1 ZTsKPiAgICAgICAgICAgZGVzY3JpcHRpb24gIlBhcnRpY3VsYXIgY29uZmlndXJhdGlvbiB0byB1 bmxvY2suIjsKPiAgICAgICAgICAgdXNlcyBScGNPcGVyYXRpb25UYXJnZXRUeXBlOwo+ICAgICAg ICAgfQo+ICAgICAgIH0KPiAgICB9Cj4KPiAgICBycGMgZ2V0IHsKPiAgICAgICBkZXNjcmlwdGlv bgo+ICAgICAgICAgIlJldHJpZXZlIHJ1bm5pbmcgY29uZmlndXJhdGlvbiBhbmQgZGV2aWNlIHN0 YXRlIGluZm9ybWF0aW9uLiI7Cj4KPiAgICAgICByZWZlcmVuY2UgIlJGQyA0NzQxLCBzZWN0aW9u IDcuNyI7Cj4KPiAgICAgICBuY3g6cnBjLXR5cGUgIm1vbml0b3IiOwo+Cj4gICAgICAgaW5wdXQg ewo+ICAgICAgICAgYW55eG1sIGZpbHRlciB7Cj4gICAgICAgICAgIGRlc2NyaXB0aW9uCj4gICAg ICAgICAgICAgIlRoaXMgcGFyYW1ldGVyIHNwZWNpZmllcyB0aGUgcG9ydGlvbiBvZiB0aGUgc3lz dGVtCj4gICAgICAgICAgICAgIGNvbmZpZ3VyYXRpb24gYW5kIHN0YXRlIGRhdGEgdG8gcmV0cmll dmUuICBJZiB0aGlzIHBhcmFtZXRlciBpcwo+ICAgICAgICAgICAgICBlbXB0eSwgYWxsIHRoZSBk ZXZpY2UgY29uZmlndXJhdGlvbiBhbmQgc3RhdGUgaW5mb3JtYXRpb24gaXMKPiAgICAgICAgICAg ICAgcmV0dXJuZWQuCj4KPiAgICAgICAgICAgICAgVGhlIGZpbHRlciBlbGVtZW50IG1heSBvcHRp b25hbGx5IGNvbnRhaW4gYSAndHlwZScgYXR0cmlidXRlLgo+ICAgICAgICAgICAgICBUaGlzIGF0 dHJpYnV0ZSBpbmRpY2F0ZXMgdGhlIHR5cGUgb2YgZmlsdGVyaW5nIHN5bnRheCB1c2VkCj4gICAg ICAgICAgICAgIHdpdGhpbiB0aGUgZmlsdGVyIGVsZW1lbnQuICBUaGUgZGVmYXVsdCBmaWx0ZXJp bmcgbWVjaGFuaXNtIGluCj4gICAgICAgICAgICAgIE5FVENPTkYgaXMgcmVmZXJyZWQgdG8gYXMg c3VidHJlZSBmaWx0ZXJpbmcgYW5kIGlzIGRlc2NyaWJlZCBpbgo+ICAgICAgICAgICAgICBTZWN0 aW9uIDYuICBUaGUgdmFsdWUgJ3N1YnRyZWUnIGV4cGxpY2l0bHkgaWRlbnRpZmllcyB0aGlzIHR5 cGUKPiAgICAgICAgICAgICAgb2YgZmlsdGVyaW5nLgo+Cj4gICAgICAgICAgICAgIElmIHRoZSBO RVRDT05GIHBlZXIgc3VwcG9ydHMgdGhlIDp4cGF0aCBjYXBhYmlsaXR5Cj4gICAgICAgICAgICAg IChTZWN0aW9uIDguOSksIHRoZSB2YWx1ZSAneHBhdGgnIG1heSBiZSB1c2VkIHRvIGluZGljYXRl IHRoYXQKPiAgICAgICAgICAgICAgdGhlIHNlbGVjdCBhdHRyaWJ1dGUgb2YgdGhlIGZpbHRlciBl bGVtZW50IGNvbnRhaW5zIGFuIFhQYXRoCj4gICAgICAgICAgICAgIGV4cHJlc3Npb24uIjsKPiAg ICAgICAgICAgbmN4Om1ldGFkYXRhICJGaWx0ZXJUeXBlIHR5cGUiOwo+ICAgICAgICAgICBuY3g6 bWV0YWRhdGEgInN0cmluZyBzZWxlY3QiOwo+ICAgICAgICAgfQo+ICAgICAgIH0KPgo+ICAgICAg IG91dHB1dCB7Cj4gICAgICAgICBhbnl4bWwgZGF0YSB7Cj4gICAgICAgICAgIGRlc2NyaXB0aW9u Cj4gICAgICAgICAgICAgIkNvcHkgb2YgdGhlICdydW5uaW5nJyBkYXRhYmFzZSBzdWJzZXQgd2hp Y2ggbWF0Y2hlZAo+ICAgICAgICAgICAgICB0aGUgZmlsdGVyIGNyaXRlcmlhIChpZiBhbnkpLiI7 Cj4gICAgICAgICB9Cj4gICAgICAgfQo+ICAgIH0KPgo+ICAgIHJwYyBjbG9zZS1zZXNzaW9uIHsK PiAgICAgICBkZXNjcmlwdGlvbgo+ICAgICAgICAgIlJlcXVlc3QgZ3JhY2VmdWwgdGVybWluYXRp b24gb2YgYSBORVRDT05GIHNlc3Npb24uCj4KPiAgICAgICAgICBXaGVuIGEgTkVUQ09ORiBzZXJ2 ZXIgcmVjZWl2ZXMgYSA8Y2xvc2Utc2Vzc2lvbj4gcmVxdWVzdCwgaXQgd2lsbAo+ICAgICAgICAg IGdyYWNlZnVsbHkgY2xvc2UgdGhlIHNlc3Npb24uICBUaGUgc2VydmVyIHdpbGwgcmVsZWFzZSBh bnkgbG9ja3MKPiAgICAgICAgICBhbmQgcmVzb3VyY2VzIGFzc29jaWF0ZWQgd2l0aCB0aGUgc2Vz c2lvbiBhbmQgZ3JhY2VmdWxseSBjbG9zZSBhbnkKPiAgICAgICAgICBhc3NvY2lhdGVkIGNvbm5l Y3Rpb25zLiAgQW55IE5FVENPTkYgcmVxdWVzdHMgcmVjZWl2ZWQgYWZ0ZXIgYQo+ICAgICAgICAg ICdjbG9zZS1zZXNzaW9uJyByZXF1ZXN0IHdpbGwgYmUgaWdub3JlZC4iOwo+Cj4gICAgICAgcmVm ZXJlbmNlICJSRkMgNDc0MSwgc2VjdGlvbiA3LjgiOwo+Cj4gICAgICAgbmN4OnJwYy10eXBlICJv dGhlciI7Cj4gICAgfQo+Cj4gICAgcnBjIGtpbGwtc2Vzc2lvbiB7Cj4gICAgICAgZGVzY3JpcHRp b24KPiAgICAgICAgICJGb3JjZSB0aGUgdGVybWluYXRpb24gb2YgYSBORVRDT05GIHNlc3Npb24u Cj4KPiAgICAgICAgICBXaGVuIGEgTkVUQ09ORiBlbnRpdHkgcmVjZWl2ZXMgYSA8a2lsbC1zZXNz aW9uPiByZXF1ZXN0IGZvciBhbgo+ICAgICAgICAgIG9wZW4gc2Vzc2lvbiwgaXQgd2lsbCBhYm9y dCBhbnkgb3BlcmF0aW9ucyBjdXJyZW50bHkgaW4gcHJvY2VzcywKPiAgICAgICAgICByZWxlYXNl IGFueSBsb2NrcyBhbmQgcmVzb3VyY2VzIGFzc29jaWF0ZWQgd2l0aCB0aGUgc2Vzc2lvbiwgYW5k Cj4gICAgICAgICAgY2xvc2UgYW55IGFzc29jaWF0ZWQgY29ubmVjdGlvbnMuCj4KPiAgICAgICAg ICBJZiBhIE5FVENPTkYgc2VydmVyIHJlY2VpdmVzIGEgPGtpbGwtc2Vzc2lvbj4gcmVxdWVzdCB3 aGlsZQo+ICAgICAgICAgIHByb2Nlc3NpbmcgYSBjb25maXJtZWQgY29tbWl0IChTZWN0aW9uIDgu NCksIGl0IG11c3QgcmVzdG9yZSB0aGUKPiAgICAgICAgICBjb25maWd1cmF0aW9uIHRvIGl0cyBz dGF0ZSBiZWZvcmUgdGhlIGNvbmZpcm1lZCBjb21taXQgd2FzIGlzc3VlZC4KPgo+ICAgICAgICAg IE90aGVyd2lzZSwgdGhlIDxraWxsLXNlc3Npb24+IG9wZXJhdGlvbiBkb2VzIG5vdCByb2xsIGJh Y2sKPiAgICAgICAgICBjb25maWd1cmF0aW9uIG9yIG90aGVyIGRldmljZSBzdGF0ZSBtb2RpZmlj YXRpb25zIG1hZGUgYnkgdGhlCj4gICAgICAgICAgZW50aXR5IGhvbGRpbmcgdGhlIGxvY2suIjsK Pgo+ICAgICAgIHJlZmVyZW5jZSAiUkZDIDQ3NDEsIHNlY3Rpb24gNy45IjsKPgo+ICAgICAgIG5j eDpycGMtdHlwZSAiZXhlYyI7Cj4KPiAgICAgICBpbnB1dCB7Cj4gICAgICAgICBsZWFmIHNlc3Np b24taWQgewo+ICAgICAgICAgICBkZXNjcmlwdGlvbiAiUGFydGljdWxhciBzZXNzaW9uIHRvIGtp bGwuIjsKPiAgICAgICAgICAgdHlwZSBTZXNzaW9uSWQ7Cj4gICAgICAgICAgIG1hbmRhdG9yeSB0 cnVlOwo+ICAgICAgICAgfQo+ICAgICAgIH0KPiAgICB9Cj4KPiAgICBycGMgY29tbWl0IHsKPiAg ICAgICBkZXNjcmlwdGlvbgo+ICAgICAgICAgIk9ubHkgYXZhaWxhYmxlIGlmICdjYW5kaWRhdGUn IGNhcGFiaWxpdHkgaXMgc3VwcG9ydGVkLgo+Cj4gICAgICAgICAgV2hlbiBhIGNhbmRpZGF0ZSBj b25maWd1cmF0aW9uJ3MgY29udGVudCBpcyBjb21wbGV0ZSwgdGhlCj4gICAgICAgICAgY29uZmln dXJhdGlvbiBkYXRhIGNhbiBiZSBjb21taXR0ZWQsIHB1Ymxpc2hpbmcgdGhlIGRhdGEgc2V0IHRv Cj4gICAgICAgICAgdGhlIHJlc3Qgb2YgdGhlIGRldmljZSBhbmQgcmVxdWVzdGluZyB0aGUgZGV2 aWNlIHRvIGNvbmZvcm0gdG8KPiAgICAgICAgICB0aGUgYmVoYXZpb3IgZGVzY3JpYmVkIGluIHRo ZSBuZXcgY29uZmlndXJhdGlvbi4KPgo+ICAgICAgICAgIFRvIGNvbW1pdCB0aGUgY2FuZGlkYXRl IGNvbmZpZ3VyYXRpb24gYXMgdGhlIGRldmljZSdzIG5ldwo+ICAgICAgICAgIGN1cnJlbnQgY29u ZmlndXJhdGlvbiwgdXNlIHRoZSA8Y29tbWl0PiBvcGVyYXRpb24uCj4KPiAgICAgICAgICBUaGUg J2NvbW1pdCcgb3BlcmF0aW9uIGluc3RydWN0cyB0aGUgZGV2aWNlIHRvIGltcGxlbWVudCB0aGUK PiAgICAgICAgICBjb25maWd1cmF0aW9uIGRhdGEgY29udGFpbmVkIGluIHRoZSBjYW5kaWRhdGUg Y29uZmlndXJhdGlvbi4KPiAgICAgICAgICBJZiB0aGUgZGV2aWNlIGlzIHVuYWJsZSB0byBjb21t aXQgYWxsIG9mIHRoZSBjaGFuZ2VzIGluIHRoZQo+ICAgICAgICAgIGNhbmRpZGF0ZSBjb25maWd1 cmF0aW9uIGRhdGFzdG9yZSwgdGhlbiB0aGUgcnVubmluZwo+ICAgICAgICAgIGNvbmZpZ3VyYXRp b24gTVVTVCByZW1haW4gdW5jaGFuZ2VkLiAgSWYgdGhlIGRldmljZSBkb2VzCj4gICAgICAgICAg c3VjY2VlZCBpbiBjb21taXR0aW5nLCB0aGUgcnVubmluZyBjb25maWd1cmF0aW9uIE1VU1QgYmUK PiAgICAgICAgICB1cGRhdGVkIHdpdGggdGhlIGNvbnRlbnRzIG9mIHRoZSBjYW5kaWRhdGUgY29u ZmlndXJhdGlvbi4KPgo+ICAgICAgICAgIElmIHRoZSBzeXN0ZW0gZG9lcyBub3QgaGF2ZSB0aGUg OmNhbmRpZGF0ZSBjYXBhYmlsaXR5LCB0aGUKPiAgICAgICAgICAnY29tbWl0JyBvcGVyYXRpb24g aXMgbm90IGF2YWlsYWJsZS4iOwo+Cj4gICAgICAgcmVmZXJlbmNlICJSRkMgNDc0MSwgc2VjdGlv biA4LjMuNC4xIjsKPgo+ICAgICAgIG5jeDpycGMtdHlwZSAiY29uZmlnIjsKPgo+ICAgICAgIGlu cHV0IHsKPiAgICAgICAgIGxlYWYgY29uZmlybWVkIHsKPiAgICAgICAgICAgZGVzY3JpcHRpb24K PiAgICAgICAgICAgICAiUmVxdWVzdCBhIGNvbmZpcm1lZCBjb21taXQuICBPbmx5IGF2YWlsYWJs ZSBpZgo+ICAgICAgICAgICAgICAnY29uZmlybWVkLWNvbW1pdCcgY2FwYWJpbGl0eSBpcyBzdXBw b3J0ZWQuIjsKPiAgICAgICAgICAgcmVmZXJlbmNlICJSRkMgNDc0MSwgc2VjdGlvbiA4LjQuNS4x IjsKPiAgICAgICAgICAgdHlwZSBlbXB0eTsKPiAgICAgICAgIH0KPgo+ICAgICAgICAgbGVhZiBj b25maXJtLXRpbWVvdXQgewo+ICAgICAgICAgICBkZXNjcmlwdGlvbgo+ICAgICAgICAgICAgICJS ZXF1ZXN0IGEgc3BlY2lmaWMgdGltZW91dCBwZXJpb2QgZm9yIGEgY29uZmlybWVkIGNvbW1pdAo+ ICAgICAgICAgICAgICBpZiAnY29uZmlybWVkLWNvbW1pdCcgY2FwYWJpbGl0eSBzdXBwb3J0ZWQu IjsKPiAgICAgICAgICAgcmVmZXJlbmNlICJSRkMgNDc0MSwgc2VjdGlvbiA4LjQuNS4xIjsKPiAg ICAgICAgICAgdHlwZSBDb25maXJtVGltZW91dFR5cGU7Cj4gICAgICAgICB9Cj4gICAgICAgfQo+ ICAgIH0KPgo+ICAgIHJwYyBkaXNjYXJkLWNoYW5nZXMgewo+ICAgICAgIGRlc2NyaXB0aW9uCj4g ICAgICAgICAiT25seSBhdmFpbGFibGUgaWYgJ2NhbmRpZGF0ZScgY2FwYWJpbGl0eSBpcyBzdXBw b3J0ZWQuCj4KPiAgICAgICAgICBJZiB0aGUgY2xpZW50IGRlY2lkZXMgdGhhdCB0aGUgY2FuZGlk YXRlIGNvbmZpZ3VyYXRpb24gc2hvdWxkIG5vdCBiZQo+ICAgICAgICAgIGNvbW1pdHRlZCwgdGhl ICdkaXNjYXJkLWNoYW5nZXMnIG9wZXJhdGlvbiBjYW4gYmUgdXNlZCB0byByZXZlcnQgdGhlCj4g ICAgICAgICAgY2FuZGlkYXRlIGNvbmZpZ3VyYXRpb24gdG8gdGhlIGN1cnJlbnQgcnVubmluZyBj b25maWd1cmF0aW9uLgo+Cj4gICAgICAgICAgVGhpcyBvcGVyYXRpb24gZGlzY2FyZHMgYW55IHVu Y29tbWl0dGVkIGNoYW5nZXMgYnkgcmVzZXR0aW5nIHRoZQo+ICAgICAgICAgIGNhbmRpZGF0ZSBj b25maWd1cmF0aW9uIHdpdGggdGhlIGNvbnRlbnQgb2YgdGhlIHJ1bm5pbmcKPiAgICAgICAgICBj b25maWd1cmF0aW9uLiI7Cj4KPiAgICAgICByZWZlcmVuY2UgIlJGQyA0NzQxLCBzZWN0aW9uIDgu My40LjIiOwo+Cj4gICAgICAgbmN4OnJwYy10eXBlICJjb25maWciOwo+Cj4gICAgfQo+Cj4gICAg cnBjIHZhbGlkYXRlIHsKPiAgICAgICBkZXNjcmlwdGlvbgo+ICAgICAgICAgICJPbmx5IGF2YWls YWJsZSBpZiAndmFsaWRhdGUnIGNhcGFiaWxpdHkgaXMgc3VwcG9ydGVkLgo+Cj4gICAgICAgICAg IFZhbGlkYXRlcyB0aGUgY29udGVudHMgb2YgdGhlIHNwZWNpZmllZCBjb25maWd1cmF0aW9uLiI7 Cj4KPiAgICAgICByZWZlcmVuY2UgIlJGQyA0NzQxLCBzZWN0aW9uIDguNi40LjEiOwo+Cj4gICAg ICAgbmN4OnJwYy10eXBlICJjb25maWciOwo+Cj4gICAgICAgaW5wdXQgewo+ICAgICAgICAgY29u dGFpbmVyIHNvdXJjZSB7Cj4gICAgICAgICAgIGRlc2NyaXB0aW9uICJQYXJ0aWN1bGFyIGNvbmZp Z3VyYXRpb24gdG8gdmFsaWRhdGUuIjsKPiAgICAgICAgICAgLy8gbWFuZGF0b3J5IHRydWU7Cj4g ICAgICAgICAgIHVzZXMgUnBjT3BlcmF0aW9uU291cmNlVHlwZTsKPiAgICAgICAgIH0KPiAgICAg ICB9Cj4gICAgfQo+Cj4gICAgY29udGFpbmVyIGNvbmZpZyB7Cj4gICAgICBkZXNjcmlwdGlvbgo+ ICAgICAgICAiVXNlZCBhcyB0aGUgY29udGFpbmVyIGZvciBORVRDT05GIG9iamVjdCBkZWZpbml0 aW9ucy4iOwo+ICAgICAgbmN4OnJvb3Q7Cj4gICAgICBuY3g6YWJzdHJhY3Q7Cj4gICAgfQo+Cj4g fQo+Cj4KPgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgoKPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IG5ldG1vZCBtYWlsaW5nIGxpc3QKPiBuZXRt b2RAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v ZAo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRt b2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Fri Oct 10 07:56: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 A4E853A69C9; Fri, 10 Oct 2008 07:56: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 375C53A69FF for ; Fri, 10 Oct 2008 07:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.35 X-Spam-Level: * X-Spam-Status: No, score=1.35 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKAKjx7R-kMt for ; Fri, 10 Oct 2008 07:56:11 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 60A1C3A6A50 for ; Fri, 10 Oct 2008 07:56:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by office2.cesnet.cz (Postfix) with ESMTP id 8DD75D800CC for ; Fri, 10 Oct 2008 16:56:54 +0200 (CEST) Received: from 66.129.238.85 ([66.129.238.85]) by office2.cesnet.cz (Horde MIME library) with HTTP for ; Fri, 10 Oct 2008 16:56:54 +0200 Message-ID: <20081010165654.2wb1cvw3rvkksk0k@office2.cesnet.cz> Date: Fri, 10 Oct 2008 16:56:54 +0200 From: lhotka@cesnet.cz To: netmod@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.0.2) Subject: [netmod] question to XML lawyers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 my proposal for the question about use of prefixes in XPath expression. Lada YANG specification defines the "namespace" and "prefix" statements that are mandatory for every YANG module. The purpose of these statements is to define a namespace to which all names defined in the module belong, and a recommended prefix that should be used whenever possible in XML documents and other contexts that use these qualified names. In addition, YANG utilizes XPath 1.0 expressions in several places. In order to make the XPath expressions more readable for humans, the YANG specification defines the context for evaluating these expressions, which includes the notion of a default namespace that is set to the namespace of the local module where the Xpath expression appear. Consequently, the local QNames are allowed to be used without any namespace prefix in the XPath expression. QUESTION: Is this approach allowed by the XPath 1.0 specification or must the QNames always be used with an explicit namespace prefix? _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Oct 11 10:25:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08BEE3A686E; Sat, 11 Oct 2008 10:25: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 D01953A686E for ; Sat, 11 Oct 2008 10:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVP5fNoHuJhB for ; Sat, 11 Oct 2008 10:25:54 -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 26D403A63EC for ; Sat, 11 Oct 2008 10:25:53 -0700 (PDT) Received: (qmail 97888 invoked from network); 11 Oct 2008 17:26:36 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.240.48 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 11 Oct 2008 17:26:34 -0000 X-YMail-OSG: fDYD0xQVM1m2TUNYT49QZI811cNfHt2vggZRZgysPUYlfzIndh7VvXqU7sJjxescdYEUnODn2GOu7JZTHZLdqMgo5UKNtSzb5_Ng0iNtAwhp6cJXn9eoV.51xraMQ8feV5Q- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48F0E1C9.1020308@netconfcentral.com> Date: Sat, 11 Oct 2008 10:26:33 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] methods and events X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I am removing my objection to putting rpc-stmt and notification-stmt within the data-def-stmt, if it is done carefully and with lots of thought. I think new constructs should be used instead of overloading the "plain" versions. I prefer to view the config database as "just data" because it matches the "C" world I know. I am skeptical that this mechanism alone will be enough to support OO application development, but I think we have to try anyway. container foo-service { presence "Creates an instance of the foo service if present."; grouping FooServiceParameters { ... } grouping FooServiceStats { ... } method start { input { uses FooServiceParameters; } } method stop; method restart { input { uses FooServiceParameters; } } method status { output { uses FooServiceStats; } } event fooServiceEnabled { uses FooServiceStatus; } // config data (can it be private or read-only?) uses FooServiceParameters; // monitoring data uses FooServiceStats; } The differences between a method and an rpc: 1) a method has an extra parameter that can select from various standard method signatures. 2) a method has extra automatic parameters (expected in the PDU), based on the method signature 3) rpc can only be top-level (as it is now) and method can only be a substatement of list-stmt or container-stmt. The differences between an event and a notification: 1) an event has extra automatic data generated in notification PDUs, based on a standard notification template 2) notification can only be top-level (as it is now) and method can only be a substatement of list-stmt or container-stmt. A method signature template will be needed, so it can be automated instead of hard-wired: signature simple-rpc { leaf callingPoint { type instance-identifier; } } Comments? Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Oct 11 11:23: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 BD7743A6916; Sat, 11 Oct 2008 11:23: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 9D0DA3A6916 for ; Sat, 11 Oct 2008 11:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 923laYypu3b3 for ; Sat, 11 Oct 2008 11:23:10 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id E8DEF3A68B9 for ; Sat, 11 Oct 2008 11:23:10 -0700 (PDT) Received: (qmail 39074 invoked from network); 11 Oct 2008 18:24:00 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.240.48 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 11 Oct 2008 18:23:58 -0000 X-YMail-OSG: ytuaf6wVM1m6_yiYZnurbLoVep4B9IuFXvDEU7UKbwmQoE03LkKJUNiXRJ5enoZVvwSNApXHfLdpzuaEgkuY9yFgFZZL._tvyLmfzOJef8sxFUrgAhH6FaQkAqzFx3FXdPOD3PyLo0kvWx7L4Ue7IshE X-Yahoo-Newman-Property: ymail-3 Message-ID: <48F0EF3D.7030008@netconfcentral.com> Date: Sat, 11 Oct 2008 11:23:57 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETMOD Working Group References: <48F0E1C9.1020308@netconfcentral.com> In-Reply-To: <48F0E1C9.1020308@netconfcentral.com> Subject: Re: [netmod] methods and events X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 am removing my objection to putting rpc-stmt and > notification-stmt within the data-def-stmt, if > it is done carefully and with lots of thought. > I think new constructs should be used instead of > overloading the "plain" versions. > > I prefer to view the config database as "just data" > because it matches the "C" world I know. I am > skeptical that this mechanism alone will be enough > to support OO application development, but I think > we have to try anyway. > > In case it isn't obvious what else data-def-stmt imples here: grouping FooService { container foo-service { ... } } container interfaces { list interface { key name; ... uses FooService { // refine as needed }; } } Andy > container foo-service { > presence "Creates an instance of the foo service if present."; > > grouping FooServiceParameters { > ... > } > > grouping FooServiceStats { > ... > } > > method start { > input { > uses FooServiceParameters; > } > } > > method stop; > > method restart { > input { > uses FooServiceParameters; > } > } > > method status { > output { > uses FooServiceStats; > } > } > > event fooServiceEnabled { > uses FooServiceStatus; > } > > // config data (can it be private or read-only?) > uses FooServiceParameters; > > // monitoring data > uses FooServiceStats; > > } > > > The differences between a method and an rpc: > > 1) a method has an extra parameter that can select from > various standard method signatures. > 2) a method has extra automatic parameters (expected in > the PDU), based on the method signature > 3) rpc can only be top-level (as it is now) and method > can only be a substatement of list-stmt or container-stmt. > > The differences between an event and a notification: > > 1) an event has extra automatic data generated in > notification PDUs, based on a standard notification template > 2) notification can only be top-level (as it is now) and method event ^^^^^^^ > can only be a substatement of list-stmt or container-stmt. > > > A method signature template will be needed, so it can be > automated instead of hard-wired: > > signature simple-rpc { > leaf callingPoint { > type instance-identifier; > } > } > > > > Comments? > > > 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 Sat Oct 11 12:25:56 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49BBF3A680E; Sat, 11 Oct 2008 12:25: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 A77713A6892 for ; Sat, 11 Oct 2008 12:25:54 -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 1Pb0tZKTQBJF for ; Sat, 11 Oct 2008 12:25: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 591EB3A680E for ; Sat, 11 Oct 2008 12:25:53 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B09DC0050 for ; Sat, 11 Oct 2008 21:26:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UCswYs-EcaJ1; Sat, 11 Oct 2008 21:26:35 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BB53C0026; Sat, 11 Oct 2008 21:26:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 210C17FC2B6; Sat, 11 Oct 2008 21:26:37 +0200 (CEST) Date: Sat, 11 Oct 2008 21:26:37 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20081011192637.GA697@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [netmod] identity and identityref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi! In the SMIv2 world, we sometimes use OBJECT IDENTIFIERs (OIDs) as distributed registries. An example are OIDs identifying crypto algorithms. By using OIDs instead of enumerations, everybody can create his own algorithm without having to go through a central registry (IANA). This clearly has proven useful. YANG currently lacks a mechanism to do this (enumerations are centralized, choices with augmentations can't be reused since this would require augmentable groupings). To provide distributed registries in YANG, we (Martin and myself) propose the following additions to YANG: 1) A new 'identity' statement that can be used to define identities (the equivalent of the SMIv2 OBJECT-IDENTITY macro). The base substatement associates an identity with a base identity. By way of example: // module a - introduces a crypto-alg registry module A { namespace uri:module:a; prefix a; identitiy crypto-alg { description ...; } } // module b - registers a new algorithm module B { namespace uri:module:b; prefix b; import A { prefix a; } identity des { base a:crypto-alg; description ...; } } 2) A new 'identityref' type is introduced with a 'base' (or scope?) restriction. The value set of an identityref is the set of identities with the same base. By way of example: // module C - uses a leaf with crypto algorithms module C { namespace uri:module:c; prefix c; import A { prefix a; } leaf x { type identityref { base a:crypto-alg; description ...; } } A possible XML encoding would look like this: b:des Note that the value uses an XML namespace prefix and hence another possible XML encoding would be: foo:des Using the XML namespace prefix in the XML encoding is consistent from an XML perspective. However, this requires that applications dealing with the value can deal with potentially different prefixes for the same identity. An alternative would be to prefix the identity value with the module name (B:des in the example) - this guarantees that the value is always the same but this is somewhat strange from an XML perspective. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Oct 11 12:29: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 9E4BE3A680E; Sat, 11 Oct 2008 12:29: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 26A963A6892 for ; Sat, 11 Oct 2008 12:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyIS3wZKRYTr for ; Sat, 11 Oct 2008 12:29:15 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 7D4BB3A680E for ; Sat, 11 Oct 2008 12:29:15 -0700 (PDT) Received: (qmail 83086 invoked from network); 11 Oct 2008 19:30:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.240.48 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 11 Oct 2008 19:30:03 -0000 X-YMail-OSG: yP4v_nYVM1k3kWE0uH9TRGZX0g8LZsn.SBgKRPncjFgqMi80BBikp1lmzDTm08MD3wpGzE2supxfUxaUs4fWWjmvem9sUSqL92Lwvnb70tzmsk0pjvECZdGDugRk7ZvTgeA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48F0FEBA.4050109@netconfcentral.com> Date: Sat, 11 Oct 2008 12:30:02 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETMOD Working Group References: <48F0E1C9.1020308@netconfcentral.com> In-Reply-To: <48F0E1C9.1020308@netconfcentral.com> Subject: Re: [netmod] methods and events X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org >.... > A method signature template will be needed, so it can be > automated instead of hard-wired: > > signature simple-rpc { > leaf callingPoint { > type instance-identifier; > } > } > In case this part isn't obvious: module yang { signature from-to-rpc { leaf from { type instance-identifier; } leaf to { type instance-identifier; } } } module X { import yang { prefix yang; } import acme { prefix acme; } list Y { ... method copy { method-type yang:from-to-rpc; // add extra copy-specific details } method move { method-type yang:from-to-rpc; // add extra move-specific details } method foo { method-type acme:my-rpc-signature; // add foo-specific details } } } I think this helps address the very valid concern that Phil raised at the interim about one simplistic template not being being sufficient. Or am I totally missing the point, and there is no need for method signatures (or templates) because all you really want is the 'self' parameter added to the rpc automatically? (Balazs?) > > > Comments? > > > Andy > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Oct 11 16:27: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 231F13A679C; Sat, 11 Oct 2008 16:27: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 171AE3A6855 for ; Sat, 11 Oct 2008 16:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7DBYXXtchYI for ; Sat, 11 Oct 2008 16:27:15 -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 5B6683A67F6 for ; Sat, 11 Oct 2008 16:27:15 -0700 (PDT) Received: (qmail 69514 invoked from network); 11 Oct 2008 23:28:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.240.48 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 11 Oct 2008 23:28:03 -0000 X-YMail-OSG: IFXDgNMVM1nD9ogBxDcixin3oKHQQGCpqBDlTc68ncG_F2h9qTZ4tkGGdYG8rO40UWv6EfopC.PlVGZVwsWjKHhy4BPwXHPD0TuEcItaTr22oCFrqrF5Pf_CBfx1ASfn4pA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48F13682.1030807@netconfcentral.com> Date: Sat, 11 Oct 2008 16:28:02 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: netmod@ietf.org References: <20081011192637.GA697@elstar.local> In-Reply-To: <20081011192637.GA697@elstar.local> Subject: Re: [netmod] identity and identityref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > Hi! > I like this idea a lot. I prefer to keep all XML instance documents XML namespace based, using local prefixes via xmlns attributes. Let's keep module names out of XML documents because it will confuse people who know XML and know about QNames. A YANG content QName is simple to think about as the namespace of the module + the name of an identifier within that module. A missing namespace should not be allowed for a YANG QName, since we cannot agree on what that means, or even if the NULL namespace is allowed. IMO, every YANG definition should be defined in a unique namespace, and the NULL namespace should be disallowed. Andy > In the SMIv2 world, we sometimes use OBJECT IDENTIFIERs (OIDs) as > distributed registries. An example are OIDs identifying crypto > algorithms. By using OIDs instead of enumerations, everybody can > create his own algorithm without having to go through a central > registry (IANA). This clearly has proven useful. > > YANG currently lacks a mechanism to do this (enumerations are > centralized, choices with augmentations can't be reused since this > would require augmentable groupings). To provide distributed > registries in YANG, we (Martin and myself) propose the following > additions to YANG: > > 1) A new 'identity' statement that can be used to define identities > (the equivalent of the SMIv2 OBJECT-IDENTITY macro). The base > substatement associates an identity with a base identity. By way of > example: > > // module a - introduces a crypto-alg registry > module A { > namespace uri:module:a; > prefix a; > identitiy crypto-alg { > description ...; > } > } > > // module b - registers a new algorithm > module B { > namespace uri:module:b; > prefix b; > import A { prefix a; } > identity des { > base a:crypto-alg; > description ...; > } > } > > 2) A new 'identityref' type is introduced with a 'base' (or scope?) > restriction. The value set of an identityref is the set of identities > with the same base. By way of example: > > // module C - uses a leaf with crypto algorithms > module C { > namespace uri:module:c; > prefix c; > import A { prefix a; } > leaf x { > type identityref { > base a:crypto-alg; > description ...; > } > } > > A possible XML encoding would look like this: > > b:des > > Note that the value uses an XML namespace prefix and hence another > possible XML encoding would be: > > foo:des > > Using the XML namespace prefix in the XML encoding is consistent from > an XML perspective. However, this requires that applications dealing > with the value can deal with potentially different prefixes for the > same identity. An alternative would be to prefix the identity value > with the module name (B:des in the example) - this guarantees that the > value is always the same but this is somewhat strange from an XML > perspective. > > /js > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 13 00:47: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 8ADAF3A68F7; Mon, 13 Oct 2008 00:47: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 606C53A6B84 for ; Mon, 13 Oct 2008 00:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.233 X-Spam-Level: X-Spam-Status: No, score=-6.233 tagged_above=-999 required=5 tests=[AWL=0.016, 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 GDAIbIRA9CBv for ; Mon, 13 Oct 2008 00:46:58 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 24DDF3A6AB3 for ; Mon, 13 Oct 2008 00:46:58 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A2FCD20820 for ; Mon, 13 Oct 2008 09:47:06 +0200 (CEST) X-AuditID: c1b4fb3c-ae0cebb0000015b5-f0-48f2fcfa49ca Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 671EE20835 for ; Mon, 13 Oct 2008 09:47:06 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 09:47:01 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 09:47:01 +0200 Message-ID: <48F2FCF5.7010904@ericsson.com> Date: Mon, 13 Oct 2008 09:47:01 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netmod@ietf.org References: <20081011192637.GA697@elstar.local> In-Reply-To: <20081011192637.GA697@elstar.local> X-OriginalArrivalTime: 13 Oct 2008 07:47:01.0662 (UTC) FILETIME=[E0D18BE0:01C92D07] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] identity and identityref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > Hi! > > In the SMIv2 world, we sometimes use OBJECT IDENTIFIERs (OIDs) as > distributed registries. An example are OIDs identifying crypto > algorithms. By using OIDs instead of enumerations, everybody can > create his own algorithm without having to go through a central > registry (IANA). This clearly has proven useful. > > YANG currently lacks a mechanism to do this (enumerations are > centralized, choices with augmentations can't be reused since this > would require augmentable groupings). To provide distributed > registries in YANG, we (Martin and myself) propose the following > additions to YANG: > > 1) A new 'identity' statement that can be used to define identities > (the equivalent of the SMIv2 OBJECT-IDENTITY macro). The base > substatement associates an identity with a base identity. By way of > example: > > // module a - introduces a crypto-alg registry > module A { > namespace uri:module:a; > prefix a; > identitiy crypto-alg { > description ...; > } > } > > // module b - registers a new algorithm > module B { > namespace uri:module:b; > prefix b; > import A { prefix a; } > identity des { > base a:crypto-alg; > description ...; > } > } > > 2) A new 'identityref' type is introduced with a 'base' (or scope?) > restriction. The value set of an identityref is the set of identities > with the same base. By way of example: > > // module C - uses a leaf with crypto algorithms > module C { > namespace uri:module:c; > prefix c; > import A { prefix a; } > leaf x { > type identityref { > base a:crypto-alg; > description ...; > } > } > > A possible XML encoding would look like this: > > b:des > > Note that the value uses an XML namespace prefix and hence another > possible XML encoding would be: > > foo:des > > Using the XML namespace prefix in the XML encoding is consistent from > an XML perspective. However, this requires that applications dealing > with the value can deal with potentially different prefixes for the > same identity. An alternative would be to prefix the identity value > with the module name (B:des in the example) - this guarantees that the > value is always the same but this is somewhat strange from an XML > perspective. > > /js > The idea is nice. Question: do you have to import the module B, if you want to use the value defined in module B? If I do not import module B how does my system know that a value defined in Module B exists? Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 13 00:53: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 035BB3A681C; Mon, 13 Oct 2008 00:53: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 464203A6842 for ; Mon, 13 Oct 2008 00:53:07 -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 nvfqT5pgUAwG for ; Mon, 13 Oct 2008 00:53:06 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 74C853A681B for ; Mon, 13 Oct 2008 00:53:06 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3314976C4E6; Mon, 13 Oct 2008 09:53:00 +0200 (CEST) Date: Mon, 13 Oct 2008 09:57:08 +0200 (CEST) Message-Id: <20081013.095708.189975258.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <48F2FCF5.7010904@ericsson.com> References: <20081011192637.GA697@elstar.local> <48F2FCF5.7010904@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] identity and identityref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: > The idea is nice. > Question: do you have to import the module B, if you want to use the value > defined in module B? What do you mean when you say "use the value defined in module B"? If your module refer to a defintion in module B, then you have to import it, otherwise not. > If I do not import module B how does my system know that a > value defined in Module B exists? Compare with instance-identifer. You don't import all the modules that may end up in an instance-identifer. Your system will implement a set of modules. If these modules define identities with the identity in module A as a base, then a client can use them in edit-config requests. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 13 01:23:41 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 211DB3A657C; Mon, 13 Oct 2008 01:23:41 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0E03A67AF for ; Mon, 13 Oct 2008 01:23:39 -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 b9PF9PMKMjCU for ; Mon, 13 Oct 2008 01:23:38 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9A07B3A657C for ; Mon, 13 Oct 2008 01:23:38 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8988276C4E6; Mon, 13 Oct 2008 10:23:19 +0200 (CEST) Date: Mon, 13 Oct 2008 10:27:31 +0200 (CEST) Message-Id: <20081013.102731.02166956.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48F0FEBA.4050109@netconfcentral.com> References: <48F0E1C9.1020308@netconfcentral.com> <48F0FEBA.4050109@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] methods and events X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: > Or am I totally missing the point, and there is no need > for method signatures (or templates) because all you > really want is the 'self' parameter added to > the rpc automatically? (Balazs?) In our proprietary DML, we support these 'methods', but we call them 'actions'. We do not have templates etc, just the equivalent of a callingPoint. In order to support locally scoped action names (i.e. the same name 'reset' can exist in multiple locations, with different parameters), we use a generic action rpc: eth0 I.e.instead of one 'callingPoint' parameter, we use the same instance identification mechanism as edit-config. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 13 01:59: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 E89353A6A94; Mon, 13 Oct 2008 01:59: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 45DE43A6A94 for ; Mon, 13 Oct 2008 01:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[AWL=0.015, 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 x4EWCgXULxdl for ; Mon, 13 Oct 2008 01:59:03 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 12BE83A6A87 for ; Mon, 13 Oct 2008 01:59:02 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8E74120845; Mon, 13 Oct 2008 10:59:17 +0200 (CEST) X-AuditID: c1b4fb3c-ab8c9bb0000015b5-7a-48f30de532b1 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 74E362063A; Mon, 13 Oct 2008 10:59:17 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 10:59:16 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 10:59:15 +0200 Message-ID: <48F30DE3.2010401@ericsson.com> Date: Mon, 13 Oct 2008 10:59:15 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <48F0E1C9.1020308@netconfcentral.com> <48F0FEBA.4050109@netconfcentral.com> In-Reply-To: <48F0FEBA.4050109@netconfcentral.com> X-OriginalArrivalTime: 13 Oct 2008 08:59:15.0860 (UTC) FILETIME=[F833AD40:01C92D11] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] methods and events X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Andy, Thanks for the proposals. For me one automatic parameter (self) is important. As Phil stated, there might be cases where multiple parameters are needed, but IMO there is no common pattern in the other parameters. Manipulating one managed item (needing one instance identifier) is a common task. Tasks that need multiple instance identifiers like copying objects or replacing them are much less frequent, and parameters beyond "self" are typically different in different rpcs/actions. Although I do not see the need for this, if we agree that is a good idea, I have no objection for having different names for top level rpcs and nested methods as you propose. Comments? regards Balazs Andy Bierman wrote: > >.... >> A method signature template will be needed, so it can be >> automated instead of hard-wired: >> >> signature simple-rpc { >> leaf callingPoint { >> type instance-identifier; >> } >> } >> > > In case this part isn't obvious: > > module yang { > > signature from-to-rpc { > leaf from { > type instance-identifier; > } > leaf to { > type instance-identifier; > } > } > } > > module X { > > import yang { prefix yang; } > > import acme { prefix acme; } > > list Y { > ... > method copy { > method-type yang:from-to-rpc; > // add extra copy-specific details > } > > method move { > method-type yang:from-to-rpc; > // add extra move-specific details > } > > method foo { > method-type acme:my-rpc-signature; > // add foo-specific details > } > } > } > > I think this helps address the very valid concern that Phil raised > at the interim about one simplistic template not being > being sufficient. > > Or am I totally missing the point, and there is no need > for method signatures (or templates) because all you > really want is the 'self' parameter added to > the rpc automatically? (Balazs?) > > >> >> >> Comments? >> >> >> Andy >> > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 13 07:16:28 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A0773A67E3; Mon, 13 Oct 2008 07:16:28 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BB7728C102 for ; Mon, 13 Oct 2008 07:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZ075vrZSxsJ for ; Mon, 13 Oct 2008 07:16:23 -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 EF5D03A67E3 for ; Mon, 13 Oct 2008 07:16:22 -0700 (PDT) Received: (qmail 82468 invoked from network); 13 Oct 2008 14:16:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.129.131 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 13 Oct 2008 14:16:37 -0000 X-YMail-OSG: s17y8TQVM1lotTxYJS2XwJMaE59VFJsrRlwQLxQm4RRDcOtiT1_.jJ3fSvPjIN1wCviWT8wX8GQxrj_U0FnYyG2HAxfcpwTON5WJLKRtk5MrK7KpyO6.FFjry8VCzKCD7SJ5MNXqPQh95ZhM9KHg213Z X-Yahoo-Newman-Property: ymail-3 Message-ID: <48F35844.7020201@netconfcentral.com> Date: Mon, 13 Oct 2008 07:16:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Balazs Lengyel References: <48F0E1C9.1020308@netconfcentral.com> <48F0FEBA.4050109@netconfcentral.com> <48F30DE3.2010401@ericsson.com> In-Reply-To: <48F30DE3.2010401@ericsson.com> Cc: NETMOD Working Group Subject: Re: [netmod] methods and events X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Andy, > Thanks for the proposals. > For me one automatic parameter (self) is important. > > As Phil stated, there might be cases where multiple parameters are > needed, but IMO there is no common pattern in the other parameters. > Manipulating one managed item (needing one instance identifier) is a > common task. Tasks that need multiple instance identifiers like copying > objects or replacing them are much less frequent, and parameters beyond > "self" are typically different in different rpcs/actions. > > Although I do not see the need for this, if we agree that is a good > idea, I have no objection for having different names for top level rpcs > and nested methods as you propose. Comments? > I think we should not use the signature template. The difference is the 'self' parameter. I also prefer the name 'action' to 'method' because it carries less baggage. An implementation will always need to check the ancestors to make sure an 'action' is not defined within an 'rpc', no matter what it is called. Doesn't the same callingPoint idea apply to notifications as well as actions? Does it ever make sense to nest an action within: - rpc-foo/input - rpc-foo/output - notif-foo/ Does it ever make sense to nest a notification within: - rpc-foo/input - rpc-foo/output - notif-foo/ IMO, NO to all of the above. Actions and events can only be within the database objects, and not associated with or PDUs at all. > regards Balazs > Andy > > > Andy Bierman wrote: >> >.... >>> A method signature template will be needed, so it can be >>> automated instead of hard-wired: >>> >>> signature simple-rpc { >>> leaf callingPoint { >>> type instance-identifier; >>> } >>> } >>> >> >> In case this part isn't obvious: >> >> module yang { >> >> signature from-to-rpc { >> leaf from { >> type instance-identifier; >> } >> leaf to { >> type instance-identifier; >> } >> } >> } >> >> module X { >> >> import yang { prefix yang; } >> >> import acme { prefix acme; } >> >> list Y { >> ... >> method copy { >> method-type yang:from-to-rpc; >> // add extra copy-specific details >> } >> >> method move { >> method-type yang:from-to-rpc; >> // add extra move-specific details >> } >> >> method foo { >> method-type acme:my-rpc-signature; >> // add foo-specific details >> } >> } >> } >> >> I think this helps address the very valid concern that Phil raised >> at the interim about one simplistic template not being >> being sufficient. >> >> Or am I totally missing the point, and there is no need >> for method signatures (or templates) because all you >> really want is the 'self' parameter added to >> the rpc automatically? (Balazs?) >> >> >>> >>> >>> Comments? >>> >>> >>> Andy >>> >> >> >> Andy >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 13 21:54: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 34BA63A6BC6; Mon, 13 Oct 2008 21:54: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 1D23B3A6BCF for ; Mon, 13 Oct 2008 21:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 ZI6kB9-qqpEi for ; Mon, 13 Oct 2008 21:54:27 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 1C7D93A6BC6 for ; Mon, 13 Oct 2008 21:54:27 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8P00GN3PNFXI@usaga01-in.huawei.com> for netmod@ietf.org; Mon, 13 Oct 2008 21:54:52 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8P0011BPNEJI@usaga01-in.huawei.com> for netmod@ietf.org; Mon, 13 Oct 2008 21:54:51 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Tue, 14 Oct 2008 12:54:33 +0800 Date: Tue, 14 Oct 2008 12:54:33 +0800 From: fanhuaxiang 90002624 To: netmod@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal Subject: [netmod] I found some inconsistency in yang-central website X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 found some inconsistency exist in website http://www.yang-central.org/twiki/bin/view/Main/YangExamples, NETCONF Monitoring Data Model section, inconsistency between netconf-state.xsd and netconf-state.yang: 1> list subscription not equavalent to complexType NetconfSubscriptionInfo semantically. NetconfSubscriptionInfo take more children than subscription. 2> in xsd, subscriptions is sibling of configurations, but in yang, the relationship becomes to child. 3> complexType ManagementSessionInfo seems lack a key element. regards, washam _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Oct 14 04: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 06E653A67EA; Tue, 14 Oct 2008 04:50: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 2AFF43A692B for ; Tue, 14 Oct 2008 04:50:53 -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 H46PBSRGO5f6 for ; Tue, 14 Oct 2008 04:50:47 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id BF24D3A67EA for ; Tue, 14 Oct 2008 04:50:47 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 87F1320DB0 for ; Tue, 14 Oct 2008 13:51:07 +0200 (CEST) X-AuditID: c1b4fb3c-ac0cabb0000015b5-7b-48f487ab3d44 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 50FB420D41 for ; Tue, 14 Oct 2008 13:51:07 +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, 14 Oct 2008 13:50:56 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 13:50:56 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 14 Oct 2008 13:50:56 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200810141350.56645.david.partain@ericsson.com> X-OriginalArrivalTime: 14 Oct 2008 11:50:56.0965 (UTC) FILETIME=[1E8D4F50:01C92DF3] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Agenda items for the upcoming IETF meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings, If you have agenda items you think should be on the agenda for the meetings in Minneapolis, please let the chairs know. With kind regards, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Oct 14 05: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 66AA73A6BA4; Tue, 14 Oct 2008 05: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 7124E3A67EE for ; Tue, 14 Oct 2008 05:07:12 -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 WjFvKKywfHYn for ; Tue, 14 Oct 2008 05:07:11 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A3B253A6B7E for ; Tue, 14 Oct 2008 05:07:11 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7E42F20A56 for ; Tue, 14 Oct 2008 13:51:07 +0200 (CEST) X-AuditID: c1b4fb3c-ab0c8bb0000015b5-7a-48f487ab58b0 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 44ABB20AC4 for ; Tue, 14 Oct 2008 13:51:07 +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, 14 Oct 2008 13:50:14 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 13:50:13 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 14 Oct 2008 13:50:13 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200810141350.13729.david.partain@ericsson.com> X-OriginalArrivalTime: 14 Oct 2008 11:50:13.0997 (UTC) FILETIME=[04F0E9D0:01C92DF3] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Updates after the Interim Meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings all, It's time for the big push after the interim meeting last week. Firstly, a big thank you to our hosts, Ron Bonica & Phil Shafer and Juniper Networks! Secondly, thanks to all of the participants who took the time to spend three days slogging through NETMOD issues. The meeting was, in my opinion, very successful. Over the course of this week and next, the chairs will be focusing on the following: 1. Working on getting the minutes from the interim. They are not blow-by-blow, but they certainly try to cover the discussion for future generations. I have notes from a couple of people, but if you took notes you're willing to share, please send them to me ASAP. 2. Where there was rough consensus at the interim meeting, we will issue a call for consensus on the mailing list. If these calls for consensus are met with applause or silence, we'll consider that issue closed and ask the authors to take appropriate action. Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 15 01:37:14 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94C0B3A68C8; Wed, 15 Oct 2008 01:37: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 63A1C3A68CC for ; Wed, 15 Oct 2008 01:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.014, 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 xLNliYsiAyN2 for ; Wed, 15 Oct 2008 01:37:12 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 80C443A68C8 for ; Wed, 15 Oct 2008 01:37:12 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A2E4520E84 for ; Wed, 15 Oct 2008 10:38:04 +0200 (CEST) X-AuditID: c1b4fb3c-ac0cabb0000015b5-e5-48f5abeb065e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 09F3020CA0 for ; Wed, 15 Oct 2008 10:38:04 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Oct 2008 10:37:44 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Oct 2008 10:37:43 +0200 Message-ID: <48F5ABD8.7030506@ericsson.com> Date: Wed, 15 Oct 2008 10:37:44 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETMOD Working Group X-OriginalArrivalTime: 15 Oct 2008 08:37:44.0004 (UTC) FILETIME=[4B059840:01C92EA1] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Additional substatements in groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, I wanted to use a grouping as a kind-of complex type. I ran into the problem that the list of substatements inside a grouping is rather limited. Why can't we use the following statements directly under a grouping? - key (need it !!!) - mandatory - min-elements (need it !!!) - max-elements (need it !!!) - config - type Generally: IMHO the main aim of a grouping is to be meaningful and correct ONCE IT HAS BEEN PUT INTO A USES. Validation of a grouping itself should only complain about things, that can in no way be correct with any kind of uses statement. That means nearly all statements could be allowed inside a grouping with some exceptions e.g. module, submodule. All the above statements can perfectly fulfill this requirement. E.g. the following examples make perfect sense for me: grouping foo { key id; leaf id; } list myFooList { uses foo; } Or if a set of modules all reference the same set of other modules: grouping commonImports { import yang-types {..} import inet-types {...} import ieee-types {...} import ericssonTypes {...} import ericssonExtensions {...} import tpsPlatformBaseStuff {...} } module oneOfManyModules { uses commonImports; } Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 15 06:43:05 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ECA93A692F; Wed, 15 Oct 2008 06:43:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25BBD3A6AF6 for ; Wed, 15 Oct 2008 06:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[AWL=0.358, 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 vPKfR6cZYec1 for ; Wed, 15 Oct 2008 06:43:01 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id BF08E3A692F for ; Wed, 15 Oct 2008 06:43:00 -0700 (PDT) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 0F4B8D800C5 for ; Wed, 15 Oct 2008 15:43:40 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Wed, 15 Oct 2008 15:43:39 +0200 Message-Id: <1224078219.15520.9.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [netmod] architecture draft - DSDL X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 a follow-up to our discussion at the interim, I propose the following text for inclusion in the YANG architecture draft, perhaps as a separate section. Comments and suggestions are certainly welcome. Lada ======================================================================== The hierarchical structure, datatypes of nodes and semantics specified in a YANG module have their counterparts in similar (but not identical) structural, datatype and semantical constraints on NETCONF protocol data units (PDU) that are exchanged within a NETCONF session. In [YANG], the implications of YANG constructs and constraints for NETCONF PDUs are explained in plain English and by giving numerous examples. However, as the PDUs are supposed to be the only means of communication between the agent and manager, the ability to formally validate the entire contents of NETCONF PDUs is crucial for verifying that the contract expressed by the YANG module is fulfilled. Since NETCONF PDUs are encoded in XML, it is natural to use XML Schema Languages for their validation. To facilitate this, YANG offers a standardized mapping of YANG modules Document Schema Description Languages (DSDL) [DSDL] that are being developed as the set of international standards ISO/IEC 19757. DSDL are considered to be the best choice for the given purpose because they address not only grammar and datatypes of XML documents but also semantic constraints and rules for modifying information set of the document, such as application of default values. In addition, DSDL offers formal means for coordinating multiple independent schemas and specifying how to apply the schemas to the various parts of the document. This is useful since NETCONF PDUs are typically composed of multiple vocabularies. For example, an edit-config request consists of several nested elements specified in [RFC4741] (, and ) that encapsulate configuration data and, moreover, some configuration data elements may carry "operation" attributes that are again defined in [RFC4741]. Rather than merging the schema of [RFC4741] with that of a particular data model into a new monolithic schema, Namespace-based Validation Dispatching Language (NVDL, part 4 of DSDL) allows for setting up a validation procedure that applies specific schemas to various levels and sections of the XML document. While it is true that some parts of the DSDL set need further development before they can be used in applications, the standard mapping from YANG to DSDL uses only those DSDL parts that already have the status of an ISO/IEC International Standard or are at the stage of a FCD (Final Committee Draft): - Part 2: Regular-grammar-based validation - RELAX NG (ISO/IEC 19757-2:2003) - Part 3: Rule-based validation - Schematron (ISO/IEC 19757-3:2006) - Part 4: Namespace-based Validation Dispatching Language - NVDL (ISO/IEC 19757-4:2006) - Part 8: Document schema renaming language - DSRL (ISO/IEC 19757-8 FCD) For several details of YANG semantics that cannot be adequately represented in the four DSDL schema languages mentioned above, the mapping introduces a small set of new XML attributes that annotate appropriate elements in the RELAX NG schema. In addition, metadata contained in YANG modules such as contact person, organization and revision date are mapped to analogical Dublin Core metadata terms. The mapping of YANG modules to DSDL schemas is further complicated by the inherent variability of NETCONF PDUs. A number of NETCONF RPC methods are defined in [RFC4741] and other RPC methods may be defined by data models. Yet another type of PDUs are asynchronous notifications. Contents of each of these PDU types is constrained in a specific way and in some cases other constraints may follow from the context - for example, contents of a get-config reply depends on filters that may be present in the corresponding get-config request, on available features etc. Last but not least, in order to get a complete schema for a particular NETCONF session, one has to take into account all YANG modules that have been negotiated as capabilities in the hello message. These modules may also be interrelated via the augment statement. In order to cope with this complexity, the mapping procedure is divided into two phases illustrated in the following figure: 1. In the first phase (transformation T in Fig. 1), one or more YANG modules are mapped into a schema for the conceptual tree that encompasses the entire contents as specified by the YANG modules: tree of configuration and non-configuration data, input and output parts of RPC messages and notifications. 2. In the second phase, the schema for the conceptual tree is transformed to "production" schemas for different NETCONF PDU types that may also take into account other contextual information such as get-config filters or available features. This is accomplished by an array of specialized transformations (T_g, T_e, T_r and T_n in the figure) that will be typically implemented as XSLT stylesheets. +----------------+ | YANG module(s) | +----------------+ | | T | +-----------------+ | DSDL schema for | | conceptual tree | +-----------------+ / | | \ T_g/ T_e| |T_r \T_n / | | \ +----------+ | +---+ +------------+ |get-config| | |rpc| |notification| +----------+ | +---+ +------------+ | +-----------+ |edit-config| +-----------+ The conceptual tree can be schematically represented as follows: ... configuration and status data ... ... ... ... ... ... ... ... ... The first transformation phase (T), described in [ref], maps the logic expressed in YANG modules to the slightly different logic of DSDL schema languages. In contrast, the second phase transformations implement mainly NETCONF rules specified in [RFC4741] and other documents. They will be described in separate documents. -- 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 Oct 15 08:36: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 F266B3A697F; Wed, 15 Oct 2008 08:36: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 1E49828C22E for ; Wed, 15 Oct 2008 08:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, 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 O2Jk7Xy6xeee for ; Wed, 15 Oct 2008 08:36:18 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id E80FE3A67FA for ; Wed, 15 Oct 2008 08:36:17 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9FFbFOx017174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Oct 2008 17:37:15 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9FFbDQr021774; Wed, 15 Oct 2008 17:37:15 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 17:37:06 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 17:37:06 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by FIESEXC015.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 16:17:01 +0300 MIME-Version: 1.0 Received: from demuexc023.nsn-intra.net ([10.150.128.36]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 15:17:00 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 15:16:59 +0200 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 X-OriginalArrivalTime: 15 Oct 2008 13:16:59.0924 (UTC) FILETIME=[4E541540:01C92EC8] Date: Wed, 15 Oct 2008 18:37:02 +0300 Message-ID: <84028E2C0BD7D44F8308A6E7FF659CDB76985A@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [netmod] Additional substatements in groupings Thread-Index: AckuoWL46TiVyKNORxSWELV3LoOt+AAIWO2wAAD7i3A= From: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" To: "NETMOD Working Group" , "ext Balazs Lengyel" X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081015173715-40303BB0-AB9E2A35/0-0/0-15 X-purgate-size: 2577/0 Subject: Re: [netmod] Additional substatements in groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org (Second try - now with correct from- and to address. There were some mail delivery failures. If you have received this mail already, you can ignore the previous one as this contains the same text) Hi, Balazs Lengyel wrote: > Hello, > I wanted to use a grouping as a kind-of complex type. This is really useful for the mapping of one of our CM modeling languages to YANG. > I ran > into the problem that the list of > substatements inside a grouping is rather limited. > Why can't we use the following statements directly under a grouping? > - key (need it !!!) Yes! Otherwise it is impossible to define a reusable grouping that could serve as complete template for defining data nodes, especially lists. > - mandatory Hmm, what about the case where groupings with "mandatory true;" as direct substatement is used inside an augment statement? Shouldn't that be disallowed? > - min-elements (need it !!!) > - max-elements (need it !!!) > - config > - type Need it! > > Generally: > IMHO the main aim of a grouping is to be meaningful and > correct ONCE IT HAS BEEN PUT INTO A USES. > Validation of a grouping itself should only complain about > things, that can in no way be > correct with any kind of uses statement. Absolutely agree! Recently I was prototyping the mapping of a NSN CM modeling language to YANG and also realized that the usability of groupings is substanially impaired by not being able to use key, config, min/max-elements inside the grouping, as this are quite fundamental properties of a data-node. Best wishes, Bernd > That means nearly > all statements could be allowed > inside a grouping with some exceptions e.g. module, submodule. > > All the above statements can perfectly fulfill this > requirement. E.g. the following examples > make perfect sense for me: > > grouping foo { > key id; > leaf id; > } > > list myFooList { > uses foo; > } > > Or if a set of modules all reference the same set of other modules: > > grouping commonImports { > import yang-types {..} > import inet-types {...} > import ieee-types {...} > import ericssonTypes {...} > import ericssonExtensions {...} > import tpsPlatformBaseStuff {...} > } > > module oneOfManyModules { > uses commonImports; > } > > Balazs > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 15 08:50:29 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3653A6C80; Wed, 15 Oct 2008 08:50: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 BDA283A6C7B for ; Wed, 15 Oct 2008 08:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJDX7hg4gySj for ; Wed, 15 Oct 2008 08:50:24 -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 0C3B028C223 for ; Wed, 15 Oct 2008 08:50:21 -0700 (PDT) Received: (qmail 53836 invoked from network); 15 Oct 2008 15:51:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.158.252 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 15 Oct 2008 15:51:01 -0000 X-YMail-OSG: JCH0TUMVM1l3VLTPX6DB1NOcHO3PDxNsRHKKTmUuxOy9fZY8UzX_Yj.qd0DEvOv_nsA699OZbtN4Cd4SQ0yYvI64ZGusKPgQbqWaI9Ojt5gWTiiN8SfCm.La0KELEORNqA6XCAWT1j02FT2eQY0NI2Ea X-Yahoo-Newman-Property: ymail-3 Message-ID: <48F61163.7020305@netconfcentral.com> Date: Wed, 15 Oct 2008 08:50:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Balazs Lengyel References: <48F5ABD8.7030506@ericsson.com> In-Reply-To: <48F5ABD8.7030506@ericsson.com> Cc: NETMOD Working Group Subject: Re: [netmod] Additional substatements in groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > Hello, > I wanted to use a grouping as a kind-of complex type. I ran into the > problem that the list of substatements inside a grouping is rather limited. > Why can't we use the following statements directly under a grouping? I do not agree that this is useful, in relation to the complexity and confusion that can result from treating a grouping as a #define. It impairs readability because important clauses such as the 'key' get hidden, forcing the reader to track down every grouping, look for 'uses' in that grouping, track down that grouping, etc. -- just to find out if a list has a key or not. I prefer to keep groupings the way they are, as a collection of data-def-stmts. Andy > - key (need it !!!) > - mandatory > - min-elements (need it !!!) > - max-elements (need it !!!) > - config > - type > > Generally: > IMHO the main aim of a grouping is to be meaningful and correct ONCE IT > HAS BEEN PUT INTO A USES. > Validation of a grouping itself should only complain about things, that > can in no way be correct with any kind of uses statement. That means > nearly all statements could be allowed inside a grouping with some > exceptions e.g. module, submodule. > > All the above statements can perfectly fulfill this requirement. E.g. > the following examples make perfect sense for me: > > grouping foo { > key id; > leaf id; > } > > list myFooList { > uses foo; > } > > Or if a set of modules all reference the same set of other modules: > > grouping commonImports { > import yang-types {..} > import inet-types {...} > import ieee-types {...} > import ericssonTypes {...} > import ericssonExtensions {...} > import tpsPlatformBaseStuff {...} > } > > module oneOfManyModules { > uses commonImports; > } > > Balazs > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 15 09:11:10 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421BE28C26F; Wed, 15 Oct 2008 09:11:10 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 856AB28C26E for ; Wed, 15 Oct 2008 09:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.236 X-Spam-Level: X-Spam-Status: No, score=-6.236 tagged_above=-999 required=5 tests=[AWL=0.013, 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 GL3w79JOoKj9 for ; Wed, 15 Oct 2008 09:11:07 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 8F7633A68C0 for ; Wed, 15 Oct 2008 09:10:20 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 036BA204B9; Wed, 15 Oct 2008 18:10:26 +0200 (CEST) X-AuditID: c1b4fb3e-aa688bb000007a96-01-48f615f1d520 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D222120060; Wed, 15 Oct 2008 18:10:25 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Oct 2008 18:10:25 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Oct 2008 18:10:25 +0200 Message-ID: <48F615F0.1020502@ericsson.com> Date: Wed, 15 Oct 2008 18:10:24 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <48F5ABD8.7030506@ericsson.com> <48F61163.7020305@netconfcentral.com> In-Reply-To: <48F61163.7020305@netconfcentral.com> X-OriginalArrivalTime: 15 Oct 2008 16:10:25.0233 (UTC) FILETIME=[88603C10:01C92EE0] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] Additional substatements in groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, Andy Bierman wrote: > Balazs Lengyel wrote: >> Hello, >> I wanted to use a grouping as a kind-of complex type. I ran into the >> problem that the list of substatements inside a grouping is rather >> limited. >> Why can't we use the following statements directly under a grouping? > > > I do not agree that this is useful, in relation to > the complexity and confusion that can result from > treating a grouping as a #define. > > It impairs readability because important clauses > such as the 'key' get hidden, forcing the reader > to track down every grouping, look for 'uses' in that > grouping, track down that grouping, etc. -- just to > find out if a list has a key or not. > > I prefer to keep groupings the way they are, as a collection > of data-def-stmts. BALAZS: I think this is completely dependent on the modeling style you use. Maybe "#define" is too strong wording especially considering prefixing issues, but I still believe the substatements of grouping are extremely limited. We should allow key, max/min-elements, config etc. If you use grouping as a kind of complex type, as we are forced to do, as our existing models need that, it is rather counter-intuitive to define a leaf in the grouping, but tell thats it is a key only in uses. > > > Andy > >> - key (need it !!!) >> - mandatory >> - min-elements (need it !!!) >> - max-elements (need it !!!) >> - config >> - type >> >> Generally: >> IMHO the main aim of a grouping is to be meaningful and correct ONCE >> IT HAS BEEN PUT INTO A USES. >> Validation of a grouping itself should only complain about things, >> that can in no way be correct with any kind of uses statement. That >> means nearly all statements could be allowed inside a grouping with >> some exceptions e.g. module, submodule. >> >> All the above statements can perfectly fulfill this requirement. E.g. >> the following examples make perfect sense for me: >> >> grouping foo { >> key id; >> leaf id; >> } >> >> list myFooList { >> uses foo; >> } >> >> Or if a set of modules all reference the same set of other modules: >> >> grouping commonImports { >> import yang-types {..} >> import inet-types {...} >> import ieee-types {...} >> import ericssonTypes {...} >> import ericssonExtensions {...} >> import tpsPlatformBaseStuff {...} } >> >> module oneOfManyModules { >> uses commonImports; >> } >> >> Balazs >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> > > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 15 10:44:55 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7B23A6975; Wed, 15 Oct 2008 10: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 86C1028C229 for ; Wed, 15 Oct 2008 10:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[AWL=0.341, 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 zFx4iN9Lbd97 for ; Wed, 15 Oct 2008 10:44:54 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 292093A6975 for ; Wed, 15 Oct 2008 10:44:54 -0700 (PDT) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 50441D800BD for ; Wed, 15 Oct 2008 19:45:32 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Organization: CESNET Date: Wed, 15 Oct 2008 19:45:32 +0200 Message-Id: <1224092732.15520.13.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [netmod] architecture draft - DSDL X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 a follow-up to our discussion at the interim, I propose the following text for inclusion in the YANG architecture draft, perhaps as a separate section. Comments and suggestions are certainly welcome. Lada ======================================================================== The hierarchical structure, datatypes of nodes and semantics specified in a YANG module have their counterparts in similar (but not identical) structural, datatype and semantical constraints on NETCONF protocol data units (PDU) that are exchanged within a NETCONF session. In [YANG], the implications of YANG constructs and constraints for NETCONF PDUs are explained in plain English and by giving numerous examples. However, as the PDUs are supposed to be the only means of communication between the agent and manager, the ability to formally validate the entire contents of NETCONF PDUs is crucial for verifying that the contract expressed by the YANG module is fulfilled. Since NETCONF PDUs are encoded in XML, it is natural to use XML Schema Languages for their validation. To facilitate this, YANG offers a standardized mapping of YANG modules Document Schema Description Languages (DSDL) [DSDL] that are being developed as the set of international standards ISO/IEC 19757. DSDL are considered to be the best choice for the given purpose because they address not only grammar and datatypes of XML documents but also semantic constraints and rules for modifying information set of the document, such as application of default values. In addition, DSDL offers formal means for coordinating multiple independent schemas and specifying how to apply the schemas to the various parts of the document. This is useful since NETCONF PDUs are typically composed of multiple vocabularies. For example, an edit-config request consists of several nested elements specified in [RFC4741] (, and ) that encapsulate configuration data and, moreover, some configuration data elements may carry "operation" attributes that are again defined in [RFC4741]. Rather than merging the schema of [RFC4741] with that of a particular data model into a new monolithic schema, Namespace-based Validation Dispatching Language (NVDL, part 4 of DSDL) allows for setting up a validation procedure that applies specific schemas to various levels and sections of the XML document. While it is true that some parts of the DSDL set need further development before they can be used in applications, the standard mapping from YANG to DSDL uses only those DSDL parts that already have the status of an ISO/IEC International Standard or are at the stage of a FCD (Final Committee Draft): - Part 2: Regular-grammar-based validation - RELAX NG (ISO/IEC 19757-2:2003) - Part 3: Rule-based validation - Schematron (ISO/IEC 19757-3:2006) - Part 4: Namespace-based Validation Dispatching Language - NVDL (ISO/IEC 19757-4:2006) - Part 8: Document schema renaming language - DSRL (ISO/IEC 19757-8 FCD) For several details of YANG semantics that cannot be adequately represented in the four DSDL schema languages mentioned above, the mapping introduces a small set of new XML attributes that annotate appropriate elements in the RELAX NG schema. In addition, metadata contained in YANG modules such as contact person, organization and revision date are mapped to analogical Dublin Core metadata terms. The mapping of YANG modules to DSDL schemas is further complicated by the inherent variability of NETCONF PDUs. A number of NETCONF RPC methods are defined in [RFC4741] and other RPC methods may be defined by data models. Yet another type of PDUs are asynchronous notifications. Contents of each of these PDU types is constrained in a specific way and in some cases other constraints may follow from the context - for example, contents of a get-config reply depends on filters that may be present in the corresponding get-config request, on available features etc. Last but not least, in order to get a complete schema for a particular NETCONF session, one has to take into account all YANG modules that have been negotiated as capabilities in the hello message. These modules may also be interrelated via the augment statement. In order to cope with this complexity, the mapping procedure is divided into two phases illustrated in the following figure: 1. In the first phase (transformation T in Fig. 1), one or more YANG modules are mapped into a schema for the conceptual tree that encompasses the entire contents as specified by the YANG modules: tree of configuration and non-configuration data, input and output parts of RPC messages and notifications. 2. In the second phase, the schema for the conceptual tree is transformed to "production" schemas for different NETCONF PDU types that may also take into account other contextual information such as get-config filters or available features. This is accomplished by an array of specialized transformations (T_g, T_e, T_r and T_n in the figure) that will be typically implemented as XSLT stylesheets. +----------------+ | YANG module(s) | +----------------+ | | T | +-----------------+ | DSDL schema for | | conceptual tree | +-----------------+ / | | \ T_g/ T_e| |T_r \T_n / | | \ +----------+ | +---+ +------------+ |get-config| | |rpc| |notification| +----------+ | +---+ +------------+ | +-----------+ |edit-config| +-----------+ The conceptual tree can be schematically represented as follows: ... configuration and status data ... ... ... ... ... ... ... ... ... The first transformation phase (T), described in [ref], maps the logic expressed in YANG modules to the slightly different logic of DSDL schema languages. In contrast, the second phase transformations implement mainly NETCONF rules specified in [RFC4741] and other documents. They will be described in separate documents. -- 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 Oct 15 11:21:25 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88B9C3A6893; Wed, 15 Oct 2008 11:21:25 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 560843A692F for ; Wed, 15 Oct 2008 11:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+5YSEjf5DlR for ; Wed, 15 Oct 2008 11:21:23 -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 7AA3C3A67A8 for ; Wed, 15 Oct 2008 11:21:23 -0700 (PDT) Received: (qmail 10593 invoked from network); 15 Oct 2008 18:22:23 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.158.252 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 15 Oct 2008 18:22:21 -0000 X-YMail-OSG: Jum6JNsVM1nqFMKLyS_MVQ4PmE3Hu4YZ1YDEU6pZvPhRMyyVdq1E6odM3mrPFzb5eT3xAl7YtnYbZdvl_8kbTxjKaA0NGFOj1FtNBTpr_Tbh86Nna4ffYU2a0rUOOKOv.clmWjia5emCwE0LGA50wZTa X-Yahoo-Newman-Property: ymail-3 Message-ID: <48F634DC.9050809@netconfcentral.com> Date: Wed, 15 Oct 2008 11:22:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Balazs Lengyel References: <48F5ABD8.7030506@ericsson.com> <48F61163.7020305@netconfcentral.com> <48F615F0.1020502@ericsson.com> In-Reply-To: <48F615F0.1020502@ericsson.com> Cc: NETMOD Working Group Subject: Re: [netmod] Additional substatements in groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > Hello, > > Andy Bierman wrote: >> Balazs Lengyel wrote: >>> Hello, >>> I wanted to use a grouping as a kind-of complex type. I ran into the >>> problem that the list of substatements inside a grouping is rather >>> limited. >>> Why can't we use the following statements directly under a grouping? >> >> >> I do not agree that this is useful, in relation to >> the complexity and confusion that can result from >> treating a grouping as a #define. >> >> It impairs readability because important clauses >> such as the 'key' get hidden, forcing the reader >> to track down every grouping, look for 'uses' in that >> grouping, track down that grouping, etc. -- just to >> find out if a list has a key or not. >> >> I prefer to keep groupings the way they are, as a collection >> of data-def-stmts. > BALAZS: I think this is completely dependent on the modeling style you use. > Maybe "#define" is too strong wording especially considering prefixing > issues, but I still believe the substatements of grouping are extremely > limited. We should allow key, max/min-elements, config etc. > If you use grouping as a kind of complex type, as we are forced to do, > as our existing models need that, it is rather counter-intuitive to > define a leaf in the grouping, but tell thats it is a key only in uses. >> >> But YANG doesn't have complex types like XSD. It is not object-oriented either. IMO, features like this should be done with extensions, because they make YANG too complicated to use for many people. BTW, you cannot change the key within a uses-stmt: refine-list-stmt = list-keyword sep identifier-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order *(must-stmt stmtsep) [config-stmt stmtsep] [min-elements-stmt stmtsep] [max-elements-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep] *(refinement-stmt stmtsep) "}") YANG is intentionally simple, especially wrt/ inline definitions like list, container, and choice. It is a long-standing IETF NM area tradition to optimize for interoperability and readability, over data modeling complexity. SMIv2 is too simple, and now YANG is getting too complicated. >> Andy Andy >> >>> - key (need it !!!) >>> - mandatory >>> - min-elements (need it !!!) >>> - max-elements (need it !!!) >>> - config >>> - type >>> >>> Generally: >>> IMHO the main aim of a grouping is to be meaningful and correct ONCE >>> IT HAS BEEN PUT INTO A USES. >>> Validation of a grouping itself should only complain about things, >>> that can in no way be correct with any kind of uses statement. That >>> means nearly all statements could be allowed inside a grouping with >>> some exceptions e.g. module, submodule. >>> >>> All the above statements can perfectly fulfill this requirement. E.g. >>> the following examples make perfect sense for me: >>> >>> grouping foo { >>> key id; >>> leaf id; >>> } >>> >>> list myFooList { >>> uses foo; >>> } >>> >>> Or if a set of modules all reference the same set of other modules: >>> >>> grouping commonImports { >>> import yang-types {..} >>> import inet-types {...} >>> import ieee-types {...} >>> import ericssonTypes {...} >>> import ericssonExtensions {...} >>> import tpsPlatformBaseStuff {...} } >>> >>> module oneOfManyModules { >>> uses commonImports; >>> } >>> >>> Balazs >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> >>> >> >> > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 15 11:50:22 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EF0D3A6A14; Wed, 15 Oct 2008 11:50:22 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E35093A6A18 for ; Wed, 15 Oct 2008 11:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AYLyiJNhmkH for ; Wed, 15 Oct 2008 11:50:20 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F05FA3A6A14 for ; Wed, 15 Oct 2008 11:50:19 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 17206C0015 for ; Wed, 15 Oct 2008 20:51:17 +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 vngzch1ITfsP; Wed, 15 Oct 2008 20:51:10 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A922C007C; Wed, 15 Oct 2008 20:51:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6275C808E8E; Wed, 15 Oct 2008 20:51:09 +0200 (CEST) Date: Wed, 15 Oct 2008 20:51:09 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20081015185109.GB4819@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [netmod] creeping featurism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, it seems NETMOD is suffering from creeping featurism and I like to request that the chairs consider ways to handle this. I believe we need NETMOD 1.0 and not 3.0. One option could be that we do a feature freeze and for any feature added to the language, some other feature needs to be removed. /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 Oct 15 13:15: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 86BC03A68D5; Wed, 15 Oct 2008 13:15: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 D7ACF28C0DD for ; Wed, 15 Oct 2008 13:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.308, 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 rXZ7tPT3MMlH for ; Wed, 15 Oct 2008 13:15:04 -0700 (PDT) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id BC66D3A68F8 for ; Wed, 15 Oct 2008 13:15:03 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA08.westchester.pa.mail.comcast.net with comcast id T54m1a00J1HzFnQ588Fl1k; Wed, 15 Oct 2008 20:15:45 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.westchester.pa.mail.comcast.net with comcast id T8Fq1a00V4HwxpC3a8FrhH; Wed, 15 Oct 2008 20:15:51 +0000 X-Authority-Analysis: v=1.0 c=1 a=cL9Ex25eRQAA:10 a=SSmOFEACAAAA:8 a=A1X0JdhQAAAA:8 a=QYeuQFWgK7i9Xfy3RM8A:9 a=M7ipqVOBleEC-ffFURYA:7 a=VDYu3qOhDMYhwGG9bjlqxwEFb3cA:4 a=YewFc9KQ5U8A:10 a=8b0TY1xhFYQA:10 From: "David Harrington" To: Date: Wed, 15 Oct 2008 16:15:50 -0400 Message-ID: <028101c92f02$d1b2b600$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acku+EwVSZ0zoXr7Te2XZp1bkD4/KgACmLCQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [netmod] FW: Request for help with a NETMOD question X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Can somebody remind me why we are not using XPath 2.0? Would that resolve this issue satisfactorily? dbh -----Original Message----- From: Lisa Dusseault [mailto:lisa@osafoundation.org] Sent: Wednesday, October 15, 2008 3:00 PM To: David Partain Cc: Chris Newman; David Harrington; Dan Romascanu; Ron Bonica Subject: Re: Request for help with a NETMOD question I have no idea what the answer is myself. I do note that the XSLT spec you reference ten years old. Have you tried looking at XPath 2.0 and its errata? http://www.w3.org/TR/2007/WD-xpath-full-text-10-20070518/ So, looking around for who could help you, I don't know anybody with XPath expertise. Frustratingly, at the W3 web site, I can't find out who is active in XML/XSL at this time -- the XSL WG page is readable to members only. The XPath spec does list contributors, so there's a bunch of names of experts there. I don't know any of them. We could certainly route a query through the IETF's W3C liaison if you'd like. That could work but it could be slow. Lisa On Oct 15, 2008, at 1:11 AM, David Partain wrote: > Greetings, > > A question has been raised in the NETMOD Working Group about the way > the > current YANG draft defines the context in which XPath expressions are > evaluated. > > YANG defines data models using constructs like "leaf"s and > "container"s. > Constraints are defined using "must" expressions, which use the > XPath 1.0 > syntax. For example, this snippet defines a container whose "max" > cannot > exceed the "min": > > module test-case { > namespace http://example.com/yang/test-case; > prefix tc; > > container limits { > must "min < max"; > leaf min { type uint32; } > leaf max { type uint32; } > } > } > > The "must" expression is defined as being evaluated in a context > where the > current module is the null namespace, so unqualified nodes refer to > the > locally defined nodes. > > This allows a natural syntax where the "must" statement uses the same > unqualified syntax as other YANG statements like the "leaf" statement. > > The question is whether this definition of the null namespace > constitutes > breaking the rules defined in XPath 1.0. XPath allows standards > such as XSLT > and XPointer to define such a context. For example, see the rules > for XSLT > contexts in section 4 of the XSLT spec: > > http://www.w3.org/TR/xslt.html#section-Expressions > > The XSLT spec specifically calls out the default namespace as not > being > carried into the context, meaning the default namespace is always > the null > namespace. > > XPath 2.0 allows the default namespace to be set, addressing this > issue. > > XML-PATCH-OPS (RFC 5261) defines their expressions as namespace- > agnostic, > allowing unqualified nodes to match nodes regardless of the > namespace. This > is covered in the section "Departures from XPath > Requirements" (section > 4.2.2). > > So the question is: does defining the context to include the null > namespace as > being the current module violate XPath 1.0? > > We would be grateful if you could provide some guidance or point us > in the > direction of those who can. > > Thanks very much. > > David and David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 15 13:30: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 4C2A23A690E; Wed, 15 Oct 2008 13:30: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 213B53A68F8 for ; Wed, 15 Oct 2008 13:30:19 -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 UT7Wt0d8b+A0 for ; Wed, 15 Oct 2008 13:30:18 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 576F83A690E for ; Wed, 15 Oct 2008 13:30:18 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Wed, 15 Oct 2008 13:30:10 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, 15 Oct 2008 13:31:05 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 13:31:05 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 13:31:04 -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 m9FKV4M44947; Wed, 15 Oct 2008 13:31:04 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m9FKQcDu050432; Wed, 15 Oct 2008 20:26:39 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200810152026.m9FKQcDu050432@idle.juniper.net> To: "David Harrington" In-reply-to: <028101c92f02$d1b2b600$0600a8c0@china.huawei.com> Date: Wed, 15 Oct 2008 16:26:38 -0400 From: Phil Shafer X-OriginalArrivalTime: 15 Oct 2008 20:31:04.0605 (UTC) FILETIME=[F22B04D0:01C92F04] Cc: netmod@ietf.org Subject: Re: [netmod] FW: Request for help with a NETMOD question X-BeenThere: netmod@ietf.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: >Can somebody remind me why we are not using XPath 2.0? XPath 2.0 increased the size of both the spec and implementation by at least double. Saxon (Java) is the only implementation IFAIK. The libxml2 folks see no value to xpath 2.0 and there's no interest in implementing it. libxml2 is the engine used in C, Perl, PHP, Python, and other languages. So mandating 2.0 means mandating Java, which is a non-starter. XPath 1.0 is a subset of 2.0, so we can move forward when and if the marketplace moves to 2.0. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 15 14:12: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 6DCA23A6C23; Wed, 15 Oct 2008 14:12: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 D6EAA28C158 for ; Wed, 15 Oct 2008 14:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 k4OUk4XmgDFM for ; Wed, 15 Oct 2008 14:12:36 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 3DFF43A6C92 for ; Wed, 15 Oct 2008 14:12:35 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Wed, 15 Oct 2008 14:13:18 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 14:11:20 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 14:11:20 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Oct 2008 14:11: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 m9FLBIM67551; Wed, 15 Oct 2008 14:11: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 m9FL6r2n050790; Wed, 15 Oct 2008 21:06:53 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200810152106.m9FL6r2n050790@idle.juniper.net> To: Ladislav Lhotka In-reply-to: <1224092732.15520.13.camel@missotis> Date: Wed, 15 Oct 2008 17:06:53 -0400 From: Phil Shafer X-OriginalArrivalTime: 15 Oct 2008 21:11:19.0245 (UTC) FILETIME=[9167D7D0:01C92F0A] Cc: NETMOD Working Group Subject: Re: [netmod] architecture draft - DSDL X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka writes: >as a follow-up to our discussion at the interim, I propose the following >text for inclusion in the YANG architecture draft, perhaps as a separate >section. Comments and suggestions are certainly welcome. Three points of contention: (a) The implication that DSDL is needed for the YANG spec is incorrect. The YANG spec needs to stand on its own, even if the constraints are in "plain English". The spec must articulate these contraints in a "stand alone" manner. (b) The claim that DSDL is needed to validate YANG PDUs is incorrect. When YANG-based validation software is available, the need to generate DSDL will disappear. You only need DSDL files if you use DSDL for validation; if you can validate directly based on the YANG modules, you don't need them. (c) The concentration on PDUs is unfortunate. As we discussed at the interim, there are three places where validation is needed. (1) rpc input (did you send me the right stuff?) (2) rpc output (did I send you the right stuff?) (3) database contents (do I have the right stuff?) PDUs cover (1) and (2), but not (3). In selling us on DSDL, Rohan implied that the same schema file could support all three scenarios. > DSDL are considered to be the best choice for the given purpose > because they address not only grammar and datatypes of XML > documents but also semantic constraints and rules for modifying > information set of the document, such as application of default > values. Does XSD not do default values? > - Part 2: Regular-grammar-based validation - RELAX NG > (ISO/IEC 19757-2:2003) > - Part 3: Rule-based validation - Schematron (ISO/IEC 19757-3:2006) > - Part 4: Namespace-based Validation Dispatching Language - NVDL > (ISO/IEC 19757-4:2006) > - Part 8: Document schema renaming language - DSRL > (ISO/IEC 19757-8 FCD) I thought we only needed 2 and 3. What are 4 and 8 and why do we need them? Are implementations available? Looks like part 8 went out for review last December. dsdl.org lists it as a draft, but their copy of the draft is older than the one sent out in December. Do you know the current status? Are we comfortable with our depth of knowledge in these technologies? The rest of this material is not appropriate for an architecture document. We need only the high level view. I'd skip the earlier "best choice" part, since we need only say what we are doing. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 15 14: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 976353A685F; Wed, 15 Oct 2008 14: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 585443A685F for ; Wed, 15 Oct 2008 14:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isJaoKCoNg0n for ; Wed, 15 Oct 2008 14:51:54 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 4F3D53A67FC for ; Wed, 15 Oct 2008 14:51:54 -0700 (PDT) Received: (qmail 47300 invoked from network); 15 Oct 2008 21:52:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.158.252 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 15 Oct 2008 21:52:52 -0000 X-YMail-OSG: 2.rB958VM1l2BMX0JMo33rY3kZom39646q8vCsjcXyeG4_lpLyXJfOVpiEhizb0lThjhHBUPC2RrNrxDHN6_E_JMyA20AWYfpZvfh3zOwMk9D6HagwdfQbzFvGn8pCmoUDIylzkotYLBADasKqXIesSc X-Yahoo-Newman-Property: ymail-3 Message-ID: <48F66633.9000301@netconfcentral.com> Date: Wed, 15 Oct 2008 14:52:51 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Phil Shafer References: <200810152106.m9FL6r2n050790@idle.juniper.net> In-Reply-To: <200810152106.m9FL6r2n050790@idle.juniper.net> Cc: NETMOD Working Group Subject: Re: [netmod] architecture draft - DSDL X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > Ladislav Lhotka writes: >> as a follow-up to our discussion at the interim, I propose the following >> text for inclusion in the YANG architecture draft, perhaps as a separate >> section. Comments and suggestions are certainly welcome. > > Three points of contention: > > (a) The implication that DSDL is needed for the YANG spec is > incorrect. The YANG spec needs to stand on its own, even if the > constraints are in "plain English". The spec must articulate these > contraints in a "stand alone" manner. > > (b) The claim that DSDL is needed to validate YANG PDUs is incorrect. > When YANG-based validation software is available, the need to > generate DSDL will disappear. You only need DSDL files if you use > DSDL for validation; if you can validate directly based on the > YANG modules, you don't need them. > > (c) The concentration on PDUs is unfortunate. As we discussed at > the interim, there are three places where validation is needed. > > (1) rpc input (did you send me the right stuff?) > (2) rpc output (did I send you the right stuff?) > (3) database contents (do I have the right stuff?) > > PDUs cover (1) and (2), but not (3). In selling us on DSDL, Rohan > implied that the same schema file could support all three scenarios. > 4 scenarios: (4) notification content I agree 100% that DSDL based validation is just one implementation choice, and validation is just one task among many that can be performed on a YANG file. A NETCONF manager or agent implementation is not required to use any particular DML, or any at all. Maybe the DM content support is hard-wired, and there are no YANG or DSDL files anywhere near the implementation. If the agent supports the NETCONF operations on the particular data model content associated with module 'foo', then the manager should not care how the agent figured out how to send the correct responses. Isn't the DSDL mapping supposed to be an Informational RFC? Andy >> DSDL are considered to be the best choice for the given purpose >> because they address not only grammar and datatypes of XML >> documents but also semantic constraints and rules for modifying >> information set of the document, such as application of default >> values. > > Does XSD not do default values? > >> - Part 2: Regular-grammar-based validation - RELAX NG >> (ISO/IEC 19757-2:2003) >> - Part 3: Rule-based validation - Schematron (ISO/IEC 19757-3:2006) >> - Part 4: Namespace-based Validation Dispatching Language - NVDL >> (ISO/IEC 19757-4:2006) >> - Part 8: Document schema renaming language - DSRL >> (ISO/IEC 19757-8 FCD) > > I thought we only needed 2 and 3. What are 4 and 8 and why > do we need them? Are implementations available? > > Looks like part 8 went out for review last December. dsdl.org > lists it as a draft, but their copy of the draft is older than > the one sent out in December. Do you know the current status? > > Are we comfortable with our depth of knowledge in these technologies? > > The rest of this material is not appropriate for an architecture > document. We need only the high level view. I'd skip the earlier > "best choice" part, since we need only say what we are doing. > > 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 Thu Oct 16 00:57: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 CE0983A6ACC; Thu, 16 Oct 2008 00:57: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 70FBF3A6B4C for ; Thu, 16 Oct 2008 00:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOyNrjJeKuJy for ; Thu, 16 Oct 2008 00:57:05 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 0A9C93A6B37 for ; Thu, 16 Oct 2008 00:57:04 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id C3E5BD800BD; Thu, 16 Oct 2008 09:57:55 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <200810152106.m9FL6r2n050790@idle.juniper.net> References: <200810152106.m9FL6r2n050790@idle.juniper.net> Organization: CESNET Date: Thu, 16 Oct 2008 09:57:55 +0200 Message-Id: <1224143875.8409.53.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: NETMOD Working Group Subject: Re: [netmod] architecture draft - DSDL X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 UGhpbCBTaGFmZXIgcMOtxaFlIHYgU3QgMTUuIDEwLiAyMDA4IHYgMTc6MDYgLTA0MDA6Cj4gTGFk aXNsYXYgTGhvdGthIHdyaXRlczoKPiA+YXMgYSBmb2xsb3ctdXAgdG8gb3VyIGRpc2N1c3Npb24g YXQgdGhlIGludGVyaW0sIEkgcHJvcG9zZSB0aGUgZm9sbG93aW5nCj4gPnRleHQgZm9yIGluY2x1 c2lvbiBpbiB0aGUgWUFORyBhcmNoaXRlY3R1cmUgZHJhZnQsIHBlcmhhcHMgYXMgYSBzZXBhcmF0 ZQo+ID5zZWN0aW9uLiBDb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIGNlcnRhaW5seSB3ZWxj b21lLgo+IAo+IFRocmVlIHBvaW50cyBvZiBjb250ZW50aW9uOgo+IAo+IChhKSBUaGUgaW1wbGlj YXRpb24gdGhhdCBEU0RMIGlzIG5lZWRlZCBmb3IgdGhlIFlBTkcgc3BlYyBpcwo+IGluY29ycmVj dC4gIFRoZSBZQU5HIHNwZWMgbmVlZHMgdG8gc3RhbmQgb24gaXRzIG93biwgZXZlbiBpZiB0aGUK PiBjb25zdHJhaW50cyBhcmUgaW4gInBsYWluIEVuZ2xpc2giLiAgVGhlIHNwZWMgbXVzdCBhcnRp Y3VsYXRlIHRoZXNlCj4gY29udHJhaW50cyBpbiBhICJzdGFuZCBhbG9uZSIgbWFubmVyLgoKSSBh Z3JlZSwgYnV0IHN0aWxsIEkgY2xhaW0gaXQncyBpbXBvcnRhbnQgdG8gYmUgYWJsZSB0byBkbyBm b3JtYWwKdmFsaWRhdGlvbi4gVGhlIHNwZWMgYWxzbyBleHBsYWlucyBZQU5HIHN5bnRheCBpbiBw bGFpbiBFbmdsaXNoIGJ1dCBhbnkKaW1wbGVtZW50b3Igd2lsbCBwZXJ1c2UgdGhlIEFCTkYgcXVp dGUgb2Z0ZW4sIHRvby4gVGhlIHByb2JsZW0gd2l0aApZQU5HLT5QRFUgbWFwcGluZyBpcyB0aGF0 IHRoZXJlIGlzIG5vIGZvcm1hbCBsYW5ndWFnZSBmb3Igd3JpdGluZyBkb3duCnRoZSBtYXBwaW5n IHJ1bGVzIGFzIEFCTkYgZG9lcyBmb3IgY29udGV4dC1mcmVlIGdyYW1tYXJzLCBzbyBoYXZpbmcg aXQKaW4gdGhlIHNhbWUgc3BlYyBpc24ndCByZWFsbHkgYW4gb3B0aW9uLgoKPiAKPiAoYikgVGhl IGNsYWltIHRoYXQgRFNETCBpcyBuZWVkZWQgdG8gdmFsaWRhdGUgWUFORyBQRFVzIGlzIGluY29y cmVjdC4KCldoZXJlIGRpZCBJIHNheSB0aGF0PyBJIG9ubHkgc2FpZCB0aGlzOiAiU2luY2UgTkVU Q09ORiBQRFVzIGFyZSBlbmNvZGVkCmluIFhNTCwgaXQgaXMgbmF0dXJhbCB0byB1c2UgWE1MIFNj aGVtYSBMYW5ndWFnZXMgZm9yIHRoZWlyCnZhbGlkYXRpb24uIiAoQWN0dWFsbHksICJzY2hlbWEg bGFuZ3VhZ2VzIiBzaG91bGRuJ3QgYmUgY2FwaXRhbGl6ZWQKaGVyZSkuCgo+IFdoZW4gWUFORy1i YXNlZCB2YWxpZGF0aW9uIHNvZnR3YXJlIGlzIGF2YWlsYWJsZSwgdGhlIG5lZWQgdG8KCkFGQUlL LCB0aGVyZSBpcyBubyBzdWNoIHRoaW5nIGluIHNpZ2h0LCBhbmQgSSB0aGluayBpdCB3b3VsZCBi ZSB3YXN0ZSBvZgp0aW1lLiBUaGUgZXhpc3Rpbmcgc2NoZW1hIGxhbmd1YWdlcyBhbmQgdmFsaWRh dGluZyBzb2Z0d2FyZSBhcmUgZ29vZAplbm91Z2ggZm9yIHRoaXMgdGFzay4KCj4gZ2VuZXJhdGUg RFNETCB3aWxsIGRpc2FwcGVhci4gIFlvdSBvbmx5IG5lZWQgRFNETCBmaWxlcyBpZiB5b3UgdXNl Cj4gRFNETCBmb3IgdmFsaWRhdGlvbjsgIGlmIHlvdSBjYW4gdmFsaWRhdGUgZGlyZWN0bHkgYmFz ZWQgb24gdGhlCj4gWUFORyBtb2R1bGVzLCB5b3UgZG9uJ3QgbmVlZCB0aGVtLgo+IAo+IChjKSBU aGUgY29uY2VudHJhdGlvbiBvbiBQRFVzIGlzIHVuZm9ydHVuYXRlLiAgQXMgd2UgZGlzY3Vzc2Vk IGF0Cj4gdGhlIGludGVyaW0sIHRoZXJlIGFyZSB0aHJlZSBwbGFjZXMgd2hlcmUgdmFsaWRhdGlv biBpcyBuZWVkZWQuCj4gCj4gICAgKDEpIHJwYyBpbnB1dCAoZGlkIHlvdSBzZW5kIG1lIHRoZSBy aWdodCBzdHVmZj8pCj4gICAgKDIpIHJwYyBvdXRwdXQgKGRpZCBJIHNlbmQgeW91IHRoZSByaWdo dCBzdHVmZj8pCj4gICAgKDMpIGRhdGFiYXNlIGNvbnRlbnRzIChkbyBJIGhhdmUgdGhlIHJpZ2h0 IHN0dWZmPykKPiAKPiBQRFVzIGNvdmVyICgxKSBhbmQgKDIpLCBidXQgbm90ICgzKS4gIEluIHNl bGxpbmcgdXMgb24gRFNETCwgUm9oYW4KPiBpbXBsaWVkIHRoYXQgdGhlIHNhbWUgc2NoZW1hIGZp bGUgY291bGQgc3VwcG9ydCBhbGwgdGhyZWUgc2NlbmFyaW9zLgoKVGhlIHNjaGVtYXMgdGhhdCBy ZXN1bHQgZnJvbSB0aGUgc2Vjb25kIHBoYXNlIG9mIHRoZSBtYXBwaW5nIG1heSBoYXZlIGEKZGlm ZmVyZW50IHN0cnVjdHVyZSAtIHRoZSBmaWd1cmUgaXMganVzdCBhbiBleGFtcGxlLiBPbmUgb3B0 aW9uIGlzIHRvCmhhdmUgYWxsIGNsaWVudCBQRFVzIGluIG9uZSBzY2hlbWEgKGV4Y2VwdCBoZWxs bykgYW5kIHRoZW4gYWxsIHNlcnZlcgpycGMtcmVwbHkgbWVzc2FnZXMgaW4gYW5vdGhlciBhbmQg bm90aWZpY2F0aW9ucyBpbiB5ZXQgYW5vdGhlci4gQW55CmlkZWFzPwoKSG93ZXZlciwgSSBkbyBo YXZlIHByb2JsZW1zIHdpdGggImRhdGFiYXNlIGNvbnRlbnRzIHZhbGlkYXRpb24iIHNpbmNlIGl0 CmlzIG5vdCBjbGVhciB3aGF0IGEgY29uZmlndXJhdGlvbiBkYXRhYmFzZSBpcyAtIHdoYXQgaXRz IGluZm9ybWF0aW9uCm1vZGVsIGlzIGV0Yy4KCkkgYW0gYWxzbyBub3Qgc2F5aW5nIHRoYXQgUERV IHZhbGlkYXRpb24gY292ZXJzIGV2ZXJ5dGhpbmcsIGp1c3QgdGhhdCBpdAppcyBhbiBpbXBvcnRh bnQgc3RlcCBpbiB0aGUgdmFsaWRhdGlvbiBwcm9jZXNzLgoKPiAKPiA+ICAgRFNETCBhcmUgY29u c2lkZXJlZCB0byBiZSB0aGUgYmVzdCBjaG9pY2UgZm9yIHRoZSBnaXZlbiBwdXJwb3NlCj4gPiAg IGJlY2F1c2UgdGhleSBhZGRyZXNzIG5vdCBvbmx5IGdyYW1tYXIgYW5kIGRhdGF0eXBlcyBvZiBY TUwKPiA+ICAgZG9jdW1lbnRzIGJ1dCBhbHNvIHNlbWFudGljIGNvbnN0cmFpbnRzIGFuZCBydWxl cyBmb3IgbW9kaWZ5aW5nCj4gPiAgIGluZm9ybWF0aW9uIHNldCBvZiB0aGUgZG9jdW1lbnQsIHN1 Y2ggYXMgYXBwbGljYXRpb24gb2YgZGVmYXVsdAo+ID4gICB2YWx1ZXMuCj4gCj4gRG9lcyBYU0Qg bm90IGRvIGRlZmF1bHQgdmFsdWVzPwoKSXQgc3VyZSBkb2VzLgoKPiAKPiA+ICAgLSBQYXJ0IDI6 IFJlZ3VsYXItZ3JhbW1hci1iYXNlZCB2YWxpZGF0aW9uIC0gUkVMQVggTkcKPiA+ICAgICAoSVNP L0lFQyAxOTc1Ny0yOjIwMDMpCj4gPiAgIC0gUGFydCAzOiBSdWxlLWJhc2VkIHZhbGlkYXRpb24g LSBTY2hlbWF0cm9uIChJU08vSUVDIDE5NzU3LTM6MjAwNikKPiA+ICAgLSBQYXJ0IDQ6IE5hbWVz cGFjZS1iYXNlZCBWYWxpZGF0aW9uIERpc3BhdGNoaW5nIExhbmd1YWdlIC0gTlZETAo+ID4gICAg IChJU08vSUVDIDE5NzU3LTQ6MjAwNikKPiA+ICAgLSBQYXJ0IDg6IERvY3VtZW50IHNjaGVtYSBy ZW5hbWluZyBsYW5ndWFnZSAtIERTUkwKPiA+ICAgICAoSVNPL0lFQyAxOTc1Ny04IEZDRCkKPiAK PiBJIHRob3VnaHQgd2Ugb25seSBuZWVkZWQgMiBhbmQgMy4gIFdoYXQgYXJlIDQgYW5kIDggYW5k IHdoeQo+IGRvIHdlIG5lZWQgdGhlbT8gIEFyZSBpbXBsZW1lbnRhdGlvbnMgYXZhaWxhYmxlPwoK UGFydCA0IHdpbGwgb25seSBhcHBlYXIgaW4gcGhhc2UgMiBzY2hlbWFzLiBJIGFtIGF3YXJlIG9m IHR3bwppbXBsZW1lbnRhdGlvbnM6Ci0gaHR0cDovL3d3dy5veHlnZW54bWwuY29tL29udmRsLmh0 bWwKLSBodHRwOi8vam52ZGwuc291cmNlZm9yZ2UubmV0LwoKUGFydCA4IGlzIHVzZWQgb25seSBm b3Igc3BlY2lmeWluZyBkZWZhdWx0IHZhbHVlcy4gVGhlcmUgaXMgYW4KWFNMVC1iYXNlZCBpbXBs ZW1lbnRhdGlvbiwgYnV0IGluIGZhY3QgaW1wbGVtZW50aW5nIGluc2VydGlvbiBvZgpkZWZhdWx0 cyB3aGVuIHRoZXkgYXJlIG1pc3NpbmcgaXMgdHJpdmlhbC4KCj4gCj4gTG9va3MgbGlrZSBwYXJ0 IDggd2VudCBvdXQgZm9yIHJldmlldyBsYXN0IERlY2VtYmVyLiAgZHNkbC5vcmcKPiBsaXN0cyBp dCBhcyBhIGRyYWZ0LCBidXQgdGhlaXIgY29weSBvZiB0aGUgZHJhZnQgaXMgb2xkZXIgdGhhbgo+ IHRoZSBvbmUgc2VudCBvdXQgaW4gRGVjZW1iZXIuICBEbyB5b3Uga25vdyB0aGUgY3VycmVudCBz dGF0dXM/CgpUaGUgc2Vjb25kIGRyYWZ0IHRoYXQgeW91IG1lbnRpb24gaGFzIGJlZW4gYXBwcm92 ZWQgZml2ZSB3ZWVrcyBhZ286Cmh0dHA6Ly9icm9hZGNhc3Qub3JlaWxseS5jb20vMjAwOC8wOS9k c3JsLWEtbmV3LXN0YW5kYXJkLXRoYXQtY2FuLXIuaHRtbAoKPiAKPiBBcmUgd2UgY29tZm9ydGFi bGUgd2l0aCBvdXIgZGVwdGggb2Yga25vd2xlZGdlIGluIHRoZXNlIHRlY2hub2xvZ2llcz8KCkFz IEkgc2FpZCwganVzdCBkZWFsaW5nIHdpdGggZGVmYXVsdHMgaXMgbm8gcm9ja2V0IHNjaWVuY2Uu Cgo+IAo+IFRoZSByZXN0IG9mIHRoaXMgbWF0ZXJpYWwgaXMgbm90IGFwcHJvcHJpYXRlIGZvciBh biBhcmNoaXRlY3R1cmUKPiBkb2N1bWVudC4gIFdlIG5lZWQgb25seSB0aGUgaGlnaCBsZXZlbCB2 aWV3LiAgSSdkIHNraXAgdGhlIGVhcmxpZXIKPiAiYmVzdCBjaG9pY2UiIHBhcnQsIHNpbmNlIHdl IG5lZWQgb25seSBzYXkgd2hhdCB3ZSBhcmUgZG9pbmcuCgpTdXJlLCBzZWxlY3Qgd2hhdCB5b3Ug bGlrZSwgdGhlIHJlc3Qgd2lsbCBhcHBlYXIgaW4gdGhlIERTREwgZHJhZnQuCgpMYWRhCgotLSAK TGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDogRTc0RThDMEMKCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QK bmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 bW9kCg== From netmod-bounces@ietf.org Thu Oct 16 08: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 13C303A63D3; Thu, 16 Oct 2008 08: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 1D2413A680A for ; Thu, 16 Oct 2008 08:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=1.200, 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 1kcn5Y3fC6E9 for ; Thu, 16 Oct 2008 08:42:04 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 041713A63D3 for ; Thu, 16 Oct 2008 08:42:03 -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 m9GFh4ZD025130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 16 Oct 2008 17:43:04 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9GFh239002463 for ; Thu, 16 Oct 2008 17:43:04 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Oct 2008 17:43:02 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Oct 2008 17:42:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Oct 2008 18:42:03 +0300 Message-ID: <84028E2C0BD7D44F8308A6E7FF659CDB769EA0@FIESEXC015.nsn-intra.net> In-Reply-To: <48F0FEBA.4050109@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] methods and events Thread-Index: Ackr18YvaTosFl/LQ+6eJ65c+atOWQDw0EzQ References: <48F0E1C9.1020308@netconfcentral.com> <48F0FEBA.4050109@netconfcentral.com> From: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" To: "NETMOD Working Group" X-OriginalArrivalTime: 16 Oct 2008 15:42:40.0574 (UTC) FILETIME=[D2932DE0:01C92FA5] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081016174304-40301BB0-01006A30/0-0/0-15 X-purgate-size: 2430/0 Subject: Re: [netmod] methods and events X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, first, I think it is a good idea to put methods (or "actions") inside (local to) data nodes as it makes much more obvious to which part of the tree the method is applied. In my opinion, having the method target ("self" parameter) as implicit parameter and being able to add additional parameters as needed in the context at hand is enough. More complex mechanisms like signatures might turn out to be hard to understand and use correctly. What is not clear to me is - how is the output / result of an method invocation specified? - can methods statements be augmented? Would it be allowed to add additional, optional parameters? - can new methods itself be augmented? So would it be allowed to augment a method to lists and containers? Best wishes, Bernd Andy Bierman wrote: > >.... >> A method signature template will be needed, so it can be >> automated instead of hard-wired: >> >> signature simple-rpc { >> leaf callingPoint { >> type instance-identifier; >> } >> } >> > > In case this part isn't obvious: > > module yang { > > signature from-to-rpc { > leaf from { > type instance-identifier; > } > leaf to { > type instance-identifier; > } > } > } > > module X { > > import yang { prefix yang; } > > import acme { prefix acme; } > > list Y { > ... > method copy { > method-type yang:from-to-rpc; > // add extra copy-specific details > } > > method move { > method-type yang:from-to-rpc; > // add extra move-specific details > } > > method foo { > method-type acme:my-rpc-signature; > // add foo-specific details > } > } > } > > I think this helps address the very valid concern that Phil raised > at the interim about one simplistic template not being > being sufficient. > > Or am I totally missing the point, and there is no need > for method signatures (or templates) because all you > really want is the 'self' parameter added to > the rpc automatically? (Balazs?) > > > > > > > > Comments? > > > > > > Andy > > > > > 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 Thu Oct 16 09:55:54 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03F103A6805; Thu, 16 Oct 2008 09:55:54 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672B63A682B for ; Thu, 16 Oct 2008 09:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gqsn8SakT-Vc for ; Thu, 16 Oct 2008 09:55:51 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id B7C713A6805 for ; Thu, 16 Oct 2008 09:55:51 -0700 (PDT) Received: (qmail 8729 invoked from network); 16 Oct 2008 16:56:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 16 Oct 2008 16:56:18 -0000 X-YMail-OSG: WXpfkOMVM1nvzsfWyfjfCzF1ppQH62ixoH9jivL1zCNvBoOxCDnjMHn9aCWxsNGhFe8NfjCNQJV2uX4CMUE.4XutDk04gH3YAPIVyN7Fxkpb8vO4Y0DipCbc.lCDR23Givk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48F77230.2010303@netconfcentral.com> Date: Thu, 16 Oct 2008 09:56:16 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Linowski, Bernd (EXT-Other - DE/Dusseldorf)" References: <48F0E1C9.1020308@netconfcentral.com> <48F0FEBA.4050109@netconfcentral.com> <84028E2C0BD7D44F8308A6E7FF659CDB769EA0@FIESEXC015.nsn-intra.net> In-Reply-To: <84028E2C0BD7D44F8308A6E7FF659CDB769EA0@FIESEXC015.nsn-intra.net> Cc: NETMOD Working Group Subject: Re: [netmod] methods and events X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Linowski, Bernd (EXT-Other - DE/Dusseldorf) wrote: > Hi, > > first, I think it is a good idea to put methods (or "actions") inside > (local to) data nodes as it makes much more obvious to which part of the > tree > the method is applied. > I realized by the time I sent the original mail that the 'self' parameter is all that is added. > In my opinion, having the method target ("self" parameter) as implicit > parameter > and being able to add additional parameters as needed in the context at > hand is enough. > More complex mechanisms like signatures might turn out to be hard to > understand > and use correctly. > > What is not clear to me is > - how is the output / result of an method invocation specified? TBD: the tail-f 'action' construct seems a good place to start. > - can methods statements be augmented? good question. I hope not, and I strongly oppose making 'action' one of the data-def-stmt options. > Would it be allowed to add additional, > optional parameters? > - can new methods itself be augmented? > So would it be allowed to augment a method to lists and containers? > > Best wishes, > Bernd > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Oct 17 06:08:46 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B11F3A68A2; Fri, 17 Oct 2008 06:08:46 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCB213A692B for ; Fri, 17 Oct 2008 06:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HapVgZkeeUK8 for ; Fri, 17 Oct 2008 06:08:40 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 928CF3A68A2 for ; Fri, 17 Oct 2008 06:08:40 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9F33F20C55 for ; Fri, 17 Oct 2008 15:08:14 +0200 (CEST) X-AuditID: c1b4fb3c-ab0c8bb0000015b5-c5-48f88e3eeabd Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7C988207CE for ; Fri, 17 Oct 2008 15:08:14 +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, 17 Oct 2008 15:06:11 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 15:06:11 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Fri, 17 Oct 2008 15:06:11 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200810171506.11481.david.partain@ericsson.com> X-OriginalArrivalTime: 17 Oct 2008 13:06:11.0574 (UTC) FILETIME=[20B53960:01C93059] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Consensus call on yang-00088: new "refine" statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings, This is a call for consensus about issue 'yang-00088: new "refine" statement'. See the wiki at http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00088 This mail and other consensus calls after the interim will follow a similar pattern. First, we have the question and the proposed consensus, then details. The details include examples, followed by a summary of the interim discussion on the issues. Please read the whole message. PLEASE speak up if you favor or object to the proposed change, including people who attended the interim. Silence is impossible to interpret. This issue on the wiki actually is about 4 interrelated issues, all of which have a proposed consensus in this mail: 1. Should we add a refine statement (assuming we have 'augment' inside uses) in "uses"? Rough Consensus from the interim: make this change 2. Should we have an 'augment' statement inside the 'uses' (while keeping the top-level 'augment')? (very) Rough Consensus from the interim: make this change 3. Should we put a "when" as a substatement of a leaf? Rough Consensus from the interim: yes, assuming #2 is yes. 4. Should we have two 'augment' keywords? Rough Consensus from the interim: yes, assuming #2 is yes. More details below... The current way YANG does things is to use an overlay and a conditional change. For example: container x augment . { when "..." ; leaf a { foo } ; } ------------------------------------------------------------------ First subissue: 1. Should we add a refine statement (assuming we have 'augment' inside uses) in 'uses'. That would look like this: uses foo { refine "b/c" { default 42; ... } } First consensus call is to determine whether we're going to add the refine statement and change the "overlay" way of doing things that we do today (see above). The sense of the room at the interim was that we have rough consensus to do so. However, adding separate keywords for refining each kind of node (refine-leaf, refine-container, etc.) generated no support, so that is off the table. ------------------------------------------------------------------ Second subissue: 2. Should we have an 'augment' statement inside the 'uses' (while keeping the top-level 'augment')? That would mean, for example: uses foo { augment "b/c" { ... } } This is 'just a syntactic change'. You cannot do more than you could before. Advantage is that you know which node the 'uses' come from. This does not disallow the top-level augment; it adds the augment to 'uses'. 'augment' was originally written to add nodes to a different namespace. At the top-level, 'augment' adds nodes to someone else's namespace, whereas this 'augment' adds to the current namespace. It also means we no longer have definitions spread out in seemingly unrelated places. Moving the augments inside uses forces you to collect related statements (the augment and the uses). Forces model writers to collect related information rather than spreading it around. The interim had very rough consensus to make this change. The primary argument for was the clear association of the 'augment' with the definition of the 'nodes' being augmented (clarity). Some of the arguments against were that what we have works fine and a worry of lost flexibility (unclear what flexibility, though). ------------------------------------------------------------------ Third subissue: 3. Should we put a "when" as a substatement of a leaf If we move augment to the uses statement (see previous subissue), we need to have "when" 'everywhere' (leaf, leaf-list, container, grouping, case, choice, notification, input, output). Rough concensus from the interim was that if #2 is introduced, this should be as well. ------------------------------------------------------------------ Fourth subissue: 4. Should we have two 'augment' keywords? Should we have two keywords (for top-level 'augment' and for 'augment' inside uses)? For example, the 'augments' under uses could be called "extend". Rough consensus in the meeting to have two different names. What the second name should be has not been decided. Suggestions welcome! _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Oct 17 06:39:03 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3D123A6405; Fri, 17 Oct 2008 06:39: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 88E2D3A6405 for ; Fri, 17 Oct 2008 06:39:02 -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 0qI7MkcVWlZ5 for ; Fri, 17 Oct 2008 06:39:01 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 3F78B3A6826 for ; Fri, 17 Oct 2008 06:39:01 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 72A8E21A64 for ; Fri, 17 Oct 2008 15:08:04 +0200 (CEST) X-AuditID: c1b4fb3e-aae89bb000007a96-08-48f88e1f2068 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0584A2066A for ; Fri, 17 Oct 2008 15:07:44 +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, 17 Oct 2008 15:07:13 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 15:07:13 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Fri, 17 Oct 2008 15:07:12 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200810171507.13052.david.partain@ericsson.com> X-OriginalArrivalTime: 17 Oct 2008 13:07:13.0140 (UTC) FILETIME=[45677340:01C93059] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Consensus call on yang-00750: add a "feature" feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 Greetings, This is a call for consensus about issue 'yang-00750: add a "feature" feature'. See the wiki at http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00750 This mail and other consensus calls after the interim will follow a similar pattern. First, we have the question and the proposed consensus, then details. The details include examples, followed by a summary of the interim discussion on the issues. Please read the whole message. PLEASE speak up if you favor or object to the proposed change, including people who attended the interim. A very simple high-level overview is below. Note that this issue was then split into two decisions: 1. Add 'if-feature', used to include nodes conditionally Rough consensus of the interim meeting: yes 2. Allow 'if-feature' to affect types conditionally (e.g., conditionally include an enumeration). Rough consensus of the interim meeting: no Details... Feature clause with subclauses defines a feature to be used... feature name { description references status if-feature } Conditional inclusion of a leaf based on a feature... leaf f { if-feature name; . . } Conditional change of a type based on a feature.... typedef x { type enumeration; enum foo { if-feature name; } } Advertisement of a feature. Given features n1,n2,n3: uri?features=3Dn1,n2,n3 Features are connected to a module: One feature, one module. However, 'if-feature' can refer to a feature defined in a different module. Ron Bonica asked: what if we don't have any of this? Phil Shafer: The problem is that the module is a contract and if we don't have finer granularity, we cannot follow that contract. That means we have to have a single module with separate modules to augment that module in order to add the conditionality. Furthermore, we (NETMOD) have a couple of groups using YANG that want something like this in order to partition a module into parts that are relevant for different implementations. The question is how we're going to meet that "market requirement"? Andy Bierman thinks this will be useful in the context of the IETF to allow them to define conditional parts of the module. With respect to the question where can one use 'if-feature' for altering types, the answer would be that it's all of the types that are OR'd: unions, bits, enumerations. Some concerns: - Andy Bierman is concerned that this looks good for simple things, but it might be complicated in the context of all of our conditional statements. - Martin Bj=F6rklund is, on the other hand, worried that it might be too simple since it's not an expression (with ORs, for example). - J=FCrgen Sch=F6nw=E4lder is concerned about propogation of features. For example: feature X { ... } typedef F { type enumeration { enum g { if-feature X; } } } Then, in a different module... import F {...} leaf a { type F; } // dependent on Feature X! leaf b { when "a =3D g"; ... } - Ladislav Lhotka proposed emulating this feature with existing functionality in the language rather than introducing a new language feature. container features { container foo { presense ...;' leaf enable {type boolean;} } container bar { } } and then use 'when' to introduced the conditionality. The problem is that 'when' cannot refer to non-config data, which is what this is. It is also the case that you won't be able to conditionally include enumerations, union parts, etc. - David Harrington thinks there are cleaner ways to do this and doesn't like that it looks like there are #ifdefs spread throughout the module. He is concerned we're adding complexity to the language. Instead, he thinks (1) use different modules (do things like they are now), (2) do something like what's in the SMI. - Andy Bierman thinks something like this will be useful in the context of the IETF to allow them to define conditional parts of the module. He, however, was not convinced that this proposal is the right solution. Conclusions: - There was rough consensus to include if-feature for conditional inclusion of data definitions. - There was NO consensus to include if-feature within data types (unions, enumerations,...). This remains open. - Andy Bierman is going to work on a proposal to deal with more expressive conformance declarations as a complement to if-feature for conditional inclusion of data definitions. He has the skeleton of a proposal that he will be send to the list. There are things we want to be able to reflect about conformance for a data definition: * config * type restrictions * not supported _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Oct 17 06: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 B89303A68A2; Fri, 17 Oct 2008 06: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 F18773A68A2 for ; Fri, 17 Oct 2008 06:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COi8tNpbIdL8 for ; Fri, 17 Oct 2008 06:41:50 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 377943A6897 for ; Fri, 17 Oct 2008 06:41:50 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 340A022737 for ; Fri, 17 Oct 2008 15:41:14 +0200 (CEST) X-AuditID: c1b4fb3e-a8684bb000007a96-32-48f895b426dd Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 331EB2257E for ; Fri, 17 Oct 2008 15:40:04 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 15:38:16 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 15:38:16 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Fri, 17 Oct 2008 15:38:16 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200810171538.16749.david.partain@ericsson.com> X-OriginalArrivalTime: 17 Oct 2008 13:38:16.0893 (UTC) FILETIME=[9C4996D0:01C9305D] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] NETMOD meeting times in Minneapolis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, In case you haven't seen it yet, NETMOD has been scheduled for two sessions at the upcoming IETF: Monday, 1300-1500 Afternoon Session I Friday, 0900-1130 Morning Session I Cheers, David _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Oct 17 12:13: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 24E963A6A60; Fri, 17 Oct 2008 12:13: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 BF8633A6A57 for ; Fri, 17 Oct 2008 12:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jaZf+rntsWT for ; Fri, 17 Oct 2008 12:13:09 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 8524C3A6A60 for ; Fri, 17 Oct 2008 12:13:09 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 7F42DD800C7 for ; Fri, 17 Oct 2008 21:14:13 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <200810171506.11481.david.partain@ericsson.com> References: <200810171506.11481.david.partain@ericsson.com> Organization: CESNET Date: Fri, 17 Oct 2008 21:14:14 +0200 Message-Id: <1224270854.6275.40.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] Consensus call on yang-00088: new "refine" statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org SGksCgpJIGFtIHN0cm9uZ2x5IGluIGZhdm9yIG9mIGFsbCB0aGVzZSBjaGFuZ2VzLCB0aGV5IG1h a2UgdGhlIGxhbmd1YWdlIG1vcmUKcHJlZGljdGFibGUuIE15IHN1Z2dlc3Rpb24gZm9yIHRoZSBu ZXcgbmFtZSBvZiB0b3AtbGV2ZWwgYXVnbWVudCBpcwoiaW5zZXJ0Ii4KCkxhZGEKCkRhdmlkIFBh cnRhaW4gcMOtxaFlIHYgUMOhIDE3LiAxMC4gMjAwOCB2IDE1OjA2ICswMjAwOgo+IEdyZWV0aW5n cywKPiAKPiBUaGlzIGlzIGEgY2FsbCBmb3IgY29uc2Vuc3VzIGFib3V0IGlzc3VlICd5YW5nLTAw MDg4OiBuZXcKPiAicmVmaW5lIiBzdGF0ZW1lbnQnLiAgU2VlIHRoZSB3aWtpIGF0Cj4gaHR0cDov L3dpa2kudG9vbHMuaWV0Zi5vcmcvd2cvbmV0bW9kL3RyYWMvd2lraS9Jc3N1ZXNfeWFuZyNpc3N1 ZS0wMDA4OAo+IAo+IFRoaXMgbWFpbCBhbmQgb3RoZXIgY29uc2Vuc3VzIGNhbGxzIGFmdGVyIHRo ZSBpbnRlcmltIHdpbGwgZm9sbG93Cj4gYSBzaW1pbGFyIHBhdHRlcm4uICBGaXJzdCwgd2UgaGF2 ZSB0aGUgcXVlc3Rpb24gYW5kIHRoZSBwcm9wb3NlZAo+IGNvbnNlbnN1cywgdGhlbiBkZXRhaWxz LiAgVGhlIGRldGFpbHMgaW5jbHVkZSBleGFtcGxlcywgZm9sbG93ZWQKPiBieSBhIHN1bW1hcnkg b2YgdGhlIGludGVyaW0gZGlzY3Vzc2lvbiBvbiB0aGUgaXNzdWVzLiAgUGxlYXNlCj4gcmVhZCB0 aGUgd2hvbGUgbWVzc2FnZS4KPiAKPiBQTEVBU0Ugc3BlYWsgdXAgaWYgeW91IGZhdm9yIG9yIG9i amVjdCB0byB0aGUgcHJvcG9zZWQgY2hhbmdlLAo+IGluY2x1ZGluZyBwZW9wbGUgd2hvIGF0dGVu ZGVkIHRoZSBpbnRlcmltLiAgU2lsZW5jZSBpcyBpbXBvc3NpYmxlCj4gdG8gaW50ZXJwcmV0Lgo+ IAo+IFRoaXMgaXNzdWUgb24gdGhlIHdpa2kgYWN0dWFsbHkgaXMgYWJvdXQgNCBpbnRlcnJlbGF0 ZWQgaXNzdWVzLAo+IGFsbCBvZiB3aGljaCBoYXZlIGEgcHJvcG9zZWQgY29uc2Vuc3VzIGluIHRo aXMgbWFpbDoKPiAKPiAxLiBTaG91bGQgd2UgYWRkIGEgcmVmaW5lIHN0YXRlbWVudCAoYXNzdW1p bmcgd2UgaGF2ZSAnYXVnbWVudCcKPiAgICBpbnNpZGUgdXNlcykgaW4gInVzZXMiPwo+IAo+ICAg IFJvdWdoIENvbnNlbnN1cyBmcm9tIHRoZSBpbnRlcmltOiBtYWtlIHRoaXMgY2hhbmdlCj4gCj4g Mi4gU2hvdWxkIHdlIGhhdmUgYW4gJ2F1Z21lbnQnIHN0YXRlbWVudCBpbnNpZGUgdGhlICd1c2Vz Jwo+ICAgICh3aGlsZSBrZWVwaW5nIHRoZSB0b3AtbGV2ZWwgJ2F1Z21lbnQnKT8KPiAKPiAgICAo dmVyeSkgUm91Z2ggQ29uc2Vuc3VzIGZyb20gdGhlIGludGVyaW06IG1ha2UgdGhpcyBjaGFuZ2UK PiAKPiAzLiBTaG91bGQgd2UgcHV0IGEgIndoZW4iIGFzIGEgc3Vic3RhdGVtZW50IG9mIGEgbGVh Zj8KPiAKPiAgICBSb3VnaCBDb25zZW5zdXMgZnJvbSB0aGUgaW50ZXJpbTogeWVzLCBhc3N1bWlu ZyAjMiBpcyB5ZXMuCj4gCj4gNC4gU2hvdWxkIHdlIGhhdmUgdHdvICdhdWdtZW50JyBrZXl3b3Jk cz8KPiAKPiAgICBSb3VnaCBDb25zZW5zdXMgZnJvbSB0aGUgaW50ZXJpbTogeWVzLCBhc3N1bWlu ZyAjMiBpcyB5ZXMuCj4gCj4gTW9yZSBkZXRhaWxzIGJlbG93Li4uCj4gCj4gVGhlIGN1cnJlbnQg d2F5IFlBTkcgZG9lcyB0aGluZ3MgaXMgdG8gdXNlIGFuIG92ZXJsYXkgYW5kIGEKPiBjb25kaXRp b25hbCBjaGFuZ2UuICBGb3IgZXhhbXBsZToKPiAKPiBjb250YWluZXIgeAo+ICAgYXVnbWVudCAu IHsKPiAgIHdoZW4gIi4uLiIgOwo+ICAgbGVhZiBhIHsgZm9vIH0gOwo+ICAgfQo+IAo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQo+IEZpcnN0IHN1Ymlzc3VlOiAxLiBTaG91bGQgd2UgYWRkIGEgcmVmaW5lIHN0YXRlbWVu dCAoYXNzdW1pbmcKPiB3ZSBoYXZlICdhdWdtZW50JyBpbnNpZGUgdXNlcykgaW4gJ3VzZXMnLgo+ IAo+IFRoYXQgd291bGQgbG9vayBsaWtlIHRoaXM6Cj4gCj4gdXNlcyBmb28gewo+ICAgcmVmaW5l ICJiL2MiIHsKPiAgICAgZGVmYXVsdCA0MjsKPiAgICAgLi4uCj4gICB9Cj4gfQo+IAo+IEZpcnN0 IGNvbnNlbnN1cyBjYWxsIGlzIHRvIGRldGVybWluZSB3aGV0aGVyIHdlJ3JlIGdvaW5nIHRvIGFk ZAo+IHRoZSByZWZpbmUgc3RhdGVtZW50IGFuZCBjaGFuZ2UgdGhlICJvdmVybGF5IiB3YXkgb2Yg ZG9pbmcgdGhpbmdzCj4gdGhhdCB3ZSBkbyB0b2RheSAoc2VlIGFib3ZlKS4gIFRoZSBzZW5zZSBv ZiB0aGUgcm9vbSBhdCB0aGUKPiBpbnRlcmltIHdhcyB0aGF0IHdlIGhhdmUgcm91Z2ggY29uc2Vu c3VzIHRvIGRvIHNvLgo+IAo+IEhvd2V2ZXIsIGFkZGluZyBzZXBhcmF0ZSBrZXl3b3JkcyBmb3Ig cmVmaW5pbmcgZWFjaCBraW5kIG9mIG5vZGUKPiAocmVmaW5lLWxlYWYsIHJlZmluZS1jb250YWlu ZXIsIGV0Yy4pIGdlbmVyYXRlZCBubyBzdXBwb3J0LCBzbwo+IHRoYXQgaXMgb2ZmIHRoZSB0YWJs ZS4KPiAKPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KPiBTZWNvbmQgc3ViaXNzdWU6IDIuIFNob3VsZCB3ZSBoYXZlIGFu ICdhdWdtZW50JyBzdGF0ZW1lbnQgaW5zaWRlCj4gdGhlICd1c2VzJyAod2hpbGUga2VlcGluZyB0 aGUgdG9wLWxldmVsICdhdWdtZW50Jyk/Cj4gCj4gVGhhdCB3b3VsZCBtZWFuLCBmb3IgZXhhbXBs ZToKPiAKPiB1c2VzIGZvbyB7Cj4gICBhdWdtZW50ICJiL2MiIHsKPiAgICAgLi4uCj4gICB9Cj4g fQo+IAo+IFRoaXMgaXMgJ2p1c3QgYSBzeW50YWN0aWMgY2hhbmdlJy4gWW91IGNhbm5vdCBkbyBt b3JlIHRoYW4geW91Cj4gY291bGQgYmVmb3JlLiAgQWR2YW50YWdlIGlzIHRoYXQgeW91IGtub3cg d2hpY2ggbm9kZSB0aGUgJ3VzZXMnCj4gY29tZSBmcm9tLgo+IAo+IFRoaXMgZG9lcyBub3QgZGlz YWxsb3cgdGhlIHRvcC1sZXZlbCBhdWdtZW50OyBpdCBhZGRzIHRoZSBhdWdtZW50Cj4gdG8gJ3Vz ZXMnLiAgJ2F1Z21lbnQnIHdhcyBvcmlnaW5hbGx5IHdyaXR0ZW4gdG8gYWRkIG5vZGVzIHRvIGEK PiBkaWZmZXJlbnQgbmFtZXNwYWNlLiAgQXQgdGhlIHRvcC1sZXZlbCwgJ2F1Z21lbnQnIGFkZHMg bm9kZXMgdG8KPiBzb21lb25lIGVsc2UncyBuYW1lc3BhY2UsIHdoZXJlYXMgdGhpcyAnYXVnbWVu dCcgYWRkcyB0byB0aGUKPiBjdXJyZW50IG5hbWVzcGFjZS4KPiAKPiBJdCBhbHNvIG1lYW5zIHdl IG5vIGxvbmdlciBoYXZlIGRlZmluaXRpb25zIHNwcmVhZCBvdXQgaW4KPiBzZWVtaW5nbHkgdW5y ZWxhdGVkIHBsYWNlcy4gIE1vdmluZyB0aGUgYXVnbWVudHMgaW5zaWRlIHVzZXMKPiBmb3JjZXMg eW91IHRvIGNvbGxlY3QgcmVsYXRlZCBzdGF0ZW1lbnRzICh0aGUgYXVnbWVudCBhbmQgdGhlCj4g dXNlcykuICBGb3JjZXMgbW9kZWwgd3JpdGVycyB0byBjb2xsZWN0IHJlbGF0ZWQgaW5mb3JtYXRp b24KPiByYXRoZXIgdGhhbiBzcHJlYWRpbmcgaXQgYXJvdW5kLgo+IAo+IFRoZSBpbnRlcmltIGhh ZCB2ZXJ5IHJvdWdoIGNvbnNlbnN1cyB0byBtYWtlIHRoaXMgY2hhbmdlLiAgVGhlCj4gcHJpbWFy eSBhcmd1bWVudCBmb3Igd2FzIHRoZSBjbGVhciBhc3NvY2lhdGlvbiBvZiB0aGUgJ2F1Z21lbnQn Cj4gd2l0aCB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgJ25vZGVzJyBiZWluZyBhdWdtZW50ZWQgKGNs YXJpdHkpLgo+IFNvbWUgb2YgdGhlIGFyZ3VtZW50cyBhZ2FpbnN0IHdlcmUgdGhhdCB3aGF0IHdl IGhhdmUgd29ya3MgZmluZQo+IGFuZCBhIHdvcnJ5IG9mIGxvc3QgZmxleGliaWxpdHkgKHVuY2xl YXIgd2hhdCBmbGV4aWJpbGl0eSwKPiB0aG91Z2gpLgo+IAo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IFRoaXJkIHN1 Ymlzc3VlOiAzLiBTaG91bGQgd2UgcHV0IGEgIndoZW4iIGFzIGEgc3Vic3RhdGVtZW50IG9mIGEg bGVhZgo+IAo+IElmIHdlIG1vdmUgYXVnbWVudCB0byB0aGUgdXNlcyBzdGF0ZW1lbnQgKHNlZSBw cmV2aW91cyBzdWJpc3N1ZSksCj4gd2UgbmVlZCB0byBoYXZlICJ3aGVuIiAnZXZlcnl3aGVyZScg KGxlYWYsIGxlYWYtbGlzdCwgY29udGFpbmVyLAo+IGdyb3VwaW5nLCBjYXNlLCBjaG9pY2UsIG5v dGlmaWNhdGlvbiwgaW5wdXQsIG91dHB1dCkuCj4gCj4gUm91Z2ggY29uY2Vuc3VzIGZyb20gdGhl IGludGVyaW0gd2FzIHRoYXQgaWYgIzIgaXMgaW50cm9kdWNlZCwKPiB0aGlzIHNob3VsZCBiZSBh cyB3ZWxsLgo+IAo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IEZvdXJ0aCBzdWJpc3N1ZTogNC4gU2hvdWxkIHdlIGhh dmUgdHdvICdhdWdtZW50JyBrZXl3b3Jkcz8KPiAKPiBTaG91bGQgd2UgaGF2ZSB0d28ga2V5d29y ZHMgKGZvciB0b3AtbGV2ZWwgJ2F1Z21lbnQnIGFuZCBmb3IKPiAnYXVnbWVudCcgaW5zaWRlIHVz ZXMpPyAgRm9yIGV4YW1wbGUsIHRoZSAnYXVnbWVudHMnIHVuZGVyIHVzZXMKPiBjb3VsZCBiZSBj YWxsZWQgImV4dGVuZCIuCj4gCj4gUm91Z2ggY29uc2Vuc3VzIGluIHRoZSBtZWV0aW5nIHRvIGhh dmUgdHdvIGRpZmZlcmVudCBuYW1lcy4gIFdoYXQKPiB0aGUgc2Vjb25kIG5hbWUgc2hvdWxkIGJl IGhhcyBub3QgYmVlbiBkZWNpZGVkLgo+IAo+IFN1Z2dlc3Rpb25zIHdlbGNvbWUhCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBuZXRtb2QgbWFpbGlu ZyBsaXN0Cj4gbmV0bW9kQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRtb2QKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3 NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpu ZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Fri Oct 17 12:26: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 7FE313A6818; Fri, 17 Oct 2008 12:26: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 643C03A6969 for ; Fri, 17 Oct 2008 12:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.952 X-Spam-Level: X-Spam-Status: No, score=-0.952 tagged_above=-999 required=5 tests=[AWL=0.298, 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 ZHBig8MRIQrd for ; Fri, 17 Oct 2008 12:26:23 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 0DB163A6818 for ; Fri, 17 Oct 2008 12:26:23 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 74546D800C7 for ; Fri, 17 Oct 2008 21:27:27 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <200810171507.13052.david.partain@ericsson.com> References: <200810171507.13052.david.partain@ericsson.com> Organization: CESNET Date: Fri, 17 Oct 2008 21:27:28 +0200 Message-Id: <1224271648.6275.54.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] Consensus call on yang-00750: add a "feature" feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 SGksCgpJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0byBtYWtlIHRoZSBpbmZvIGFib3V0IGF2 YWlsYWJsZSBmZWF0dXJlcyBhCnBhcnQgb2YgdGhlICBjb25maWd1cmF0aW9uIGRhdGFiYXNlOgoK MS4gSXQgaXMgc2ltcGxlciwgbm8gbmV3IGZlYXR1cmVzIGluIGJvdGggWUFORyBhbmQgTkVUQ09O RiBhcmUgbmVlZGVkLCAKICAganVzdCBtaW5vciBjaGFuZ2VzIG9mIFlBTkcgcnVsZXMgKGZvciBp bnN0YW5jZSwgYWxsb3cgbm9uLWNvbmZpZyAKICAgbm9kZXMgaW4gd2hlbiBleHByZXNzaW9ucyku CjIuIFRoZSBleGlzdGVuY2Ugb2YgYW4gZmVhdHVyZSBjYW4gYmUgY2hlY2tlZCBhdCBhbnkgdGlt ZSwgbm90IG9ubHkgICAgCiAgIGZyb20gdGhlIGhlbGxvIG1lc3NhZ2UuIChXaGF0IGlmIGEgZmVh dHVyZSBhcHBlYXJzIGR1cmluZyBhIHNlc3Npb24sIAogICBlLmcuLCB2aWEgaG90IHN3YXA/KQoK TGFkYQoKRGF2aWQgUGFydGFpbiBww63FoWUgdiBQw6EgMTcuIDEwLiAyMDA4IHYgMTU6MDcgKzAy MDA6Cj4gR3JlZXRpbmdzLAo+IAo+IFRoaXMgaXMgYSBjYWxsIGZvciBjb25zZW5zdXMgYWJvdXQg aXNzdWUgJ3lhbmctMDA3NTA6IGFkZCBhCj4gImZlYXR1cmUiIGZlYXR1cmUnLiAgU2VlIHRoZSB3 aWtpIGF0Cj4gaHR0cDovL3dpa2kudG9vbHMuaWV0Zi5vcmcvd2cvbmV0bW9kL3RyYWMvd2lraS9J c3N1ZXNfeWFuZyNpc3N1ZS0wMDc1MAo+IAo+IFRoaXMgbWFpbCBhbmQgb3RoZXIgY29uc2Vuc3Vz IGNhbGxzIGFmdGVyIHRoZSBpbnRlcmltIHdpbGwgZm9sbG93Cj4gYSBzaW1pbGFyIHBhdHRlcm4u ICBGaXJzdCwgd2UgaGF2ZSB0aGUgcXVlc3Rpb24gYW5kIHRoZSBwcm9wb3NlZAo+IGNvbnNlbnN1 cywgdGhlbiBkZXRhaWxzLiAgVGhlIGRldGFpbHMgaW5jbHVkZSBleGFtcGxlcywgZm9sbG93ZWQK PiBieSBhIHN1bW1hcnkgb2YgdGhlIGludGVyaW0gZGlzY3Vzc2lvbiBvbiB0aGUgaXNzdWVzLiAg UGxlYXNlCj4gcmVhZCB0aGUgd2hvbGUgbWVzc2FnZS4KPiAKPiBQTEVBU0Ugc3BlYWsgdXAgaWYg eW91IGZhdm9yIG9yIG9iamVjdCB0byB0aGUgcHJvcG9zZWQgY2hhbmdlLAo+IGluY2x1ZGluZyBw ZW9wbGUgd2hvIGF0dGVuZGVkIHRoZSBpbnRlcmltLgo+IAo+IEEgdmVyeSBzaW1wbGUgaGlnaC1s ZXZlbCBvdmVydmlldyBpcyBiZWxvdy4gIE5vdGUgdGhhdCB0aGlzIGlzc3VlCj4gd2FzIHRoZW4g c3BsaXQgaW50byB0d28gZGVjaXNpb25zOgo+IAo+IDEuIEFkZCAnaWYtZmVhdHVyZScsIHVzZWQg dG8gaW5jbHVkZSBub2RlcyBjb25kaXRpb25hbGx5Cj4gCj4gICAgUm91Z2ggY29uc2Vuc3VzIG9m IHRoZSBpbnRlcmltIG1lZXRpbmc6IHllcwo+IAo+IDIuIEFsbG93ICdpZi1mZWF0dXJlJyB0byBh ZmZlY3QgdHlwZXMgY29uZGl0aW9uYWxseSAoZS5nLiwKPiAgICBjb25kaXRpb25hbGx5IGluY2x1 ZGUgYW4gZW51bWVyYXRpb24pLgo+IAo+ICAgIFJvdWdoIGNvbnNlbnN1cyBvZiB0aGUgaW50ZXJp bSBtZWV0aW5nOiBubwo+IAo+IERldGFpbHMuLi4KPiAKPiBGZWF0dXJlIGNsYXVzZSB3aXRoIHN1 YmNsYXVzZXMgZGVmaW5lcyBhIGZlYXR1cmUgdG8gYmUgdXNlZC4uLgo+IAo+IGZlYXR1cmUgbmFt ZSB7Cj4gIGRlc2NyaXB0aW9uCj4gIHJlZmVyZW5jZXMKPiAgc3RhdHVzCj4gIGlmLWZlYXR1cmUK PiB9Cj4gCj4gQ29uZGl0aW9uYWwgaW5jbHVzaW9uIG9mIGEgbGVhZiBiYXNlZCBvbiBhIGZlYXR1 cmUuLi4KPiAKPiBsZWFmIGYgewo+ICAgaWYtZmVhdHVyZSBuYW1lOwo+ICAgLgo+ICAgLgo+IH0K PiAKPiBDb25kaXRpb25hbCBjaGFuZ2Ugb2YgYSB0eXBlIGJhc2VkIG9uIGEgZmVhdHVyZS4uLi4K PiAKPiB0eXBlZGVmIHggewo+ICAgdHlwZSBlbnVtZXJhdGlvbjsKPiAgICAgZW51bSBmb28geyBp Zi1mZWF0dXJlIG5hbWU7IH0KPiB9Cj4gCj4gQWR2ZXJ0aXNlbWVudCBvZiBhIGZlYXR1cmUuICBH aXZlbiBmZWF0dXJlcyBuMSxuMixuMzoKPiAKPiA8aGVsbG8+Cj4gICA8Y2FwPnVyaT9mZWF0dXJl cz1uMSxuMixuMzwvY2FwPgo+IDwvaGVsbG8+Cj4gCj4gRmVhdHVyZXMgYXJlIGNvbm5lY3RlZCB0 byBhIG1vZHVsZTogT25lIGZlYXR1cmUsIG9uZSBtb2R1bGUuCj4gSG93ZXZlciwgJ2lmLWZlYXR1 cmUnIGNhbiByZWZlciB0byBhIGZlYXR1cmUgZGVmaW5lZCBpbiBhCj4gZGlmZmVyZW50IG1vZHVs ZS4KPiAKPiBSb24gQm9uaWNhIGFza2VkOiB3aGF0IGlmIHdlIGRvbid0IGhhdmUgYW55IG9mIHRo aXM/Cj4gCj4gUGhpbCBTaGFmZXI6ICBUaGUgcHJvYmxlbSBpcyB0aGF0IHRoZSBtb2R1bGUgaXMg YSBjb250cmFjdCBhbmQgaWYKPiB3ZSBkb24ndCBoYXZlIGZpbmVyIGdyYW51bGFyaXR5LCB3ZSBj YW5ub3QgZm9sbG93IHRoYXQgY29udHJhY3QuCj4gVGhhdCBtZWFucyB3ZSBoYXZlIHRvIGhhdmUg YSBzaW5nbGUgbW9kdWxlIHdpdGggc2VwYXJhdGUgbW9kdWxlcwo+IHRvIGF1Z21lbnQgdGhhdCBt b2R1bGUgaW4gb3JkZXIgdG8gYWRkIHRoZSBjb25kaXRpb25hbGl0eS4KPiAKPiBGdXJ0aGVybW9y ZSwgd2UgKE5FVE1PRCkgaGF2ZSBhIGNvdXBsZSBvZiBncm91cHMgdXNpbmcgWUFORyB0aGF0Cj4g d2FudCBzb21ldGhpbmcgbGlrZSB0aGlzIGluIG9yZGVyIHRvIHBhcnRpdGlvbiBhIG1vZHVsZSBp bnRvCj4gcGFydHMgdGhhdCBhcmUgcmVsZXZhbnQgZm9yIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlv bnMuICBUaGUKPiBxdWVzdGlvbiBpcyBob3cgd2UncmUgZ29pbmcgdG8gbWVldCB0aGF0ICJtYXJr ZXQgcmVxdWlyZW1lbnQiPwo+IAo+IEFuZHkgQmllcm1hbiB0aGlua3MgdGhpcyB3aWxsIGJlIHVz ZWZ1bCBpbiB0aGUgY29udGV4dCBvZiB0aGUKPiBJRVRGIHRvIGFsbG93IHRoZW0gdG8gZGVmaW5l IGNvbmRpdGlvbmFsIHBhcnRzIG9mIHRoZSBtb2R1bGUuCj4gCj4gV2l0aCByZXNwZWN0IHRvIHRo ZSBxdWVzdGlvbiB3aGVyZSBjYW4gb25lIHVzZSAnaWYtZmVhdHVyZScgZm9yCj4gYWx0ZXJpbmcg dHlwZXMsIHRoZSBhbnN3ZXIgd291bGQgYmUgdGhhdCBpdCdzIGFsbCBvZiB0aGUgdHlwZXMKPiB0 aGF0IGFyZSBPUidkOiB1bmlvbnMsIGJpdHMsIGVudW1lcmF0aW9ucy4KPiAKPiBTb21lIGNvbmNl cm5zOgo+IAo+ICAtIEFuZHkgQmllcm1hbiBpcyBjb25jZXJuZWQgdGhhdCB0aGlzIGxvb2tzIGdv b2QgZm9yIHNpbXBsZQo+ICAgIHRoaW5ncywgYnV0IGl0IG1pZ2h0IGJlIGNvbXBsaWNhdGVkIGlu IHRoZSBjb250ZXh0IG9mIGFsbCBvZgo+ICAgIG91ciBjb25kaXRpb25hbCBzdGF0ZW1lbnRzLgo+ IAo+ICAtIE1hcnRpbiBCasO2cmtsdW5kIGlzLCBvbiB0aGUgb3RoZXIgaGFuZCwgd29ycmllZCB0 aGF0IGl0IG1pZ2h0Cj4gICAgYmUgdG9vIHNpbXBsZSBzaW5jZSBpdCdzIG5vdCBhbiBleHByZXNz aW9uICh3aXRoIE9ScywgZm9yCj4gICAgZXhhbXBsZSkuCj4gCj4gIC0gSsO8cmdlbiBTY2jDtm53 w6RsZGVyIGlzIGNvbmNlcm5lZCBhYm91dCBwcm9wb2dhdGlvbiBvZiBmZWF0dXJlcy4KPiAgICBG b3IgZXhhbXBsZToKPiAKPiAgICBmZWF0dXJlIFggewo+ICAgIC4uLgo+ICAgIH0KPiAKPiAgICB0 eXBlZGVmIEYgewo+ICAgICAgdHlwZSBlbnVtZXJhdGlvbiB7Cj4gICAgICAgIGVudW0gZyB7IGlm LWZlYXR1cmUgWDsgfQo+ICAgICAgfQo+ICAgIH0KPiAKPiAgICBUaGVuLCBpbiBhIGRpZmZlcmVu dCBtb2R1bGUuLi4KPiAKPiAgICBpbXBvcnQgRiB7Li4ufQo+IAo+ICAgICAgbGVhZiBhIHsgdHlw ZSBGOyB9ICAvLyBkZXBlbmRlbnQgb24gRmVhdHVyZSBYIQo+ICAgICAgbGVhZiBiIHsKPiAgICAg ICAgd2hlbiAiYSA9IGciOwo+ICAgICAgICAuLi4KPiAgICAgIH0KPiAKPiAgLSBMYWRpc2xhdiBM aG90a2EgcHJvcG9zZWQgZW11bGF0aW5nIHRoaXMgZmVhdHVyZSB3aXRoIGV4aXN0aW5nCj4gICAg ZnVuY3Rpb25hbGl0eSBpbiB0aGUgbGFuZ3VhZ2UgcmF0aGVyIHRoYW4gaW50cm9kdWNpbmcgYSBu ZXcKPiAgICBsYW5ndWFnZSBmZWF0dXJlLgo+IAo+ICAgIGNvbnRhaW5lciBmZWF0dXJlcyB7Cj4g ICAgICBjb250YWluZXIgZm9vIHsKPiAgICAgICAgcHJlc2Vuc2UgLi4uOycKPiAgICAgICAgbGVh ZiBlbmFibGUge3R5cGUgYm9vbGVhbjt9Cj4gICAgICB9Cj4gCj4gICAgICBjb250YWluZXIgYmFy IHsKPiAgICAgIH0KPiAgICB9Cj4gCj4gICAgYW5kIHRoZW4gdXNlICd3aGVuJyB0byBpbnRyb2R1 Y2VkIHRoZSBjb25kaXRpb25hbGl0eS4gIFRoZQo+ICAgIHByb2JsZW0gaXMgdGhhdCAnd2hlbicg Y2Fubm90IHJlZmVyIHRvIG5vbi1jb25maWcgZGF0YSwgd2hpY2gKPiAgICBpcyB3aGF0IHRoaXMg aXMuICBJdCBpcyBhbHNvIHRoZSBjYXNlIHRoYXQgeW91IHdvbid0IGJlIGFibGUKPiAgICB0byBj b25kaXRpb25hbGx5IGluY2x1ZGUgZW51bWVyYXRpb25zLCB1bmlvbiBwYXJ0cywgZXRjLgo+IAo+ ICAtIERhdmlkIEhhcnJpbmd0b24gdGhpbmtzIHRoZXJlIGFyZSBjbGVhbmVyIHdheXMgdG8gZG8g dGhpcyBhbmQKPiAgICBkb2Vzbid0IGxpa2UgdGhhdCBpdCBsb29rcyBsaWtlIHRoZXJlIGFyZSAj aWZkZWZzIHNwcmVhZAo+ICAgIHRocm91Z2hvdXQgdGhlIG1vZHVsZS4gIEhlIGlzIGNvbmNlcm5l ZCB3ZSdyZSBhZGRpbmcKPiAgICBjb21wbGV4aXR5IHRvIHRoZSBsYW5ndWFnZS4gIEluc3RlYWQs IGhlIHRoaW5rcyAoMSkgdXNlCj4gICAgZGlmZmVyZW50IG1vZHVsZXMgKGRvIHRoaW5ncyBsaWtl IHRoZXkgYXJlIG5vdyksICgyKSBkbwo+ICAgIHNvbWV0aGluZyBsaWtlIHdoYXQncyBpbiB0aGUg U01JLgo+IAo+ICAtIEFuZHkgQmllcm1hbiB0aGlua3Mgc29tZXRoaW5nIGxpa2UgdGhpcyB3aWxs IGJlIHVzZWZ1bCBpbiB0aGUKPiAgICBjb250ZXh0IG9mIHRoZSBJRVRGIHRvIGFsbG93IHRoZW0g dG8gZGVmaW5lIGNvbmRpdGlvbmFsIHBhcnRzCj4gICAgb2YgdGhlIG1vZHVsZS4gIEhlLCBob3dl dmVyLCB3YXMgbm90IGNvbnZpbmNlZCB0aGF0IHRoaXMKPiAgICBwcm9wb3NhbCBpcyB0aGUgcmln aHQgc29sdXRpb24uCj4gCj4gQ29uY2x1c2lvbnM6Cj4gCj4gIC0gVGhlcmUgd2FzIHJvdWdoIGNv bnNlbnN1cyB0byBpbmNsdWRlIGlmLWZlYXR1cmUgZm9yCj4gICAgY29uZGl0aW9uYWwgaW5jbHVz aW9uIG9mIGRhdGEgZGVmaW5pdGlvbnMuCj4gCj4gIC0gVGhlcmUgd2FzIE5PIGNvbnNlbnN1cyB0 byBpbmNsdWRlIGlmLWZlYXR1cmUgd2l0aGluIGRhdGEgdHlwZXMKPiAgICAodW5pb25zLCBlbnVt ZXJhdGlvbnMsLi4uKS4gIFRoaXMgcmVtYWlucyBvcGVuLgo+IAo+ICAtIEFuZHkgQmllcm1hbiBp cyBnb2luZyB0byB3b3JrIG9uIGEgcHJvcG9zYWwgdG8gZGVhbCB3aXRoIG1vcmUKPiAgICBleHBy ZXNzaXZlIGNvbmZvcm1hbmNlIGRlY2xhcmF0aW9ucyBhcyBhIGNvbXBsZW1lbnQgdG8KPiAgICBp Zi1mZWF0dXJlIGZvciBjb25kaXRpb25hbCBpbmNsdXNpb24gb2YgZGF0YSBkZWZpbml0aW9ucy4g IEhlCj4gICAgaGFzIHRoZSBza2VsZXRvbiBvZiBhIHByb3Bvc2FsIHRoYXQgaGUgd2lsbCBiZSBz ZW5kIHRvIHRoZQo+ICAgIGxpc3QuICBUaGVyZSBhcmUgdGhpbmdzIHdlIHdhbnQgdG8gYmUgYWJs ZSB0byByZWZsZWN0IGFib3V0Cj4gICAgY29uZm9ybWFuY2UgZm9yIGEgZGF0YSBkZWZpbml0aW9u Ogo+IAo+ICAgICogY29uZmlnCj4gICAgKiB0eXBlIHJlc3RyaWN0aW9ucwo+ICAgICogbm90IHN1 cHBvcnRlZAo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cj4gbmV0bW9kIG1haWxpbmcgbGlzdAo+IG5ldG1vZEBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05F VApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Fri Oct 17 12:33:47 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F41B03A6B01; Fri, 17 Oct 2008 12:33: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 C0AEB3A6B07 for ; Fri, 17 Oct 2008 12:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.181, 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 J5dGPAmudoXg for ; Fri, 17 Oct 2008 12:33:45 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8E6ED3A6B01 for ; Fri, 17 Oct 2008 12:33:43 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id BC8B476C4E6; Fri, 17 Oct 2008 21:34:31 +0200 (CEST) Date: Fri, 17 Oct 2008 21:34:31 +0200 (CEST) Message-Id: <20081017.213431.31977562.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1224270854.6275.40.camel@missotis> References: <200810171506.11481.david.partain@ericsson.com> <1224270854.6275.40.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] Consensus call on yang-00088: new "refine" statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Ladislav Lhotka wrote: > Hi, > > I am strongly in favor of all these changes +1 > My suggestion for the new name of top-level augment is "insert". I pefer to keep the top-level statement called 'augment', since this usage is most similiar to how the term is used in SMIv2. I suggest 'extend' for the other statement. When a grouping is used, it can be refined and extended. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Oct 17 12:37: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 2316F3A67E9; Fri, 17 Oct 2008 12:37: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 43B633A690A for ; Fri, 17 Oct 2008 12:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=0.171, 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 kQgGR-NRqrcn for ; Fri, 17 Oct 2008 12:37: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 8136D3A65A5 for ; Fri, 17 Oct 2008 12:37:56 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id CCA0576C4E6; Fri, 17 Oct 2008 21:39:00 +0200 (CEST) Date: Fri, 17 Oct 2008 21:38:54 +0200 (CEST) Message-Id: <20081017.213854.68735534.mbj@tail-f.com> To: david.partain@ericsson.com From: Martin Bjorklund In-Reply-To: <200810171507.13052.david.partain@ericsson.com> References: <200810171507.13052.david.partain@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] Consensus call on yang-00750: add a "feature" feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 support this change. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Oct 18 01:27: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 D263D3A6928; Sat, 18 Oct 2008 01:27: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 0268D3A6928 for ; Sat, 18 Oct 2008 01:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.237 X-Spam-Level: X-Spam-Status: No, score=-6.237 tagged_above=-999 required=5 tests=[AWL=0.012, 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 OJkDWwN8Cn1z for ; Sat, 18 Oct 2008 01:27:23 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 342343A67F3 for ; Sat, 18 Oct 2008 01:27:22 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 30B4421146 for ; Sat, 18 Oct 2008 10:28:27 +0200 (CEST) X-AuditID: c1b4fb3e-a8e85bb000007a96-fb-48f99e2b98c9 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1B2F920B8E for ; Sat, 18 Oct 2008 10:28:27 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Oct 2008 10:28:26 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Oct 2008 10:28:26 +0200 Message-ID: <48F99E2A.5090400@ericsson.com> Date: Sat, 18 Oct 2008 10:28:26 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Partain References: <200810171507.13052.david.partain@ericsson.com> In-Reply-To: <200810171507.13052.david.partain@ericsson.com> X-OriginalArrivalTime: 18 Oct 2008 08:28:26.0480 (UTC) FILETIME=[7DF36F00:01C930FB] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Consensus call on yang-00750: add a "feature" feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > - There was rough consensus to include if-feature for > conditional inclusion of data definitions. I support this. > > - There was NO consensus to include if-feature within data types > (unions, enumerations,...). This remains open. I support this. It could be useful when making backward compatible updates to my models. > I support both as presented by the diff-draft. Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Oct 18 09:09: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 1D5AA3A696B; Sat, 18 Oct 2008 09:09: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 25D113A6ACD for ; Sat, 18 Oct 2008 09:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8-cPB8wpu-V for ; Sat, 18 Oct 2008 09:09:50 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 4F10C3A696B for ; Sat, 18 Oct 2008 09:09:50 -0700 (PDT) Received: (qmail 39395 invoked from network); 18 Oct 2008 16:10:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 18 Oct 2008 16:10:54 -0000 X-YMail-OSG: JQgkdW4VM1kIPyerlGsWbXj7rTvRB5b5YChUVX4P3WGL88_16ylDo_pjOSTqVyOfAdKgXe12DR666ciuUb3.CXnAjTMzD1zCYQU7_gjASJxpolfRgIdvQ2oyus7ll0gVCM4T4rVlxIRa5MQaFU4i3zIC X-Yahoo-Newman-Property: ymail-3 Message-ID: <48FA0A8C.2050506@netconfcentral.com> Date: Sat, 18 Oct 2008 09:10:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: David Partain References: <200810171506.11481.david.partain@ericsson.com> In-Reply-To: <200810171506.11481.david.partain@ericsson.com> Cc: netmod@ietf.org Subject: Re: [netmod] Consensus call on yang-00088: new "refine" statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Partain wrote: > Greetings, > > This is a call for consensus about issue 'yang-00088: new > "refine" statement'. See the wiki at > http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00088 > > This mail and other consensus calls after the interim will follow > a similar pattern. First, we have the question and the proposed > consensus, then details. The details include examples, followed > by a summary of the interim discussion on the issues. Please > read the whole message. > > PLEASE speak up if you favor or object to the proposed change, > including people who attended the interim. Silence is impossible > to interpret. > > This issue on the wiki actually is about 4 interrelated issues, > all of which have a proposed consensus in this mail: > > 1. Should we add a refine statement (assuming we have 'augment' > inside uses) in "uses"? > > Rough Consensus from the interim: make this change > no -- IMO the current approach, which is slightly more verbose, is more readable because the type of contrust (container, list, leaf, etc.) is present, and all the refinements are forced to be within the one and only containment section for a given node. The refine approach assumes that the reader is very familiar with XPath, and with all the schema node types associated with the QNames in the XPath expression. Multiple refine-stmts for the same node can be present, as well as refinements in any order. Since YANG is new, and since the data models are always going to be new to a DM reader, and since YANG's main reason for existing is readability, it seems better to stick with the current approach. > 2. Should we have an 'augment' statement inside the 'uses' > (while keeping the top-level 'augment')? > > (very) Rough Consensus from the interim: make this change > no -- I prefer the current approach which has the 'when' clause within the augment-stmt. Forbidding augment (or extend) outside of a uses-stmt seems like a CLR to me. > 3. Should we put a "when" as a substatement of a leaf? > > Rough Consensus from the interim: yes, assuming #2 is yes. > no -- I prefer to think of the data model as the base contract, that is augmented when the specified condition is true. Changing the model to a bunch of random nodes that only exist when the specified conditions are true is a more complicated model. IMO, YANG has too many conditional constructs, which interact in ad-hoc ways. The current augment-stmt gathers all the additions in one place, with one 'when' clause. This makes it more clear to the reader what is going on. Sprinkling the same complicated 'when' clause all over the place (or is it the same?) can make it much harder for a reader to correctly interpret the data model contents. > 4. Should we have two 'augment' keywords? > > Rough Consensus from the interim: yes, assuming #2 is yes. > yes -- it might be useful to easily identify a construct that is augmenting another XML namespace (module), vs. an construct that is augmenting the same XML namespace. Calling them (top-level) augment and (nested) augment is not even accurate, because a top-level augment can name a local or remote object with an absolute XPath. A new name for an augment that affects a different namespace is a good idea -- augment-extern? Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Oct 18 09:39: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 A7F083A67ED; Sat, 18 Oct 2008 09:39: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 1E6BE3A692A for ; Sat, 18 Oct 2008 09:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12w8Y16aQAld for ; Sat, 18 Oct 2008 09:39:41 -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 720003A67ED for ; Sat, 18 Oct 2008 09:39:41 -0700 (PDT) Received: (qmail 34418 invoked from network); 18 Oct 2008 16:40:17 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 18 Oct 2008 16:40:16 -0000 X-YMail-OSG: w7S1EysVM1mOBtaZivXpOAQg_moKcOAtV6yogy8Kr7o7_gPhqM2bd_UxUfbJY9Yt5cVIoEiLfqJkeEHGB6nhO3.Hpwi4efGDwYu.tNs8EmV6X3sbL04Fowc3ZqSRDXhedG4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48FA116E.2050505@netconfcentral.com> Date: Sat, 18 Oct 2008 09:40:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] object, not leafref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I was asked to propose a 'leafref' built-in data type. Change of plans... The only use-case I know of for leafref is notification content. The notification-stmt needs work, and adding another built-in type is not the right answer. In SMIv2, a NOTIFICATION-TYPE macro has an OBJECTS clause. This is better than the YANG data-def-stmt contents because it is more terse, and clearly conveys the fact that a notification contains copies of database objects, and/or notification-only objects. YANG needs an 'object' sub-clause, which specifies a database object that will be copied into the notification: notification foo { object "/foo/bar/leaf1" { description "copied data from leaf1"; reference "..."; mandatory true; } object "/if:interfaces/if:interface/foo:fooEntry"; leaf foo-only { description "This leaf exists only in the foo notification."; type string; } } IMO this makes the notification content definition easier to understand, without suffering a massive ripple-effect that a new built-in type would cause. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Oct 18 10:32: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 DCBE63A67D2; Sat, 18 Oct 2008 10:32: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 38AF93A67D2 for ; Sat, 18 Oct 2008 10:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCBOVRiMSou8 for ; Sat, 18 Oct 2008 10:32:00 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 830BB3A692A for ; Sat, 18 Oct 2008 10:32:00 -0700 (PDT) Received: (qmail 43613 invoked from network); 18 Oct 2008 17:32:58 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 18 Oct 2008 17:32:56 -0000 X-YMail-OSG: fSiETogVM1nkdX2vKSZrcmGzJjSIwQL_t0qjXuWzvO9FMrl8DChyJCxeUFfVChs9kn2wElWjyN7fj_OiOgUA7TUrm8cCKCNXj1h3cCNjvJc2FHbobhTq9yTzXmoKAqwPHNzXLF2inFMYJ05x09fMP0k- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48FA1DC7.6010509@netconfcentral.com> Date: Sat, 18 Oct 2008 10:32:55 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] data model 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 Hi, IMO, the if-feature proposal, not to be confused with the addition deviation-stmt proposal, is a good inline solution if the number of features is small. However, I do not think it is sufficient or even the most appropriate solution approach for the module conformance problem. IMO, the following proposal addresses the deficiencies of the if-feature approach, and also makes import/include by revision unnecessary. module foo { namespace "..."; prefix foo; import x { prefix x; } import y { prefix y; } include foo-submod; revision 2008-10-18 { description "latest version"; } revision 2007-09-10 { description "initial version"; } // all the module definitions conformance 2008-10-18 { uses-import x { version 2007-10-17; } uses-import y { version 2008-03-01; } uses-include foo-submod { version 2007-09-10; } object-variance /foo:container/foo:leaf1 { config false; } object-variance /foo:container/x:list1 { min-elements 0; max-elements 0; } } conformance 2007-09-10 { uses-import x { version 2007-01-05; } uses-import y { version 2007-07-16; } uses-include foo-submod { version 2007-09-10; } } } The exact ABNF is TBD, but the conformance statement is what a WG would agree on before publishing a DM version. The syntax may end up similar to the deviation-stmt, but reporting agent implementation non-conformance is a different problem that agreeing on minimum conformance requirements for a standard data model. E.g., a module could claim conformance to version 2008-10-18 of module foo, even if it did not implement 'x:list1', or did not allow writes to 'foo:leaf1'. All readers and tools would know which versions of all modules involved for each published revision of each module. There is no ripple effect, since the import-stmt never needs to be edited. There is no enumerated list of objects to write, but there is still a need for tools to maintain N versions per module. This would work with the if-feature construct, in that, any features that are in effect in a given version are part of the conformance. An 'object-object' variance clause for an object within a feature only has meaning if that feature is supported by the agent. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Oct 18 23:58: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 9E5AA3A68D8; Sat, 18 Oct 2008 23:58: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 9EBC23A6919 for ; Sat, 18 Oct 2008 23:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.027, 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 tzI0hIrQDG3k for ; Sat, 18 Oct 2008 23:58:49 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B6B9F3A68D8 for ; Sat, 18 Oct 2008 23:58:48 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C5BBC0039; Sun, 19 Oct 2008 08:59:56 +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 uJ9tBy6Jg3nY; Sun, 19 Oct 2008 08:59:49 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81FE4C0019; Sun, 19 Oct 2008 08:59:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7F78E81CF7B; Sun, 19 Oct 2008 08:59:48 +0200 (CEST) Date: Sun, 19 Oct 2008 08:59:48 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20081019065948.GA27056@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group References: <48FA116E.2050505@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48FA116E.2050505@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: NETMOD Working Group Subject: Re: [netmod] object, not leafref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Sat, Oct 18, 2008 at 09:40:14AM -0700, Andy Bierman wrote: > Hi, > I was asked to propose a 'leafref' built-in data type. > Change of plans... > > The only use-case I know of for leafref is notification content. > The notification-stmt needs work, and adding > another built-in type is not the right answer. I question that assumption. Are you saying that are no references to non key objects in SMIv2 MIB modules other than notifications? I doubt that very much. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Oct 19 12:06: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 BA8843A6A75; Sun, 19 Oct 2008 12:06: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 46AB13A6A13 for ; Sun, 19 Oct 2008 12:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=-0.093, 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 NKgpzkexEAhE for ; Sun, 19 Oct 2008 12:06:14 -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 759093A67E3 for ; Sun, 19 Oct 2008 12:06:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=QK7qmsRwqSlMneL/4NKNaLGwYjEkJXBChXCt5FVjBjfBVbZJYEComiy3roBm455s; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.34.9] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KrdcW-000742-7n for netmod@ietf.org; Sun, 19 Oct 2008 15:07:20 -0400 Message-ID: <000401c9321e$103e5d20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "NETMOD Working Group" References: <48FA116E.2050505@netconfcentral.com> <20081019065948.GA27056@elstar.local> Date: Sun, 19 Oct 2008 12:08:24 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e47ba464415bc29d624d792e482d357937350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.34.9 Subject: Re: [netmod] object, not leafref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Juergen Schoenwaelder" > To: "Andy Bierman" > Cc: "NETMOD Working Group" > Sent: Saturday, October 18, 2008 11:59 PM > Subject: Re: [netmod] object, not leafref > > On Sat, Oct 18, 2008 at 09:40:14AM -0700, Andy Bierman wrote: > > Hi, > > I was asked to propose a 'leafref' built-in data type. > > Change of plans... > > > > The only use-case I know of for leafref is notification content. > > The notification-stmt needs work, and adding > > another built-in type is not the right answer. > > I question that assumption. Are you saying that are no references > to non key objects in SMIv2 MIB modules other than notifications? > I doubt that very much. ... The disman schedule (RFC 2591) and expression MIBs come to mind.... I don't know whether anyone ever intends to use netconf to configure such beasts. These MIBs have several quirks that are direct conseqneuces of the way SNMP and the SMI work. Providing equivalent functionality in a netmod world might lead to a different design, but the need to refer to specific instances of management information would remain. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Oct 19 17:55: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 6EA1E3A6852; Sun, 19 Oct 2008 17:55: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 EB4CE3A68E8 for ; Sun, 19 Oct 2008 17:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nv7k70N1Tzsl for ; Sun, 19 Oct 2008 17:55:12 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 54AC43A6852 for ; Sun, 19 Oct 2008 17:55:11 -0700 (PDT) Received: (qmail 93322 invoked from network); 20 Oct 2008 00:56:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 20 Oct 2008 00:56:20 -0000 X-YMail-OSG: L8PngCAVM1khCVA1aHOENsUQFYmuwfejsLhT79I3CJO0yG7fDWBGjz86mCh7P2iFZ36Uu3kniycJhAU_dhKKu_8wcdJho6ISkSgOahYtm9n0mSrLmvij_ZxJL5iOAoJDLkdHIcbgvfGijLLpONh1AZx7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48FBD732.3060405@netconfcentral.com> Date: Sun, 19 Oct 2008 17:56:18 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Randy Presuhn References: <48FA116E.2050505@netconfcentral.com> <20081019065948.GA27056@elstar.local> <000401c9321e$103e5d20$6801a8c0@oemcomputer> In-Reply-To: <000401c9321e$103e5d20$6801a8c0@oemcomputer> Cc: NETMOD Working Group Subject: Re: [netmod] object, not leafref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Randy Presuhn wrote: > Hi - > >> From: "Juergen Schoenwaelder" >> To: "Andy Bierman" >> Cc: "NETMOD Working Group" >> Sent: Saturday, October 18, 2008 11:59 PM >> Subject: Re: [netmod] object, not leafref >> >> On Sat, Oct 18, 2008 at 09:40:14AM -0700, Andy Bierman wrote: >>> Hi, >>> I was asked to propose a 'leafref' built-in data type. >>> Change of plans... >>> >>> The only use-case I know of for leafref is notification content. >>> The notification-stmt needs work, and adding >>> another built-in type is not the right answer. >> I question that assumption. Are you saying that are no references >> to non key objects in SMIv2 MIB modules other than notifications? >> I doubt that very much. > ... > > The disman schedule (RFC 2591) and expression MIBs come to mind.... > I don't know whether anyone ever intends to use netconf to configure such > beasts. These MIBs have several quirks that are direct conseqneuces > of the way SNMP and the SMI work. Providing equivalent functionality > in a netmod world might lead to a different design, but the need to > refer to specific instances of management information would remain. > So you think we need a leafref built-in type? Maybe we do. IMO, leafref is an unconstrained keyref. That means it is just like keyref, but it does not have to point at a config leaf, or a key leaf -- just a leaf. I don't know if it should be constrained to existing instances of the 'pointed-at' leaf, or just valid instances of the leaf. > Randy Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Oct 19 21:57:39 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8DB73A6A05; Sun, 19 Oct 2008 21:57: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 F1D4F3A6A05 for ; Sun, 19 Oct 2008 21:57:34 -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 KjYNYJZbo28n for ; Sun, 19 Oct 2008 21:57:34 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 0B3433A6967 for ; Sun, 19 Oct 2008 21:57:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=I22hZ3itE+6oUhTHijvlu07S2fksw3EmfGCrWSDg5j052t7bbSPHfG8981va5acy; 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.165.5.220] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Krmqo-0007Xu-K4 for netmod@ietf.org; Mon, 20 Oct 2008 00:58:42 -0400 Message-ID: <001001c93270$af1cdc80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "NETMOD Working Group" References: <48FA116E.2050505@netconfcentral.com> <20081019065948.GA27056@elstar.local> <000401c9321e$103e5d20$6801a8c0@oemcomputer> <48FBD732.3060405@netconfcentral.com> Date: Sun, 19 Oct 2008 21:59:50 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e43b13ea03121302cae0e70c47d2115390350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.5.220 Subject: Re: [netmod] object, not leafref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Andy Bierman" > To: "Randy Presuhn" > Cc: "NETMOD Working Group" > Sent: Sunday, October 19, 2008 5:56 PM > Subject: Re: [netmod] object, not leafref ... > So you think we need a leafref built-in type? > Maybe we do. IMO, leafref is an unconstrained keyref. > That means it is just like keyref, but it does not > have to point at a config leaf, or a key leaf -- just a leaf. > > I don't know if it should be constrained to existing > instances of the 'pointed-at' leaf, or just valid > instances of the leaf. Dunno. I *can* think of cases where it would be preferable to *not* enforce such a constraint. For example, configuring an expression/schedule like gizmo to reference something that lives on another system. It's probably more robust to define its semantics when the thing referenced (1) cannot be accessed (access control or unreachable) (2) doesn't exist (at the moment) (3) cannot exist (4) isn't a leaf But perhaps this more properly belongs to the plumbing of such gizmos, rather than to a base type. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Oct 19 22:21: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 4372E3A696E; Sun, 19 Oct 2008 22:21: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 B988E3A6A05 for ; Sun, 19 Oct 2008 22:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.027, 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 xZge4ZGmsqCE for ; Sun, 19 Oct 2008 22:21:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 933853A696E for ; Sun, 19 Oct 2008 22:21:13 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C900BC0009; Mon, 20 Oct 2008 07:22: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 SZUElEgPkhVn; Mon, 20 Oct 2008 07:22:17 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6047CC0006; Mon, 20 Oct 2008 07:22:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 91D7C81D2C6; Mon, 20 Oct 2008 07:22:16 +0200 (CEST) Date: Mon, 20 Oct 2008 07:22:16 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20081020052216.GA27708@elstar.local> Mail-Followup-To: Andy Bierman , Randy Presuhn , NETMOD Working Group References: <48FA116E.2050505@netconfcentral.com> <20081019065948.GA27056@elstar.local> <000401c9321e$103e5d20$6801a8c0@oemcomputer> <48FBD732.3060405@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48FBD732.3060405@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: NETMOD Working Group Subject: Re: [netmod] object, not leafref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Sun, Oct 19, 2008 at 05:56:18PM -0700, Andy Bierman wrote: > IMO, leafref is an unconstrained keyref. > That means it is just like keyref, but it does not > have to point at a config leaf, or a key leaf -- just a leaf. I think we need to sort out what the different constraints are we assume for a keyref and once we understand this it might be better to have a general leafref type where the keyref falls out as a special case or a subtype. /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 Oct 20 06:05: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 BF6CE3A68F5; Mon, 20 Oct 2008 06:05: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 E997E3A68C1 for ; Mon, 20 Oct 2008 06:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.237 X-Spam-Level: X-Spam-Status: No, score=-6.237 tagged_above=-999 required=5 tests=[AWL=0.012, 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 o2AlyHk1eOfg for ; Mon, 20 Oct 2008 06:05:26 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id F08EC3A6912 for ; Mon, 20 Oct 2008 06:05:25 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 703ED217AE; Mon, 20 Oct 2008 15:04:44 +0200 (CEST) X-AuditID: c1b4fb3e-a7e83bb000007a96-50-48fc81eb062e Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CF5EA2166C; Mon, 20 Oct 2008 15:04:43 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Oct 2008 15:04:43 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Oct 2008 15:04:42 +0200 Message-ID: <48FC81EA.8080201@ericsson.com> Date: Mon, 20 Oct 2008 15:04:42 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman , Randy Presuhn , NETMOD Working Group References: <48FA116E.2050505@netconfcentral.com> <20081019065948.GA27056@elstar.local> <000401c9321e$103e5d20$6801a8c0@oemcomputer> <48FBD732.3060405@netconfcentral.com> <20081020052216.GA27708@elstar.local> In-Reply-To: <20081020052216.GA27708@elstar.local> X-OriginalArrivalTime: 20 Oct 2008 13:04:42.0885 (UTC) FILETIME=[6B159B50:01C932B4] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] object, not leafref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, I see two constraints: 1) It must point to a key leaf (not an ordinary leaf) 2) The a list entry with a key leaf containing that particular key leaf with that particular value must exist Balazs Juergen Schoenwaelder wrote: > On Sun, Oct 19, 2008 at 05:56:18PM -0700, Andy Bierman wrote: > >> IMO, leafref is an unconstrained keyref. >> That means it is just like keyref, but it does not >> have to point at a config leaf, or a key leaf -- just a leaf. > > I think we need to sort out what the different constraints are we > assume for a keyref and once we understand this it might be better to > have a general leafref type where the keyref falls out as a special > case or a subtype. > > /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 Mon Oct 20 06:30: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 2D1D53A69D2; Mon, 20 Oct 2008 06:30: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 80F3E28C0E1 for ; Mon, 20 Oct 2008 06:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.026, 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 eSVNB3svv0Xy for ; Mon, 20 Oct 2008 06:30: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 1C1463A69EC for ; Mon, 20 Oct 2008 06:30:05 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5BCA7C001C; Mon, 20 Oct 2008 15:31:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MRm-nb-kb+CS; Mon, 20 Oct 2008 15:31:09 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0C548C0006; Mon, 20 Oct 2008 15:31:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5266881DE2E; Mon, 20 Oct 2008 15:30:58 +0200 (CEST) Date: Mon, 20 Oct 2008 15:30:58 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20081020133058.GA28874@elstar.local> Mail-Followup-To: Balazs Lengyel , Andy Bierman , Randy Presuhn , NETMOD Working Group References: <48FA116E.2050505@netconfcentral.com> <20081019065948.GA27056@elstar.local> <000401c9321e$103e5d20$6801a8c0@oemcomputer> <48FBD732.3060405@netconfcentral.com> <20081020052216.GA27708@elstar.local> <48FC81EA.8080201@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48FC81EA.8080201@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: NETMOD Working Group Subject: Re: [netmod] object, not leafref 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, Oct 20, 2008 at 03:04:42PM +0200, Balazs Lengyel wrote: > I see two constraints: > 1) It must point to a key leaf (not an ordinary leaf) > 2) The a list entry with a key leaf containing that particular key leaf > with that particular value must exist We had some discussion at the interim about the "must exist" property since sometimes it is perfectly valid to provision configuration for something that does not exist when it is configured but might exist at a later point in time. Phil said you can deal with this by creating a union of a keyref and a string if I recall correctly, which however makes it not obvious what is going on if you ask me. I think it will be useful to have control over the "must exist" property of a keyref and this also applies to more general leafrefs. So I like to have a general leaf reference type which is not restricted to point to keys and a keyword or so to express that the referenced leaft must exist (which I can use as needed). (I could question why it is useful to have a keyref since tools can figure out that a leafref is actually pointing to a key, but having some redundant information might help readers.) I have searched for keyref in the YANG specs and I did not see anything that could break if we replace the keyref type with a leafref type (and if needed, we can derive a keyref type from the leafref type in the common data 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 Mon Oct 20 07:03: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 79F513A69CE; Mon, 20 Oct 2008 07:03: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 5A1BD3A6A06 for ; Mon, 20 Oct 2008 07:03:00 -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 zqns487gA2ei for ; Mon, 20 Oct 2008 07:02:59 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5D6673A69CE for ; Mon, 20 Oct 2008 07:02:59 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id D3E8D76C4E9; Mon, 20 Oct 2008 16:03:53 +0200 (CEST) Date: Mon, 20 Oct 2008 16:03:53 +0200 (CEST) Message-Id: <20081020.160353.213565204.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20081020133058.GA28874@elstar.local> References: <20081020052216.GA27708@elstar.local> <48FC81EA.8080201@ericsson.com> <20081020133058.GA28874@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] object, not leafref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > I think it will be useful to have control over the "must exist" > property of a keyref +1 > and this also applies to more general leafrefs. +1 if we add leafref. > So I like to have a general leaf reference type which is not > restricted to point to keys and a keyword or so to express that the > referenced leaft must exist (which I can use as needed). > > (I could question why it is useful to have a keyref since tools can > figure out that a leafref is actually pointing to a key, but having > some redundant information might help readers.) Maybe Andy's proposed 'object' is better than 'leafref'. The 'keyref' construct is known from XSD and two proprietary DMLs. AFAIK, 'leafref' is something new, and the only use case we have seen is handled (better) with Andy's proposal. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 20 07:20: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 D10E83A69D1; Mon, 20 Oct 2008 07:20: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 3839C3A69FF for ; Mon, 20 Oct 2008 07:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.025, 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 f0sUK0Hrq-WT for ; Mon, 20 Oct 2008 07:20:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7B8143A69D1 for ; Mon, 20 Oct 2008 07:20:39 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 42D5AC000D; Mon, 20 Oct 2008 16:21:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iFwbwUd5duTX; Mon, 20 Oct 2008 16:21:42 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA653C0008; Mon, 20 Oct 2008 16:21:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2BC4681DF3E; Mon, 20 Oct 2008 16:21:42 +0200 (CEST) Date: Mon, 20 Oct 2008 16:21:41 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20081020142141.GA28942@elstar.local> Mail-Followup-To: Martin Bjorklund , balazs.lengyel@ericsson.com, netmod@ietf.org References: <20081020052216.GA27708@elstar.local> <48FC81EA.8080201@ericsson.com> <20081020133058.GA28874@elstar.local> <20081020.160353.213565204.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20081020.160353.213565204.mbj@tail-f.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] object, not leafref 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, Oct 20, 2008 at 04:03:53PM +0200, Martin Bjorklund wrote: > The 'keyref' construct is known from XSD and two proprietary DMLs. > AFAIK, 'leafref' is something new, and the only use case we have seen is > handled (better) with Andy's proposal. So you agree with Andy that we will never have to refer to a leaf that his not a key? I am still not convinced... /js PS: To some extend, keyref is a misnomer since for complex keys, a keyref is just refering to a part of a key. So keyref is really a 'partialkeyref'. ;-) -- 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 Oct 20 08:04: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 6A9943A69BC; Mon, 20 Oct 2008 08:04: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 4EF8E3A69FF for ; Mon, 20 Oct 2008 08:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5PIEextX5CJ for ; Mon, 20 Oct 2008 08:04:21 -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 987DE3A69BC for ; Mon, 20 Oct 2008 08:04:21 -0700 (PDT) Received: (qmail 36129 invoked from network); 20 Oct 2008 15:05:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 20 Oct 2008 15:05:31 -0000 X-YMail-OSG: .HNAch8VM1npW3g1uf5ujYIpE7RfczJFRdcX4qZAwNKF0bk1LZTSaBgqQBa7ueE1ELZsSMhG8HyMU4Hat3dn16tdVQs_Smw9xQ8wF_TpK_1vLTdh8AGcaDLS2cnm6mqbh8U- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48FC9E39.3010309@netconfcentral.com> Date: Mon, 20 Oct 2008 08:05:29 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund , balazs.lengyel@ericsson.com, netmod@ietf.org References: <20081020052216.GA27708@elstar.local> <48FC81EA.8080201@ericsson.com> <20081020133058.GA28874@elstar.local> <20081020.160353.213565204.mbj@tail-f.com> <20081020142141.GA28942@elstar.local> In-Reply-To: <20081020142141.GA28942@elstar.local> Subject: Re: [netmod] object, not leafref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Mon, Oct 20, 2008 at 04:03:53PM +0200, Martin Bjorklund wrote: > >> The 'keyref' construct is known from XSD and two proprietary DMLs. >> AFAIK, 'leafref' is something new, and the only use case we have seen is >> handled (better) with Andy's proposal. > > So you agree with Andy that we will never have to refer to a leaf that > his not a key? I am still not convinced... > I did not say there are no other use cases. One monitoring-related use would be statistics broken out by some metric, which happens to be a leaf in some 'static' record. For example, consider a classic database application with a record called 'person', that has a 'zipcode' column. The company may want to know the geographical distribution of its employees, so it maintains a list indexed by zipcode. list employee-distribution { key zipcode; leaf zipcode { type leafref { path "/person/address/zipcode"; } } leaf count { type uint32; } } This is a true leaf ref (foreign key), since only the zipcodes which have employees living in them are of interest, and only those instances of zipcode are valid/relevant. I think leafref will show up in data models once in awhile. If we had to pick just one, I would go with leafref over keyref, since it covers every use-case. > /js > > PS: To some extend, keyref is a misnomer since for complex keys, a > keyref is just refering to a part of a key. So keyref is really > a 'partialkeyref'. ;-) > We discussed this at the meeting (when I asked if any missing predicates are allowed for a list-in-list example. Martin said no -- the XPath must identify one instance of the 'outside' list, otherwise the keyref (or leafref) value would be ambiguous. We need to nail down the details on keyref/leafref, or at least identify the aspects that are open to implementation choice. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 20 09:02: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 ED3C93A6A06; Mon, 20 Oct 2008 09:02: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 D6E563A6A06 for ; Mon, 20 Oct 2008 09:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.011, 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 bywZ+veqXkuC for ; Mon, 20 Oct 2008 09:02:28 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 14BF63A68B5 for ; Mon, 20 Oct 2008 09:02:28 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 02C722190E; Mon, 20 Oct 2008 18:03:39 +0200 (CEST) X-AuditID: c1b4fb3e-a7e83bb000007a96-67-48fcabda13e5 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D563A217D1; Mon, 20 Oct 2008 18:03:38 +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, 20 Oct 2008 18:03:38 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Oct 2008 18:03:38 +0200 Message-ID: <48FCABD9.5050904@ericsson.com> Date: Mon, 20 Oct 2008 18:03:37 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund , balazs.lengyel@ericsson.com, netmod@ietf.org References: <20081020052216.GA27708@elstar.local> <48FC81EA.8080201@ericsson.com> <20081020133058.GA28874@elstar.local> <20081020.160353.213565204.mbj@tail-f.com> <20081020142141.GA28942@elstar.local> In-Reply-To: <20081020142141.GA28942@elstar.local> X-OriginalArrivalTime: 20 Oct 2008 16:03:38.0142 (UTC) FILETIME=[69CBD3E0:01C932CD] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] object, not leafref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, I see a use case for leafrefs in rpc/output parameters as well. Balazs Juergen Schoenwaelder wrote: > On Mon, Oct 20, 2008 at 04:03:53PM +0200, Martin Bjorklund wrote: > >> The 'keyref' construct is known from XSD and two proprietary DMLs. >> AFAIK, 'leafref' is something new, and the only use case we have seen is >> handled (better) with Andy's proposal. > > So you agree with Andy that we will never have to refer to a leaf that > his not a key? I am still not convinced... > > /js > > PS: To some extend, keyref is a misnomer since for complex keys, a > keyref is just refering to a part of a key. So keyref is really > a 'partialkeyref'. ;-) > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 20 09:50: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 6F6023A67AF; Mon, 20 Oct 2008 09:50: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 A3EA83A67AF for ; Mon, 20 Oct 2008 09:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmtqfnHixm8L for ; Mon, 20 Oct 2008 09:50:23 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id F31DB3A67AC for ; Mon, 20 Oct 2008 09:50:22 -0700 (PDT) Received: (qmail 91047 invoked from network); 20 Oct 2008 16:51:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 20 Oct 2008 16:51:06 -0000 X-YMail-OSG: XTXMS3YVM1koh7cnwImfbhD_MPSOXM3uBiIxU22MboP22cBuQ8e7vN9VWx09391zo.ouX6uIDSfbfY9S5Ltl2cEzPPmOEr1xEMuhQDat2gE_4pso3P7DGdfhJ.WrKWNpV7l4wWr3c46SsJ4sPtpjMvA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48FCB6F8.1010403@netconfcentral.com> Date: Mon, 20 Oct 2008 09:51:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] YANG errors, 12.2, 12.3 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I do not agree with the text in 12.2 and 12.3 that says the too-many-elements and too-few-elements are generated once per list node (should also mention leaf-list node). This is an implementation CLR. IMO, it would be better to identify the nodes that are causing the error. In code, it is natural to generate the error when each child count (list or leaf-list) is checked against the parent. I prefer to generate one for each child object that caused the error, and identify it with a 'bad-element' in the error-info. The errors in 12.2 and 12.3 should work the same as the unique error in 12.1. The agent MUST report at least one instance, and MAY choose to report more instances of these errors for the same parent node (identified in the error-path). Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 20 09:53: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 8A8933A6A99; Mon, 20 Oct 2008 09:53: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 8CCBF3A6AA3 for ; Mon, 20 Oct 2008 09:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.163, 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 mzLyL2yrkZEe for ; Mon, 20 Oct 2008 09:53:48 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B9FDA3A6A99 for ; Mon, 20 Oct 2008 09:53:48 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id DDB8976C4E9; Mon, 20 Oct 2008 18:54:50 +0200 (CEST) Date: Mon, 20 Oct 2008 18:54:46 +0200 (CEST) Message-Id: <20081020.185446.108468486.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48FCB6F8.1010403@netconfcentral.com> References: <48FCB6F8.1010403@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] YANG errors, 12.2, 12.3 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > I do not agree with the text in 12.2 and 12.3 that says the > too-many-elements and too-few-elements are generated once > per list node (should also mention leaf-list node). > > This is an implementation CLR. > > IMO, it would be better to identify the nodes that are > causing the error. How do you know which nodes are causing the error in a or ? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 20 10:18: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 890363A6AA3; Mon, 20 Oct 2008 10:18: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 AE06D3A6AA3 for ; Mon, 20 Oct 2008 10:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrJurwQUrfHk for ; Mon, 20 Oct 2008 10:18:20 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 0DFAB3A69F5 for ; Mon, 20 Oct 2008 10:18:19 -0700 (PDT) Received: (qmail 6617 invoked from network); 20 Oct 2008 17:19:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 20 Oct 2008 17:19:30 -0000 X-YMail-OSG: EmPadggVM1nLT1719YPxbEar6Ng5olx7Xp3kHGflUHFDthJ.Q8ea7QLoelPcXSXaG5Xru9f48srlUHdjGGVrZFEvDgEe5HuqeB.uIQwZhoDp2g5Xf8yXhkoCzcxAC_ahFGbX_17ZRDsHMj3QZ_qOxOtA X-Yahoo-Newman-Property: ymail-3 Message-ID: <48FCBDA0.8060303@netconfcentral.com> Date: Mon, 20 Oct 2008 10:19:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <48FCB6F8.1010403@netconfcentral.com> <20081020.185446.108468486.mbj@tail-f.com> In-Reply-To: <20081020.185446.108468486.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] YANG errors, 12.2, 12.3 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> I do not agree with the text in 12.2 and 12.3 that says the >> too-many-elements and too-few-elements are generated once >> per list node (should also mention leaf-list node). >> >> This is an implementation CLR. >> >> IMO, it would be better to identify the nodes that are >> causing the error. > > How do you know which nodes are causing the error in a or > ? > I see what you mean. These errors are specialized for the min-elements and max-elements clauses, which appear in the list or leaf-list definition. The term 'child nodes' in those sections is misleading. You mean the list or leaf-list node. There is no parent, no child -- just sibling nodes. I think these errors also apply to a missing mandatory leaf (too-few-elements) or extra instances of a leaf (too-many-elements). In that case, the error-path should identify the missing child (1 error), or any instance of an extra child (1 error). So I was wrong -- the current text is OK for min/max elements. But what about expanding it to cover these other 2 cases? > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 20 12:10: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 C92CD3A6780; Mon, 20 Oct 2008 12:10: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 2DE783A6780 for ; Mon, 20 Oct 2008 12:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=0.155, 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 dhKrGGg06T5x for ; Mon, 20 Oct 2008 12:10:12 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 34E473A6839 for ; Mon, 20 Oct 2008 12:10:12 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id E6C6876C4E9; Mon, 20 Oct 2008 21:04:28 +0200 (CEST) Date: Mon, 20 Oct 2008 21:04:28 +0200 (CEST) Message-Id: <20081020.210428.210946781.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48FCBDA0.8060303@netconfcentral.com> References: <48FCB6F8.1010403@netconfcentral.com> <20081020.185446.108468486.mbj@tail-f.com> <48FCBDA0.8060303@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] YANG errors, 12.2, 12.3 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > I think these errors also apply to a missing mandatory leaf > (too-few-elements) I'm using the standard 'missing-element' for this one. > or extra instances of a leaf (too-many-elements). Hmm... how would such a leaf be created? A 'create' operation on a leaf that already exists will fail with 'data-exists'. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 20 12:21:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96873A6A2A; Mon, 20 Oct 2008 12:21:20 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E63F3A6A2A for ; Mon, 20 Oct 2008 12:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-5o5Pr0h-Bw for ; Mon, 20 Oct 2008 12:21:15 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 2F78D3A6B05 for ; Mon, 20 Oct 2008 12:21:14 -0700 (PDT) Received: (qmail 19114 invoked from network); 20 Oct 2008 19:22:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 20 Oct 2008 19:22:24 -0000 X-YMail-OSG: bLZjPGEVM1k0.Of5n2nuTX_FbCu3WtTRF4MxfBJWHomLqtqH9AIF4kssf_9M6Q64FlmFTUmpFnOdNUpd8mheY1fQfbrC0PezgVRi2afdFJc3T4Bz.M.KI9SXXSlEaPzRUf3ACHo1_iS9BLqsrtlTDyJM X-Yahoo-Newman-Property: ymail-3 Message-ID: <48FCDA6F.9040901@netconfcentral.com> Date: Mon, 20 Oct 2008 12:22:23 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <48FCB6F8.1010403@netconfcentral.com> <20081020.185446.108468486.mbj@tail-f.com> <48FCBDA0.8060303@netconfcentral.com> <20081020.210428.210946781.mbj@tail-f.com> In-Reply-To: <20081020.210428.210946781.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] YANG errors, 12.2, 12.3 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> I think these errors also apply to a missing mandatory leaf >> (too-few-elements) > > I'm using the standard 'missing-element' for this one. > me too >> or extra instances of a leaf (too-many-elements). > > Hmm... how would such a leaf be created? A 'create' operation on a > leaf that already exists will fail with 'data-exists'. > if duplicate leafs are in the edit-config 'create', and no leaf exists in the target config. IMO, this is also something that the candidate does not have to check until the is done. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sat Oct 25 08:43:49 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 530643A6899; Sat, 25 Oct 2008 08:43:49 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 774993A6A1A for ; Sat, 25 Oct 2008 08:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cOFqbo8o7zO for ; Sat, 25 Oct 2008 08:43:46 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id C3EB33A6899 for ; Sat, 25 Oct 2008 08:43:46 -0700 (PDT) Received: (qmail 77693 invoked from network); 25 Oct 2008 15:45:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 25 Oct 2008 15:45:09 -0000 X-YMail-OSG: P0vTJRYVM1lYU4EEkAGPhsUEYyD6gPMRamTBaJGFCS4YN.eYASdqeIXS0mm116GN5_mHNJUPpia6kn7BzdkUE4DTaJ8yq8CdLlKrXgIbq.yy5PTgoLRenwY1Ydz3qD1b078- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49033F03.40402@netconfcentral.com> Date: Sat, 25 Oct 2008 08:45:07 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] canonical data type representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I think the YANG draft should add a short section after each 'Lexicographic Representation' section, defining the canonical format for value-space comparison. There is (hopefully) a single authoritative reference that can be used for each 'borrowed' data type, like string, float32, binary (base64), int32, etc. The custom type 'bits' needs to specify a canonical order, which is the xsd:list representation of each set bit name, in some order -- is it the bit-stmt order, or the order specified by the value of each position val? (Pick 1) An enum can be any string (with no leading or trailing WSP). Enum comparisons must use the same normalization rules as the 'string' data type. For leaf-list and list, canonical ordering could be considered out of scope. That is, system-ordered means internal system, not standardized system. (OK with me). The agent is free to return entries in natural order. Within a list or container entry, there might be canonical ordering to consider, or not. I keep entries in schema order, except for key leafs moved to the front, in key-stmt order. A choice/case does not show up in the instance document, but a canonical order, based on schema order, could be used for siblings within each case-stmt. The number 1 priority is that NETMOD not re-invent any standards for data type normalization. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Oct 26 02:48: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 212013A68A6; Sun, 26 Oct 2008 02:48: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 40C513A6A00 for ; Sun, 26 Oct 2008 02:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.023, 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 u2kjdf+wtVR6 for ; Sun, 26 Oct 2008 02:48:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C75073A68A6 for ; Sun, 26 Oct 2008 02:48:44 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D0D5DC0011 for ; Sun, 26 Oct 2008 10:50:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id em7D94-Rr62P; Sun, 26 Oct 2008 10:50:03 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BEBABC0015; Sun, 26 Oct 2008 10:50:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8DCC682A514; Sun, 26 Oct 2008 10:50:03 +0100 (CET) Date: Sun, 26 Oct 2008 10:50:03 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20081026095003.GA2622@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [netmod] types-011: multiple lexical representations 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 Some types allow multiple representations of the same value. A good example are IPv6 addresses, e.g. ::1 and 0:0:0:0:0:0:0:1. This raises several questions: 1) We need to define how comparisions are done. At the interim, there was agreement that comparisons are done in the value space so the fact that there might be different lexical representations for the same value becomes a non-issue. (This needs to be confirmed on the mailing list.) 2) At the interim meeting, there was agreement to define normalization rules - the basic idea here is the following: a) implementations MUST accept normalized values as input b) implementations MUST generate normalized values as output c) implementations MAY accept non-normalized values as input In general, it was preferred that implementations do not have to remember the representation that was used to configure a value. It should be sufficient to just store the value. (This needs to be confirmed on the mailing list.) 3) There was no agreement how we write down normalization rules are the interim meeting. There are several options: (1) we simply add text to description statements (2) we introduce a separate statement with a separate description clause, e.g. normalization { description "turn all characters to lower case"; } (3) we introduce a separate statement with a separate description clause and allow an additional pattern that can be more restrictive for normalized values, e.g. normalization { pattern "[a-z]"; description "normalized representation is in lower case"; } In option (1) and (2), it remains unclear whether the retrictions (pattern etc.) associated with a type only cover the normalized representation or also other representations that implementations MAY allow. One option is to simply just define what MUST be allowed and leave everything else to the Postel principle (implementations may be lenient in what they accept). This will work for several types, but might not work for all of them. 4) I got the task to go over all definitions in the -type document to identify types that may need normalization rules. I have done that and for each type we need to decide between the following options: (i) we further restrict the lexical space so that we have a 1:1 mapping of the lexical representation to the value space (ii) we define what the normalization rules are * date-and-time: 2008-10-26T10:35:00Z 2008-10-26T10:35:00+00:00 * ipv4-address: numeric versus textual zone index * ipv6-address: shortened and mixed forms, zone index * ipv4-prefix: unused bits (127.0.0.0/8 vs. 127.1.2.3/8) * ipv6-prefix: shortened and mixed forms, unused bits * domain-name: lower-case normalization, make this mandatory like in the uri description statement? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Oct 26 11:08:18 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF543A681A; Sun, 26 Oct 2008 11:08:18 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6248B3A6A0A for ; Sun, 26 Oct 2008 11:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=-1.283, 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 0dqF76bkNVYI for ; Sun, 26 Oct 2008 11:08:16 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 95EBA3A681A for ; Sun, 26 Oct 2008 11:08:16 -0700 (PDT) Received: (qmail 1295 invoked from network); 26 Oct 2008 18:09:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 26 Oct 2008 18:09:42 -0000 X-YMail-OSG: QWj1NZIVM1n2noXY1MJF_cL5uSnQnrds7XF0PdK863yL.sNE5Xg8KwRMIuvIdgPE8PlmKC6stHuaXsAcOKi_pXW6braP2FFJkQ409o9kQopPHq2WiJn6l.JE2yHumXHtmrw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4904B264.7070503@netconfcentral.com> Date: Sun, 26 Oct 2008 11:09:40 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] default statement for binary data type X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, A default for a binary data type is probably never going to happen, but it is legal YANG. Is it worth the bother to use a different syntax other than base64 for the default-stmt? The base64 encoding is unreadable and unwritable by humans. Should we use the hexadecimal notation defined in 8.1.1 for binary strings as well as numbers? Maybe a different start sequence than '0x' to make it easier to distinguish a binary number from a binary string? Currently allowed: leaf dead-mem-marker { type uint64; default 0xdeadbeef; } Why not also allow: leaf dead-mem-marker { type binary; default 0xaa55deadbeefaa55; } The draft (8.7.1) needs to say how a binary default-stmt is encoded. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Sun Oct 26 13:45:45 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A2733A68A0; Sun, 26 Oct 2008 13:45:45 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FCB73A68A0 for ; Sun, 26 Oct 2008 13:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVHWo09PS2jE for ; Sun, 26 Oct 2008 13:45:43 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 87A303A6892 for ; Sun, 26 Oct 2008 13:45:43 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 07A6D76C502; Sun, 26 Oct 2008 21:47:09 +0100 (CET) Date: Sun, 26 Oct 2008 21:44:35 +0100 (CET) Message-Id: <20081026.214435.162576150.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4904B264.7070503@netconfcentral.com> References: <4904B264.7070503@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] default statement for binary data type X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > Hi, > > A default for a binary data type is probably > never going to happen, but it is legal YANG. > Is it worth the bother to use a different syntax > other than base64 for the default-stmt? > > The base64 encoding is unreadable and unwritable by humans. > Should we use the hexadecimal notation defined in 8.1.1 > for binary strings as well as numbers? Maybe a different > start sequence than '0x' to make it easier to distinguish > a binary number from a binary string? We can use the same hexadecimal syntax if we disallow the base64 syntax for defaults. If we allow both, we need to use some othe prefix for hex, since e.g. "0x11" is a valid base64 encoding. > The draft (8.7.1) needs to say how a binary default-stmt > is encoded. Currently, the draft only allows the base64 alos in defaults. The draft says: The lexicographic representation of a value of a certain type is used in the XML encoding over NETCONF, and when specifying default values in a YANG module. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 27 01:33:38 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C5673A677E; Mon, 27 Oct 2008 01:33:38 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0DC23A689B for ; Mon, 27 Oct 2008 01:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRXYORb8svno for ; Mon, 27 Oct 2008 01:33:36 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CD2773A677E for ; Mon, 27 Oct 2008 01:33:35 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 44FFB2052D for ; Mon, 27 Oct 2008 09:33:34 +0100 (CET) X-AuditID: c1b4fb3e-af787bb00000537b-fb-49057cded614 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 37AE820277 for ; Mon, 27 Oct 2008 09:33:34 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 09:32:10 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 09:32:10 +0100 Content-Disposition: inline From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Mon, 27 Oct 2008 09:32:09 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Message-Id: <200810270932.09693.david.partain@ericsson.com> X-OriginalArrivalTime: 27 Oct 2008 08:32:10.0182 (UTC) FILETIME=[81016660:01C9380E] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Proposed consensus mail on yang-01253 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 Greetings, This is a call for consensus about issue 'yang-01253: adding "leafref" type'. See the wiki at http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-01253 This mail and other consensus calls after the interim will follow a similar pattern. First, we have the question and the proposed consensus, then details. The details include examples, followed by a summary of the interim discussion on the issues. Please read the whole message. PLEASE speak up if you favor or object to the proposed change, including people who attended the interim. Silence is impossible to interpret. The proposal is to add a new type 'leafref', which works like a 'keyref', but points to any leaf. = Questions: 1. Should we add 'leafref'? Interim consensus: yes 2. Should 'leafref' be 'config false'? Interim consensus: yes 3. Should 'leafref' be fully instantiated or are wildcards allowed? Interim consensus: fully instantiated A bit more detail... The following questions were discussed: 'leafref' is a way to "borrow" a column from elsewhere, to be able to point at things that aren't keys. Applicability is more for monitoring than configuration. At the interim, everyone in the room was in favor of adding leafref. Should 'leafref' be 'config false'? The consensus of the room was that it must be. Should we allow wildcards or should it be fully instantiated? The rough consensus was that it should be fully instantiated, but J. Sch=F6nw=E4lder remains unconvinced. He worried about not allowing things because we can't come up with an example. Andy Bierman will provide text for 'leafref' and send it to the mailing list. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 27 03:00: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 D56843A67D9; Mon, 27 Oct 2008 03:00: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 248893A67FF for ; Mon, 27 Oct 2008 03:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsxnvZjUPhwS for ; Mon, 27 Oct 2008 03:00:43 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0114D3A67D9 for ; Mon, 27 Oct 2008 03:00:42 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8935620658 for ; Mon, 27 Oct 2008 11:00:39 +0100 (CET) X-AuditID: c1b4fb3e-acf82bb00000537b-29-490591479ef4 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 66B5E20573 for ; Mon, 27 Oct 2008 11:00:39 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 11:00:38 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 11:00:38 +0100 Content-Disposition: inline From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Mon, 27 Oct 2008 11:00:37 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Message-Id: <200810271100.38001.david.partain@ericsson.com> X-OriginalArrivalTime: 27 Oct 2008 10:00:38.0161 (UTC) FILETIME=[DCCEB810:01C9381A] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Proposed consensus mail on yang-00172 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings, Hope the table below works. You may have to use a fixed-width font. This is a call for consensus about issue 'yang-00172: clarifications for ordered-by, must, unique, keyref, when, mandatory, minmax, etc'. See the wiki at http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00172 for an introduction. This mail documents the conversations at the interim for proposed changes / clarifications in text in the YANG document. As such, the question is whether you agree with the interpretation that this text intends to document. There are no new features being proposed. PLEASE speak up if you favor the changes or object to the text (including people who attended the interim). Question that started the discussion: What does 'ordered-by user;' mean for read-only data or RPC input or notification content? This question is broader and the table below says when the various statements are relevant or not. config config RPC RPC Notifi- Enforced true false input output cation at commit ---------------------------------------------------------------- ordered-by | OK | i | OK | i | i | N unique | OK | OK | OK | OK | OK | Y must(1) | OK | OK | OK | OK | OK | Y keyref | OK | OK | OK(2)| OK(2)| OK(2)| Y when(1) | OK | OK | OK | OK | OK | N mandatory | OK | OK | OK | OK | OK | Y max/max-elems | OK | OK | OK | OK | OK | Y All of these are constraints, and the question is when that constraint is enforced. Key: i - ignored (1) must, when - the XPath context varies, and we'll have to document all of this for all of the different columns. (2) restrictions: the target of the XPath expression refers to the running config or to status data. The interim meeting spent some time talking about the differences between when and must. Phil Shafer's definitions: 'when' - The parent schema node is ignored unless the 'when' expression is satisfied. If the expression becomes false, any data associated with the node is automatically deleted. (Editor: deleted from what? from the response? from the config database? Not entirely sure. Phil?) 'must' - If the parent node exists in the database, the 'must' expression must be true. If the expression is false, an error condition exists. Enforced at commit time. Do you agree with the definitions above? There was a long discussion about when a 'when' expression is evaluated. The rough consensus of the room was that 'when' constraints should be enforced in the candidate configuration, whereas 'must' is enforced first when committing in the running configuration. Phil Shafer will write some text about a hierarchy of constraints where mandatory can be applied underneath a 'when'. Conditions on parents affect or negate constraints on children. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 27 07:40:57 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C843A6B53; Mon, 27 Oct 2008 07:40:57 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059FF3A6B37 for ; Mon, 27 Oct 2008 07:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO9bm34LC4Ud for ; Mon, 27 Oct 2008 07:40:55 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id F10D73A6B53 for ; Mon, 27 Oct 2008 07:40:54 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 63AD0616004; Mon, 27 Oct 2008 15:40:53 +0100 (CET) Date: Mon, 27 Oct 2008 15:40:31 +0100 (CET) Message-Id: <20081027.154031.247915635.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48FA1DC7.6010509@netconfcentral.com> References: <48FA1DC7.6010509@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] data model 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, Andy Bierman wrote: > // all the module definitions > > conformance 2008-10-18 { > uses-import x { > version 2007-10-17; > } Is the idea that the construct above is used instead of import by revision? I.e. if you would have used import by revision for a certain module, you propose that this construct is used instead? Is the argument to conformance above just a string? Can I do: conformance full { uses-import x { version 2007-10-17; } } conformance read-only { uses-import x { version 2007-10-17; } object-variance /top { config false; } } > The exact ABNF is TBD, but the conformance statement is > what a WG would agree on before publishing a DM version. > The syntax may end up similar to the deviation-stmt, > but reporting agent implementation non-conformance > is a different problem that agreeing on minimum > conformance requirements for a standard data model. Agreed. So if an agent claims conformance to the 'read-only' conformance level above, it would not use any deviation statements, right? deviation is still used for when you break some of the standardized conformance levels. > All readers and tools would know which versions > of all modules involved for each published revision > of each module. There is no ripple effect, since the > import-stmt never needs to be edited. But don't you just move the problem? From the import statement to the conformance section. If you need to use a new version of an imported module, you have to modify the conformance sections. I don't see how this proposal makes handling multiple revisions easier, and I also think it a bit unintuitive to specify which version is imported in the conformance level. This makes it possible to import different versions in different levels. > This would work with the if-feature construct, in that, > any features that are in effect in a given version > are part of the conformance. An 'object-object' variance > clause for an object within a feature only has meaning > if that feature is supported by the agent. I like this. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 27 08: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 DF0653A6915; Mon, 27 Oct 2008 08: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 B4E343A6905 for ; Mon, 27 Oct 2008 08:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlY6nUle78wA for ; Mon, 27 Oct 2008 08:12:35 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id D8ADD3A67A1 for ; Mon, 27 Oct 2008 08:12:35 -0700 (PDT) Received: (qmail 2132 invoked from network); 27 Oct 2008 15:12:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 27 Oct 2008 15:12:33 -0000 X-YMail-OSG: SHaLMPgVM1mQCskDZLMs5Rs0BCHhaU3mgqg78Hwe5DSjMwe36uuC1MzVAHvww0CODFgCKz31zafTz4T8q.2cUcgt4qJFbOtc0tRGMF8rZYfA0JAcLgqA0pdKWq.kCh0lghZn4NODAZHGpm7MFTtA_cDT X-Yahoo-Newman-Property: ymail-3 Message-ID: <4905DA5F.5010104@netconfcentral.com> Date: Mon, 27 Oct 2008 08:12:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <48FA1DC7.6010509@netconfcentral.com> <20081027.154031.247915635.mbj@tail-f.com> In-Reply-To: <20081027.154031.247915635.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] data model conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> // all the module definitions >> >> conformance 2008-10-18 { >> uses-import x { >> version 2007-10-17; >> } > > Is the idea that the construct above is used instead of import by > revision? I.e. if you would have used import by revision for a > certain module, you propose that this construct is used instead? > > Is the argument to conformance above just a string? Can I do: > > conformance full { > uses-import x { > version 2007-10-17; > } > } > > conformance read-only { > uses-import x { > version 2007-10-17; > } > object-variance /top { > config false; > } > } > Not sure which would work best: 1) named conformance sections that get modified each release 2) 1 unnamed conformance section that gets modified each release 3) 1 conformance section for each published release; the old ones get kept around (like the old revision statements) >> The exact ABNF is TBD, but the conformance statement is >> what a WG would agree on before publishing a DM version. >> The syntax may end up similar to the deviation-stmt, >> but reporting agent implementation non-conformance >> is a different problem that agreeing on minimum >> conformance requirements for a standard data model. > > Agreed. So if an agent claims conformance to the 'read-only' > conformance level above, it would not use any deviation statements, > right? deviation is still used for when you break some of the > standardized conformance levels. > correct >> All readers and tools would know which versions >> of all modules involved for each published revision >> of each module. There is no ripple effect, since the >> import-stmt never needs to be edited. > > But don't you just move the problem? From the import statement to the > conformance section. If you need to use a new version of an imported > module, you have to modify the conformance sections. > yes, sort of. If multiple concurrent conformance sections are allowed, then import-by-revision is actually better, because it does not allow different revisions of an external module for different conformance levels. IMO, the entire import/include by revision needs to be tossed and a different, must less permissive, and much less complex mechanism for identifying the contents of a specific release needs to be used. I only liked import-by-revision better than listing the leafs that are required for a conformance level, because I thought import-by-revision could be made to work without N versions of every identifier used in the system. But it can't, and managing all the revision ripple for modules published in RFCs is going to be a non-trivial workload in itself. > I don't see how this proposal makes handling multiple revisions > easier, and I also think it a bit unintuitive to specify which version > is imported in the conformance level. This makes it possible to > import different versions in different levels. > I think you are right. Nothing short of listing the leafs (somehow, e.g., GROUPs) and the variance allowed for particular leafs, is going to work -- except if typedefs and groupings cannot be semantically altered after first publication. Listing the leafs for a conformance level is always going to be more verbose than simply omitting the info. But I prefer to be able to inspect the contents of a YANG module with simple tools like a text reader or a WEB browser. If I have to rely on custom tools to tell me what is in any particular YANG module version, those tools may not always be available, or if they have bugs, they will be relied on anyway. >> This would work with the if-feature construct, in that, >> any features that are in effect in a given version >> are part of the conformance. An 'object-object' variance >> clause for an object within a feature only has meaning >> if that feature is supported by the agent. > > I like this. > > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 27 08:59: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 6512B3A6AAB; Mon, 27 Oct 2008 08:59: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 753BC3A6AFF for ; Mon, 27 Oct 2008 08:59: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 BxI0KOc8D4CQ for ; Mon, 27 Oct 2008 08:59:46 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 2835528C14A for ; Mon, 27 Oct 2008 08:59:39 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Mon, 27 Oct 2008 08:58:27 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 08:59:05 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 08:59:05 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 08:59:04 -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 m9RFwxM49752; Mon, 27 Oct 2008 08:58:59 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m9RFsLou035401; Mon, 27 Oct 2008 15:54:21 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200810271554.m9RFsLou035401@idle.juniper.net> To: Andy Bierman In-reply-to: <4905DA5F.5010104@netconfcentral.com> Date: Mon, 27 Oct 2008 11:54:21 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 Oct 2008 15:59:04.0500 (UTC) FILETIME=[EF959F40:01C9384C] Cc: netmod@ietf.org Subject: Re: [netmod] data model 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: , 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: >Martin Bjorklund wrote: >> But don't you just move the problem? From the import statement to the >> conformance section. If you need to use a new version of an imported >> module, you have to modify the conformance sections. >yes, sort of. >If multiple concurrent conformance sections are allowed, >then import-by-revision is actually better, because it >does not allow different revisions of an external module >for different conformance levels. I concur that you aren't fixing anything with this new syntax, just moving the revision from the import/include to a section of the module that's less directly tied to the import/include. Will conformance sections be allowed to list differing revisions? Will this somehow be less complex? >IMO, the entire import/include by revision needs to be tossed >and a different, must less permissive, and much less complex >mechanism for identifying the contents of a specific release >needs to be used. Less permissive? Import by revision is strict and exact. This is a good thing. >But I prefer to be able to inspect the contents of >a YANG module with simple tools like a text reader >or a WEB browser. If I have to rely on custom tools >to tell me what is in any particular YANG module version, >those tools may not always be available, or if they have bugs, >they will be relied on anyway. This argument of buggy custom tools is a red herring. You can read YANG modules as text files in any tool, and YANG is unlikely to cure all bugs in all software. If you import a specific revision of a module, discovering that module's contents is a pretty easy job. On the other hand, it is a difficult taks to perform as a post mortem, trying to dig into a module that imports an unknown revision of a second module and trying to understand what the original author intended and if (when) it matters that I use a more modern revision. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 27 13:18: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 E60C23A680D; Mon, 27 Oct 2008 13:18: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 C43593A6BA8 for ; Mon, 27 Oct 2008 13:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwxEnet3vrwl for ; Mon, 27 Oct 2008 13:18:12 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B43BF3A6B95 for ; Mon, 27 Oct 2008 13:18:11 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id F0BF6616006; Mon, 27 Oct 2008 21:18:09 +0100 (CET) Date: Mon, 27 Oct 2008 21:18:06 +0100 (CET) Message-Id: <20081027.211806.219004300.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4905DA5F.5010104@netconfcentral.com> References: <48FA1DC7.6010509@netconfcentral.com> <20081027.154031.247915635.mbj@tail-f.com> <4905DA5F.5010104@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] data model 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, Wouldn't it work if we do import by revision, and add your conformance statement minus uses-import? There can be multiple conformance statements, specifying different conformance levels. The conformance level is advertised in the hello message. If no conformance level is advertised, the agent claims full conformance to all features it advertises. Each conformance level specify the 'object-variance' for each leaf / subtree it modifies: conformance partial { description "Devices that cannot modify XXX in their hardware may claim partial conformance."; object-variance "/top/foo/bar" { config false; } object-variance "/top/foo/baz" { config false; } } conformance read-only { // the entire module is read only on this conformance level object-variance "/top" { config false; } } /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Mon Oct 27 13:51: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 3B6B13A6849; Mon, 27 Oct 2008 13:51: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 B97B13A6BCF for ; Mon, 27 Oct 2008 13:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poT7Uo7cyyXG for ; Mon, 27 Oct 2008 13:51:19 -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 22B353A6BCD for ; Mon, 27 Oct 2008 13:51:12 -0700 (PDT) Received: (qmail 60420 invoked from network); 27 Oct 2008 20:51:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 27 Oct 2008 20:51:10 -0000 X-YMail-OSG: Z4xRIFUVM1k646adKTCr5rBdl7_DJdzEp82ufCZDdmq0CPyhu3BNnErHAfRkn1XcBr_wqpgXhh5UXIFGSpH.7etJkXhSt8nEz5LUbRvzwp4NKr_OBmeiFn4DWrArdSOQzEg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <490629BC.2050407@netconfcentral.com> Date: Mon, 27 Oct 2008 13:51:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <48FA1DC7.6010509@netconfcentral.com> <20081027.154031.247915635.mbj@tail-f.com> <4905DA5F.5010104@netconfcentral.com> <20081027.211806.219004300.mbj@tail-f.com> In-Reply-To: <20081027.211806.219004300.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] data model conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > Wouldn't it work if we do import by revision, and add your conformance > statement minus uses-import? > > There can be multiple conformance statements, specifying different > conformance levels. The conformance level is advertised in the hello > message. If no conformance level is advertised, the agent claims full > conformance to all features it advertises. > > Each conformance level specify the 'object-variance' for each leaf / > subtree it modifies: > > conformance partial { > description > "Devices that cannot modify XXX in their hardware may claim > partial conformance."; > > object-variance "/top/foo/bar" { > config false; > } > > object-variance "/top/foo/baz" { > config false; > } > } > > > conformance read-only { > // the entire module is read only on this conformance level > object-variance "/top" { > config false; > } > } > > I like this a lot, but import-by-revision is irrelevant to the problem of partial conformance levels. This allows vendors to claim 'full', 'partial', or 'read-only' conformance, where full is implied to be everything in the module, not described by any 'conformance-stmt'. IMO, this solves part of the ipfix request: fine-grained mods to full conformance. The capability mechanism in the protocol already exists for course-grained conformance, so I don't see why feature/if-feature is a must-have right now. > > /martin > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Oct 28 07:22: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 C35A528C219; Tue, 28 Oct 2008 07:22: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 EAF0728C2A5 for ; Tue, 28 Oct 2008 07:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 RgIWUnhCWVxx for ; Tue, 28 Oct 2008 07:22:15 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 109B428C2A1 for ; Tue, 28 Oct 2008 07:22:14 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9096C20B8C for ; Tue, 28 Oct 2008 15:21:56 +0100 (CET) X-AuditID: c1b4fb3e-acf82bb00000537b-ac-490720043a5a Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8592E20797 for ; Tue, 28 Oct 2008 15:21:56 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 15:21:31 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 15:21:31 +0100 Content-Disposition: inline From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 28 Oct 2008 15:21:30 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Message-Id: <200810281521.30860.david.partain@ericsson.com> X-OriginalArrivalTime: 28 Oct 2008 14:21:31.0484 (UTC) FILETIME=[795401C0:01C93908] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Proposed resolution on architecture document deliverable X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi all, At the interim meeting, there was discussion about the following WG item: 1. An architecture document explaining the relationship between YANG and its inputs and outputs. (informational) Phil Shafer has published an individual draft as a possible starting point for that deliverable: http://tools.ietf.org/id/draft-shafer-netmod-arch-00.txt Some of the comments from the interim meeting: Andy Bierman said that we need to make sure that we're doing what the IESG is expecting. He also commented that this document, given the scope from the charter, is not particularly useful. Mehmet Ersue thinks the document should talk about the relationship to NETCONF (as Phil's document does). David Partain agreed with Mehmet and commented that discussing NETMOD without discussing NETCONF seems like discussing the SMI without discussing SNMP. Andy pointed what NETMOD relies on from NETCONF (RPC methods, config database, notifications, and capabilities/hello) and stated that we have to be conscious of what NETCONF allows and disallows. When the room was asked "Is Phil's document a good starting point, given that we will provide him with constructive comments, including help with the text on DSDL mapping scope? Everyone in the room said yes. Cheers, David(s) _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Oct 28 07:52:06 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A2DC3A69E9; Tue, 28 Oct 2008 07:52:06 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 556BB3A69E9 for ; Tue, 28 Oct 2008 07:52: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 ZRqOFjXu5PGM for ; Tue, 28 Oct 2008 07:52:04 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 54A4F3A688F for ; Tue, 28 Oct 2008 07:52:04 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8B59A20465 for ; Tue, 28 Oct 2008 15:52:02 +0100 (CET) X-AuditID: c1b4fb3c-b00d2bb0000015b5-c1-490727126427 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7A67C20B7C for ; Tue, 28 Oct 2008 15:52:02 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 15:51:32 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 15:51:32 +0100 Content-Disposition: inline From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 28 Oct 2008 15:51:32 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Message-Id: <200810281551.32137.david.partain@ericsson.com> X-OriginalArrivalTime: 28 Oct 2008 14:51:32.0730 (UTC) FILETIME=[AAF455A0:01C9390C] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Description of the discussion about issue 'yang-00221: rpc statement in list'. X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings, This is a description of the discussion about issue 'yang-00221: rpc statement in list'. See the wiki at http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00221 Description: - Allow operations to be specified in lists. It should be possible to define custom RPCs inside list. The XML encoding should carry a reference to the list where the RPC was defined. RPCs on the top-level would still be allowed. = The interim meeting did NOT reach a rough consensus on this issue. Please correct the discussion below if you think things are missing. The discussion: Andy Bierman: why can't you just add a parameter that points into the tree where it's relevant and keep the RPC definition at the top level? Martin Bj=F6rklund: it's an encapsulation issue Balazs Lengyel: it can also be a way of providing access control. Mehmet Ersue: the most important issue is the access control issue. J=FCrgen Sch=F6nw=E4lder: if we allow RPCs at the top-level, we have to solve the access control issue anyway. Martin Bj=F6rklund: our access control model follows the UNIX-like way of doing things, setting the x bit on a particular leaf in a tree. That matches this proposal well. Phil Shafer: If you define restart all over the place, you have no guarantee that it'll be the same everywhere. This only works for trivial cases and thinks there are better ways do accomplish what this is trying to do. Martin: it all depends on the arguments. Sometimes you can have more than one argument. Andy Bierman: Want to see the configuration database as purely configuration, which this violates. David Harrington: how much of this is driven by the user community that is doing things in an object-oriented way? Martin: to some degree. This is already done today in proprietary solutions that are not "object-oriented" per se. Balazs and Mehmet: it certainly affects the desire to have this. David Harrington: we're asking for the camel's nose; will we soon have the whole camel? Andy Bierman: What would the ABNF look like? David Partain: Suggests that Martin / Balazs send a delta proposal to the mailing list and that we can talk about it in Minneapolis. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Oct 28 08:03: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 9D59928C2AF; Tue, 28 Oct 2008 08:03: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 EFCA328C2CD for ; Tue, 28 Oct 2008 08:03:12 -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 bXNtuSWjXUdt for ; Tue, 28 Oct 2008 08:03:08 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1EE2728C2B3 for ; Tue, 28 Oct 2008 08:03:08 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 29A6C2114E for ; Tue, 28 Oct 2008 16:03:06 +0100 (CET) X-AuditID: c1b4fb3c-b00d2bb0000015b5-81-490729aa8c83 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 00B9D2111C for ; Tue, 28 Oct 2008 16:03:06 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 16:02:51 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 16:02:51 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 28 Oct 2008 16:02:50 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200810281602.50774.david.partain@ericsson.com> X-OriginalArrivalTime: 28 Oct 2008 15:02:51.0284 (UTC) FILETIME=[3F677540:01C9390E] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Proposed consensus mail on yang-00000: module update rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings, This is a call for consensus about issue 'yang-00000: module update rules'. See the wiki at http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00000 PLEASE speak up if you favor or object to the proposed rules, including people who attended the interim. Silence is impossible to interpret. Issue: Need to define the rules for how modules are updated (new revisions published). The first day of the interim meeting spent a great deal of time talking about this issue. This mail does not give a blow-by-blow recounting of the discussion but rather tries to summarize what was discussed and the conclusions. The general principle is that when updating a module without name changes, the module may become less constrained, but never more constrained. - Why do we need to have these rules? * protect old client applications (old NETCONF clients talking to a new NETCONF server). You're not allowed to change something that makes a client that was previously compliant suddenly no longer compliant. * protect those importing a module - We're talking about rules for: * New building blocks (e.g., typedefs) * New definitions * Organizational changes (e.g., inline to named types) * Bug fixes - Rules for adding things to an existing module: A proposal from Balazs Lengyel: Balazs Lengyel provided a list of changes that Ericsson considers "compatible" changes: - adding new optional nodes - adding new RPCs - extending cardinality - extending the data range - change of default value of an optional attribute - relaxing rules on semantic change (e.g., config -> non-config, read-only -> read-write - adding data to notifications - updates to description clauses - updates to extensions where the policy is that if it's not on that list, it's considered "an incompatible change" and shouldn't be done without changing the namespace. Incompatible changes: - leaf order changes This fed into the subsequent suggested rules... Changes affecting types: Martin Bj=F6rklund asked: - Can you extend the value space when updating a document? - Can you restrict the value space when updating a document? For an answer, see the general principle above. In the end, changes that affect storage requirements for a type are not allowed. (Editor: the consensus here is entirely unclear.) Leaf change rules: (Thanks to Balazs for his notes here!) What are you allowed / not allowed to change about a leaf definition (given the general principle above): Changes that are permitted: - status with the current/deprecated/obsolete progression - new typedefs - new groupings - expand value range - remove musts - new optional non-mandatory nodes - allow new rpc - allow new notifications - allow new data in existing notifications - allow new optional parameters to rpc input(?) = - allow new parameters to rpc output(?) = - remove mandatory - reference (updated) - description (semantic equivalence) - length - add default (Editor: unsure of this!) - add new bits - add new enum values at the end of the list - config false ->true - (all kinds of "non-changes" as well) Changes that are not permitted: - delete nodes - leaf order changes (due to strict encoding order) - change basic type (e.g., uint8 -> int8) - change length restriction of string - make a type into union - no new mandatory nodes - change datatype of a leaf (underlying datatype at the - base of the type hierarchy) - add new membertypes to a union - change units - change default - add if-feature - change the value of enum or bits - add enums in the middle Typedef change rules: The typedef rules discussion immediately morphed into a discussion of "import by revision", which will be reported on separately. However, we reached rough consensus to proceed with "import by revision", and, by deciding this, we can use the same rules for typedefs as we have for leafs. We have not talked about the rules for groupings yet. Martin Bj=F6rklund is going to take the lead in writing a proposal for import by revision to cover import and include, as well as the rules for what can change between revisions (typedefs, groups, leafs, etc.). _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Oct 28 08:13: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 CC53C28C2C8; Tue, 28 Oct 2008 08:13: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 8057E28C1DC for ; Tue, 28 Oct 2008 08:13: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 tkyTmTstmjgL for ; Tue, 28 Oct 2008 08:13:37 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9BBA328C2DA for ; Tue, 28 Oct 2008 08:13:37 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7E62520685 for ; Tue, 28 Oct 2008 16:13:31 +0100 (CET) X-AuditID: c1b4fb3c-ac8cbbb0000015b5-20-49072c1b612f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6730C20526 for ; Tue, 28 Oct 2008 16:13:31 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 16:12:37 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 16:12:37 +0100 Content-Disposition: inline From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 28 Oct 2008 16:12:37 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Message-Id: <200810281612.37126.david.partain@ericsson.com> X-OriginalArrivalTime: 28 Oct 2008 15:12:37.0683 (UTC) FILETIME=[9CECD830:01C9390F] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Proposed consensus mail on yang-00413: import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings, This is a call for consensus about issue 'yang-00413: import by revision'. See the wiki at http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00413 for an introduction. This mail documents the conversations at the interim for proposed changes / clarifications in text in the YANG document. As such, the question is whether you agree with the interpretation that this text intends to document. There are no new features being proposed. PLEASE speak up if you favor this consensus (including people who attended the interim). Issue: Should YANG modules import specific revisions of other modules? See also the discussion about update rules, which is relevant for this issue as well. The interim meeting discussed whether to use import-by-revision or whether to require changing names when changing the groupings/typedefs in a module. After much discussion, we reached rough consensus to proceed with import by revision. However, it was quite clear that further clarification was necessary (everyone thought so). There was also consensus that import by revision will be mandatory, but with exceptions. The exceptions would be for modules that "guarantee" that they follow the rules (e.g., IANA modules) and will not change things in non-backwardly-compatible ways. David(s) _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Oct 28 08: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 2562928C2A2; Tue, 28 Oct 2008 08: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 48DEE28C2B0 for ; Tue, 28 Oct 2008 08:18: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 8lBdOrm82Hna for ; Tue, 28 Oct 2008 08:18:00 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 70CD228C2A2 for ; Tue, 28 Oct 2008 08:18:00 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 96D2622117 for ; Tue, 28 Oct 2008 16:14:27 +0100 (CET) X-AuditID: c1b4fb3e-ad783bb00000537b-3e-49072c5348f6 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 81CA82025A for ; Tue, 28 Oct 2008 16:14:27 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 16:13:55 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 16:13:55 +0100 Content-Disposition: inline From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 28 Oct 2008 16:13:54 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Message-Id: <200810281613.54550.david.partain@ericsson.com> X-OriginalArrivalTime: 28 Oct 2008 15:13:55.0042 (UTC) FILETIME=[CB08E420:01C9390F] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Proposed consensus mail on yang-00755: adding a 'prefix' substatement to 'belongs-to' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings, This is a call for consensus about issue 'yang-00755: adding a 'prefix' substatement to 'belongs-to'. See the wiki at http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00755 PLEASE speak up if you favor or object to the proposed change, including people who attended the interim. Silence is impossible to interpret. Proposal to add a 'prefix' substatement to 'belongs-to' in order to allow a submodule to be validated in isolation from its main module. David Harrington asked what the downsides are, and none were identified. David Reid asked a clarifying question about whether the purpose is for the submodule to be self-contained? (Yes, that's the purpose.) Everyone in the room at the interim agreed that this should be added. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Oct 28 09:18: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 490B63A68FA; Tue, 28 Oct 2008 09:18: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 76A143A68FC for ; Tue, 28 Oct 2008 09:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.974 X-Spam-Level: X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=-0.725, 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 hHPUmTrx38bg for ; Tue, 28 Oct 2008 09:18:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 77C543A68FA for ; Tue, 28 Oct 2008 09:18:23 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F842C004B; Tue, 28 Oct 2008 17:18:22 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zM7-e1D6SqwA; Tue, 28 Oct 2008 17:18:17 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 335CFC004A; Tue, 28 Oct 2008 17:18:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A5FA582D285; Tue, 28 Oct 2008 17:18:15 +0100 (CET) Date: Tue, 28 Oct 2008 17:18:15 +0100 From: Juergen Schoenwaelder To: David Partain Message-ID: <20081028161815.GA1360@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: David Partain , netmod@ietf.org References: <200810281613.54550.david.partain@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200810281613.54550.david.partain@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Proposed consensus mail on yang-00755: adding a 'prefix' substatement to 'belongs-to' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, Oct 28, 2008 at 04:13:54PM +0100, David Partain wrote: > This is a call for consensus about issue 'yang-00755: adding a > 'prefix' substatement to 'belongs-to'. See the wiki at > http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00755 I support this. /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 Oct 28 11:52: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 E8F403A6807; Tue, 28 Oct 2008 11:52: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 AB9A128C24B for ; Tue, 28 Oct 2008 11:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vr8-RgwzuCxS for ; Tue, 28 Oct 2008 11:52:42 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A27BC3A68A4 for ; Tue, 28 Oct 2008 11:52:41 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8E181227BF for ; Tue, 28 Oct 2008 19:27:19 +0100 (CET) X-AuditID: c1b4fb3e-abf80bb00000537b-7e-4907587de46d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5766B22E78 for ; Tue, 28 Oct 2008 19:22:53 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 19:22:11 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 19:22:11 +0100 Message-ID: <49075853.6060803@ericsson.com> Date: Tue, 28 Oct 2008 19:22:11 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Partain References: <200810281612.37126.david.partain@ericsson.com> In-Reply-To: <200810281612.37126.david.partain@ericsson.com> X-OriginalArrivalTime: 28 Oct 2008 18:22:11.0754 (UTC) FILETIME=[186658A0:01C9392A] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Proposed consensus mail on yang-00413: import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I support this. Balazs David Partain wrote: > Greetings, > > This is a call for consensus about issue > 'yang-00413: import by revision'. See the wiki at > http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00413 > for an introduction. > > This mail documents the conversations at the interim for proposed > changes / clarifications in text in the YANG document. As such, > the question is whether you agree with the interpretation that > this text intends to document. There are no new features being > proposed. > > PLEASE speak up if you favor this consensus (including people who > attended the interim). > > Issue: Should YANG modules import specific revisions of other > modules? > > See also the discussion about update rules, which is relevant for > this issue as well. > > The interim meeting discussed whether to use import-by-revision > or whether to require changing names when changing the > groupings/typedefs in a module. > > After much discussion, we reached rough consensus to proceed with > import by revision. However, it was quite clear that further > clarification was necessary (everyone thought so). > > There was also consensus that import by revision will be > mandatory, but with exceptions. The exceptions would be for > modules that "guarantee" that they follow the rules (e.g., IANA > modules) and will not change things in non-backwardly-compatible > ways. > > David(s) > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- 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 Oct 28 12:53: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 AE6BC3A693A; Tue, 28 Oct 2008 12:53: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 E2C043A6CAA for ; Tue, 28 Oct 2008 12:53:19 -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 tqa6GoAmfQVZ for ; Tue, 28 Oct 2008 12:53:19 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 016C03A693A for ; Tue, 28 Oct 2008 12:53:18 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A40C820855 for ; Tue, 28 Oct 2008 20:23:44 +0100 (CET) X-AuditID: c1b4fb3c-ac8cbbb0000015b5-4a-490766c07aa5 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 87DAB20606 for ; Tue, 28 Oct 2008 20:23:44 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 20:17:48 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 20:17:48 +0100 Message-ID: <49076558.1030704@ericsson.com> Date: Tue, 28 Oct 2008 20:17:44 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Partain References: <200810281613.54550.david.partain@ericsson.com> In-Reply-To: <200810281613.54550.david.partain@ericsson.com> X-OriginalArrivalTime: 28 Oct 2008 19:17:48.0310 (UTC) FILETIME=[DD246360:01C93931] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Proposed consensus mail on yang-00755: adding a 'prefix' substatement to 'belongs-to' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I support this. Balazs David Partain wrote: > Greetings, > > This is a call for consensus about issue 'yang-00755: adding a > 'prefix' substatement to 'belongs-to'. See the wiki at > http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00755 > > PLEASE speak up if you favor or object to the proposed change, > including people who attended the interim. Silence is impossible > to interpret. > > Proposal to add a 'prefix' substatement to 'belongs-to' in order > to allow a submodule to be validated in isolation from its main > module. > > David Harrington asked what the downsides are, and none were > identified. > > David Reid asked a clarifying question about whether the purpose > is for the submodule to be self-contained? (Yes, that's the > purpose.) > > Everyone in the room at the interim agreed that this should be > added. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- 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 Oct 28 13:00: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 D2F1C28C135; Tue, 28 Oct 2008 13:00: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 0BD2C28C135 for ; Tue, 28 Oct 2008 13:00: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=[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 iL-lfQmozMY8 for ; Tue, 28 Oct 2008 13:00:30 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id AD7C628C275 for ; Tue, 28 Oct 2008 13:00:29 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5FCC2207B7 for ; Tue, 28 Oct 2008 21:00:26 +0100 (CET) X-AuditID: c1b4fb3e-aaf7ebb00000537b-20-49076f5afdc9 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 42933200E7 for ; Tue, 28 Oct 2008 21:00:26 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 21:00:26 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 21:00:25 +0100 Message-ID: <49076F59.5050409@ericsson.com> Date: Tue, 28 Oct 2008 21:00:25 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Partain References: <200810281602.50774.david.partain@ericsson.com> In-Reply-To: <200810281602.50774.david.partain@ericsson.com> X-OriginalArrivalTime: 28 Oct 2008 20:00:26.0029 (UTC) FILETIME=[D1A955D0:01C93937] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Proposed consensus mail on yang-00000: module update rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I support this. Balazs David Partain wrote: > Greetings, > = > This is a call for consensus about issue 'yang-00000: module > update rules'. See the wiki at > http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00000 > = > PLEASE speak up if you favor or object to the proposed rules, > including people who attended the interim. Silence is impossible > to interpret. > = > Issue: Need to define the rules for how modules are updated (new > revisions published). > = > The first day of the interim meeting spent a great deal of time > talking about this issue. This mail does not give a blow-by-blow > recounting of the discussion but rather tries to summarize what > was discussed and the conclusions. > = > The general principle is that when updating a module without name > changes, the module may become less constrained, but never more > constrained. > = > - Why do we need to have these rules? > = > * protect old client applications (old NETCONF clients > talking to a new NETCONF server). You're not allowed to > change something that makes a client that was previously > compliant suddenly no longer compliant. > * protect those importing a module > = > - We're talking about rules for: > = > * New building blocks (e.g., typedefs) > * New definitions > * Organizational changes (e.g., inline to named types) > * Bug fixes > = > - Rules for adding things to an existing module: > = > A proposal from Balazs Lengyel: > = > Balazs Lengyel provided a list of changes that Ericsson considers > "compatible" changes: > = > - adding new optional nodes > - adding new RPCs > - extending cardinality > - extending the data range > - change of default value of an optional attribute > - relaxing rules on semantic change (e.g., config -> > non-config, read-only -> read-write > - adding data to notifications > - updates to description clauses > - updates to extensions > = > where the policy is that if it's not on that list, it's > considered "an incompatible change" and shouldn't be done without > changing the namespace. > = > Incompatible changes: > = > - leaf order changes > = > This fed into the subsequent suggested rules... > = > Changes affecting types: > = > Martin Bj=F6rklund asked: > = > - Can you extend the value space when updating a document? > - Can you restrict the value space when updating a document? > = > For an answer, see the general principle above. > = > In the end, changes that affect storage requirements for a type > are not allowed. (Editor: the consensus here is entirely > unclear.) > = > Leaf change rules: > = > (Thanks to Balazs for his notes here!) > = > What are you allowed / not allowed to change about a leaf > definition (given the general principle above): > = > Changes that are permitted: > = > - status with the current/deprecated/obsolete progression > - new typedefs > - new groupings > - expand value range > - remove musts > - new optional non-mandatory nodes > - allow new rpc > - allow new notifications > - allow new data in existing notifications > - allow new optional parameters to rpc input(?) = > - allow new parameters to rpc output(?) = > - remove mandatory > - reference (updated) > - description (semantic equivalence) > - length > - add default (Editor: unsure of this!) > - add new bits > - add new enum values at the end of the list > - config false ->true > - (all kinds of "non-changes" as well) > = > Changes that are not permitted: > = > - delete nodes > - leaf order changes (due to strict encoding order) > - change basic type (e.g., uint8 -> int8) > - change length restriction of string > - make a type into union > - no new mandatory nodes > - change datatype of a leaf (underlying datatype at the > - base of the type hierarchy) > - add new membertypes to a union > - change units > - change default > - add if-feature > - change the value of enum or bits > - add enums in the middle > = > Typedef change rules: > = > The typedef rules discussion immediately morphed into a > discussion of "import by revision", which will be reported on > separately. However, we reached rough consensus to proceed > with "import by revision", and, by deciding this, we can use > the same rules for typedefs as we have for leafs. We have not > talked about the rules for groupings yet. > = > Martin Bj=F6rklund is going to take the lead in writing a > proposal for import by revision to cover import and include, as > well as the rules for what can change between revisions > (typedefs, groups, leafs, etc.). > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- = 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 Oct 28 13:03: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 084323A6802; Tue, 28 Oct 2008 13:03: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 21D863A6802 for ; Tue, 28 Oct 2008 13:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyvqhIykdNsy for ; Tue, 28 Oct 2008 13:03:15 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 18DDF3A67B2 for ; Tue, 28 Oct 2008 13:03:14 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4068320662 for ; Tue, 28 Oct 2008 21:03:13 +0100 (CET) X-AuditID: c1b4fb3e-adf84bb00000537b-09-49077001fd1d Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2BAD52064D for ; Tue, 28 Oct 2008 21:03:13 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 21:02:40 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 21:02:39 +0100 Message-ID: <49076FDE.2060005@ericsson.com> Date: Tue, 28 Oct 2008 21:02:38 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Partain References: <200810270932.09693.david.partain@ericsson.com> In-Reply-To: <200810270932.09693.david.partain@ericsson.com> X-OriginalArrivalTime: 28 Oct 2008 20:02:39.0735 (UTC) FILETIME=[215B4070:01C93938] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Proposed consensus mail on yang-01253 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I support this. Balazs David Partain wrote: > Greetings, > = > This is a call for consensus about issue 'yang-01253: adding > "leafref" type'. See the wiki at > http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-01253 > = > This mail and other consensus calls after the interim will follow > a similar pattern. First, we have the question and the proposed > consensus, then details. The details include examples, followed > by a summary of the interim discussion on the issues. Please > read the whole message. > = > PLEASE speak up if you favor or object to the proposed change, > including people who attended the interim. Silence is impossible > to interpret. > = > The proposal is to add a new type 'leafref', which works like a > 'keyref', but points to any leaf. = > = > Questions: > = > 1. Should we add 'leafref'? > = > Interim consensus: yes > = > 2. Should 'leafref' be 'config false'? > = > Interim consensus: yes > = > 3. Should 'leafref' be fully instantiated or are wildcards > allowed? > = > Interim consensus: fully instantiated > = > A bit more detail... > = > The following questions were discussed: > = > 'leafref' is a way to "borrow" a column from elsewhere, to be > able to point at things that aren't keys. Applicability is more > for monitoring than configuration. > = > At the interim, everyone in the room was in favor of adding leafref. > = > Should 'leafref' be 'config false'? The consensus of the room > was that it must be. > = > Should we allow wildcards or should it be fully instantiated? > The rough consensus was that it should be fully instantiated, but > J. Sch=F6nw=E4lder remains unconvinced. He worried about not > allowing things because we can't come up with an example. > = > Andy Bierman will provide text for 'leafref' and send it to the > mailing list. > _______________________________________________ > 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 Oct 28 13:13: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 170B13A6C00; Tue, 28 Oct 2008 13:13: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 389353A6C00 for ; Tue, 28 Oct 2008 13:13: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=[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 O9x+c0+kUMEQ for ; Tue, 28 Oct 2008 13:13:38 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 133E23A6CB0 for ; Tue, 28 Oct 2008 13:13:38 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 61E3A206E8 for ; Tue, 28 Oct 2008 21:13:36 +0100 (CET) X-AuditID: c1b4fb3c-ad0ccbb0000015b5-59-490772702c05 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3E1C820249 for ; Tue, 28 Oct 2008 21:13:36 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 21:11:08 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 21:11:08 +0100 Message-ID: <490771DA.9060903@ericsson.com> Date: Tue, 28 Oct 2008 21:11:06 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Partain References: <200810271100.38001.david.partain@ericsson.com> In-Reply-To: <200810271100.38001.david.partain@ericsson.com> X-OriginalArrivalTime: 28 Oct 2008 20:11:08.0429 (UTC) FILETIME=[508FCBD0:01C93939] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Proposed consensus mail on yang-00172 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Generally I support this with some comments: General statement: Restrictions on data going to the agent must be honored, otherwise an error is returned. Restrictions on data coming from the agent, are promises by the agent. If they are broken, tough luck, but they shouldn't. Enforced at commit implies: not enforced during the editing of a candidate configuration I am still unclear what ordered-by means on RPC input. Balazs David Partain wrote: > Greetings, > > Hope the table below works. You may have to use a fixed-width font. > > This is a call for consensus about issue 'yang-00172: > clarifications for ordered-by, must, unique, keyref, when, > mandatory, minmax, etc'. See the wiki at > http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00172 > for an introduction. > > This mail documents the conversations at the interim for proposed > changes / clarifications in text in the YANG document. As such, > the question is whether you agree with the interpretation that > this text intends to document. There are no new features being > proposed. > > PLEASE speak up if you favor the changes or object to the text > (including people who attended the interim). > > Question that started the discussion: What does 'ordered-by > user;' mean for read-only data or RPC input or notification > content? > > This question is broader and the table below says when the > various statements are relevant or not. > > config config RPC RPC Notifi- Enforced > true false input output cation at commit > ---------------------------------------------------------------- > ordered-by | OK | i | OK | i | i | N > unique | OK | OK | OK | OK | OK | Y > must(1) | OK | OK | OK | OK | OK | Y > keyref | OK | OK | OK(2)| OK(2)| OK(2)| Y > when(1) | OK | OK | OK | OK | OK | N > mandatory | OK | OK | OK | OK | OK | Y > max/max-elems | OK | OK | OK | OK | OK | Y > > All of these are constraints, and the question is when that > constraint is enforced. > > Key: > > i - ignored > > (1) must, when - the XPath context varies, and we'll have to > document all of this for all of the different columns. > > (2) restrictions: the target of the XPath expression refers to > the running config or to status data. > > The interim meeting spent some time talking about the differences > between when and must. Phil Shafer's definitions: > > 'when' - The parent schema node is ignored unless the 'when' > expression is satisfied. If the expression becomes false, any > data associated with the node is automatically deleted. > > (Editor: deleted from what? from the response? from the config database? Not > entirely sure. Phil?) > > 'must' - If the parent node exists in the database, the 'must' > expression must be true. If the expression is false, an error > condition exists. Enforced at commit time. > > Do you agree with the definitions above? > > There was a long discussion about when a 'when' expression is > evaluated. The rough consensus of the room was that 'when' > constraints should be enforced in the candidate configuration, > whereas 'must' is enforced first when committing in the running > configuration. > > Phil Shafer will write some text about a hierarchy of constraints > where mandatory can be applied underneath a 'when'. Conditions > on parents affect or negate constraints on children. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Oct 28 13:35: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 C00153A6C00; Tue, 28 Oct 2008 13:35: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 C22CA28C275 for ; Tue, 28 Oct 2008 13:35:12 -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 TR2eTeC3QjIy for ; Tue, 28 Oct 2008 13:35:12 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id EE3E63A6C7F for ; Tue, 28 Oct 2008 13:35:11 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4180F203B4 for ; Tue, 28 Oct 2008 21:35:10 +0100 (CET) X-AuditID: c1b4fb3e-aaf7ebb00000537b-af-4907777e0d30 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3316B201EF for ; Tue, 28 Oct 2008 21:35:10 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 21:34:53 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 21:34:53 +0100 Message-ID: <4907776C.9020801@ericsson.com> Date: Tue, 28 Oct 2008 21:34:52 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Partain References: <200810171506.11481.david.partain@ericsson.com> In-Reply-To: <200810171506.11481.david.partain@ericsson.com> X-OriginalArrivalTime: 28 Oct 2008 20:34:53.0450 (UTC) FILETIME=[A1F0BEA0:01C9393C] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Consensus call on yang-00088: new "refine" statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org See below! Balazs David Partain wrote: > > 1. Should we add a refine statement (assuming we have 'augment' > inside uses) in "uses"? > > Rough Consensus from the interim: make this change I assume the things that can be refined are not changed by this proposal. Otherwise we need a separate debate on that. Don't really care. > > 2. Should we have an 'augment' statement inside the 'uses' > (while keeping the top-level 'augment')? > > (very) Rough Consensus from the interim: make this change YES, collecting relevant definitions into one place is nice. > > 3. Should we put a "when" as a substatement of a leaf? > > Rough Consensus from the interim: yes, assuming #2 is yes. Was it just leaf or other statements as well e.g. list, leaf-list, etc??? > > 4. Should we have two 'augment' keywords? > > Rough Consensus from the interim: yes, assuming #2 is yes. > Don't care. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Oct 28 13:49: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 D34463A67B2; Tue, 28 Oct 2008 13:49: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 EEBE13A6968 for ; Tue, 28 Oct 2008 13:49:31 -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 dun+ub04GTBE for ; Tue, 28 Oct 2008 13:49:31 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 0A40A3A67B2 for ; Tue, 28 Oct 2008 13:49:30 -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 QAA11803; Tue, 28 Oct 2008 16:49:29 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id QAA17858; Tue, 28 Oct 2008 16:49:29 -0400 (EDT) Message-Id: <200810282049.QAA17858@adminfs.snmp.com> To: David Partain From: David Reid In-reply-to: Your message of Tue, 28 Oct 2008 16:13:54 +0100. <200810281613.54550.david.partain@ericsson.com> Date: Tue, 28 Oct 2008 16:49:28 -0400 Cc: netmod@ietf.org Subject: Re: [netmod] Proposed consensus mail on yang-00755: adding a 'prefix' substatement to 'belongs-to' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > Greetings, > > This is a call for consensus about issue 'yang-00755: adding a > 'prefix' substatement to 'belongs-to'. See the wiki at > http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00755 I am in favor of adding a prefix substatement to belongs-to. -David Reid _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Oct 28 13:54: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 13EC03A6953; Tue, 28 Oct 2008 13:54: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 604083A6C96 for ; Tue, 28 Oct 2008 13:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmLfD97UmJSE for ; Tue, 28 Oct 2008 13:54:56 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 6CED23A6C6E for ; Tue, 28 Oct 2008 13:54:56 -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 QAA12036; Tue, 28 Oct 2008 16:54:55 -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 QAA18022; Tue, 28 Oct 2008 16:54:54 -0400 (EDT) Message-Id: <200810282054.QAA18022@adminfs.snmp.com> To: David Partain From: David Reid In-reply-to: Your message of Tue, 28 Oct 2008 16:02:50 +0100. <200810281602.50774.david.partain@ericsson.com> Date: Tue, 28 Oct 2008 16:54:54 -0400 Cc: netmod@ietf.org Subject: Re: [netmod] Proposed consensus mail on yang-00000: module update rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > Greetings, > > This is a call for consensus about issue 'yang-00000: module > update rules'. See the wiki at > http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00000 > > PLEASE speak up if you favor or object to the proposed rules, > including people who attended the interim. Silence is impossible > to interpret. I generally support the proposed rules. I'd like to see a more specific proposal on change rules. Do I understand correctly that Martin is going to write that proposal based on the summary in this thread? I think the list Balazs provided is very good. -David Reid _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Oct 28 14:27: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 BEC893A67B2; Tue, 28 Oct 2008 14:27: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 182903A6CC4 for ; Tue, 28 Oct 2008 14:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11BedJdwL4n2 for ; Tue, 28 Oct 2008 14:27:18 -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 E25763A6CAA for ; Tue, 28 Oct 2008 14:27:17 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 05B6C76C502; Tue, 28 Oct 2008 22:27:16 +0100 (CET) Date: Tue, 28 Oct 2008 22:27:10 +0100 (CET) Message-Id: <20081028.222710.251029462.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <200810282054.QAA18022@adminfs.snmp.com> References: <200810281602.50774.david.partain@ericsson.com> <200810282054.QAA18022@adminfs.snmp.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] Proposed consensus mail on yang-00000: module update rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Reid wrote: > I'd like to see a more specific > proposal on change rules. Do I understand correctly that Martin is going > to write that proposal based on the summary in this thread? Yes. This is what I currently have written, which I planned to include in the -02 draft, published next monday (10/11). The text is mostly copied from the SMIv2 text. /martin * Updating a Module As experience is gained with a module, it may be desirable to revise that module. However, changes are not allowed if they have any potential to cause interoperability problems between a client using an original specification and a server using an updated specification. For any published change, a new "revision" statement (^revision^) SHOULD be included in front of the existing revision statements. Furthermore, any necessary changes MUST be applied to any meta statements, including the "organization" and "contact" statements (^organization^, ^contact^). Note that definitions contained in a module are available to be imported by any other module, and are referenced in "import" statements via the module name. Thus, a module name MUST NOT be changed. Furthermore, the "namespace" statement MUST NOT be changed, since all XML elements are encoded in the namespace. Obsolete definitions MUST NOT be removed from modules since their identifiers may still be referenced by other modules. A definition may be revised in any of the following ways: - An "enumeration" type may have new enums added, provided the old enums's values do not change. - A "bits" type may have new bits added, provided the old bits's positions do not change. - A "range", "length", or "pattern" statement may expand the allowed value space. - A "default" statement may be added. - A "units" statement may be added. - A "reference" statement may be added or updated. - A "must" statement may be removed or its constraint relaxed. - A "mandatory" statement may be removed or changed from "true" to "false". - A "min-elements" statement may be removed, or changed to require less elements. - A "max-elements" statement may be removed, or changed to allow more elements. - A "description" statement may be added or clarified without changing the semantics of the definition. - New typedefs, groupings, rpc, notifications, extensions, features, and identities may be added. - New data definition statements may be added if they do not add mandatory nodes (^mandatory-nodes^) to existing nodes, or if they are conditionally dependent on a new feature (i.e. have a "if-feature" statement which refers to a new feature). - A new "case" statement may be added. - A node that was non-configuration may be changed to represent configuration, provided it is not mandatory (^mandatory-nodes^). - An "if-feature" statement may be removed, provided its node is not mandatory (^mandatory-nodes^). - A "status" statement may be added, or changed from "current" to "deprecated" or "obsolete", or from "deprecated" to "obsolete". - A "type" statement may be replaced with another "type" statement which does not change the syntax or semantics of the type. For example, an inline type definition may be replaced with a typedef. - Any set of data definition nodes may be replaced with another set of syntactically and semantically equivalent nodes. For example, a set of leafs may be replaced by a uses of a grouping with the same leafs. - A module may be split into a set of submodules, or submodule may be removed, provided the definitions in the module do not change in any other way than allowed here. - The "prefix" statment may be changed, provided all local uses of the prefix also are changed. Otherwise, if the semantics of any previous definition are changed (i.e. if a non-editorial change is made to any definition other than those specifically allowed above), then this MUST be achieved by a new definition with a new identifier. [Editor's Note: These rules work as long as we have import/include by revision] _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Oct 28 14:33: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 B560228C2CB; Tue, 28 Oct 2008 14:33: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 DF79128C30D for ; Tue, 28 Oct 2008 14:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[AWL=-0.959, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReIMFi+PvfRF for ; Tue, 28 Oct 2008 14:33:27 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 498AD28C318 for ; Tue, 28 Oct 2008 14:33:27 -0700 (PDT) Received: (qmail 41125 invoked from network); 28 Oct 2008 21:11:20 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 28 Oct 2008 21:11:18 -0000 X-YMail-OSG: zdYr4eYVM1mss7x2.2.3_hRff4dTZo7y6fLz78FUm71ZrqeA_MCc74N8I.ba0AIERAYRrZXy8cUWYwfq5E8Peg2eonO7u8Qwtt.14srm3_d1rpGx1X81YyfWt2qLNRdbpqA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49077FF2.6020900@netconfcentral.com> Date: Tue, 28 Oct 2008 14:11:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] all consensus points X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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, Since I was at the interim meeting, my positions on these consensus points is already documented, so I do not need to add any comments. It would be really great to hear from people who were not at the interim, since silence means "go with the interim consensus". Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Oct 28 14:51: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 743703A68AB; Tue, 28 Oct 2008 14:51: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 183193A6CAB for ; Tue, 28 Oct 2008 14:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.488, 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 4HfkhAxXheQJ for ; Tue, 28 Oct 2008 14:51:28 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 5C2BF3A68D8 for ; Tue, 28 Oct 2008 14:51:28 -0700 (PDT) Received: (qmail 59299 invoked from network); 28 Oct 2008 21:51:27 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 28 Oct 2008 21:51:25 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4907895C.3010807@netconfcentral.com> Date: Tue, 28 Oct 2008 14:51:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] YANG notification content proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, I do think the YANG notification construct is quite good enough. SMIv2 provides an OBJECTS list in the notification definition, so copies of 'real' objects can be easily included in the payload without any redefining needed. YANG requires 'local' nodes to be created within the notification statement, which are like SMIv2 'notification-only' objects. The problem is that this mode is the exception, not the common case. A NETCONF notification cannot really support an SMIv2-style object. You have to provide the entire XML instance tree for the root to any given 'object' node. There is no XML 'varbind', which contains a fully specified object instance ID and a value. This would only work well if the YANG to XML encoding was something like SMIv2: Implied XML content from the object-stmt: container object { config false; leaf id { type instance-identifier; } anyxml value; } Example notification-stmt: notification mtu-changed { description "Return the new MTU value when it changes."; object /if:interfaces/if:interface/if:mtu { description "Identifies the interface instance that changed, and the new MTU value for that interface."; } leaf changed-by { description "Indicates how the MTU was changed."; type enumeration { enum other; enum agent; enum manager; } } } Example PDU: 2008-10-28T14:46:04.000-07:00 /if:interfaces/if:interface[if:name='eth0']/if:mtu 1518 manager I think this will make YANG notifications better: * easier to understand * more consistent with SMIv2 notifications * allows arbitrary content, not just leafs * XPath allows simpler and less verbose encoding than XML for specifying the path from root with all the key values * notification-only content and copy of config object content are clearly distinguished, and each is easy to specify Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Oct 28 16:29:24 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E91F3A681A; Tue, 28 Oct 2008 16:29:24 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A83973A6968 for ; Tue, 28 Oct 2008 16:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 re4W6ow6G4ml for ; Tue, 28 Oct 2008 16:29:16 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 801133A681A for ; Tue, 28 Oct 2008 16:29:16 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 244CD20765 for ; Wed, 29 Oct 2008 00:29:14 +0100 (CET) X-AuditID: c1b4fb3c-ae0cebb0000015b5-78-4907a0497507 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F20A220048 for ; Wed, 29 Oct 2008 00:29:13 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 00:29:13 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 00:29:13 +0100 Message-ID: <4907A049.10709@ericsson.com> Date: Wed, 29 Oct 2008 00:29:13 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: multipart/mixed; boundary="------------040102050107000908040503" X-OriginalArrivalTime: 28 Oct 2008 23:29:13.0747 (UTC) FILETIME=[FCC36630:01C93954] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] defaults - needed updates X-BeenThere: netmod@ietf.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. --------------040102050107000908040503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, We agreed on the Reston interim on the following about the handling of defaults Management agents report default data in different ways. o Report all: All default data is always reported. o Trim: Values are not reported if they match the default. o Explicit: Report values if they are explicitly set. We want to accommodate all in YANG. I got the task of proposing some specific additions to the draft. Here they are with some explanation. Balazs ----------------------------------------------------------------------------------- Defaults potentially effect the following stuff: 1) concept of the default Solution: ==== ADD: Add to "7.6 The leaf Statement" "Leafs with a default value, may or may not exist in the conceptual datastore. " 2) get-config/get reply content - Implement the Netconf with-defaults extension, this can force all default values to be returned. I will take the draft to NETCONF. ===== ADD: reference to the with-defaults draft. 3) evaluation of the must/when/unique constraints - "7.8.3 The list's unique Statement" must be extended: ===== ADD: "The unique constraint is conceptually evaluated on all nodes in the data tree, and all leafs with default values." must and when are already OK leafs with defaults are considered as existing during the evaluation of must/when 4) Are the must constraints on a default leafs evaluated Already OK 5) success of edit-config create/delete Different nodes might give different answers to an edit-config operation, but this is not crucial. Error on delete is not important. Instead of create: replace or merge can be used. The different behavior is a consequence of 1). It can be described as a capability in the with-defaults draft. (The manager has the option to just ignore the capability.) 6) Existence of np-containers Already OK Depends on whether default leafs exist. No additional text needed. --------------040102050107000908040503 Content-Type: text/plain; name="defaults.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="defaults.txt" We agreed on the Reston interim on the following about the handling of defaults 3 models of handling defaults: Juniper) defaults don't exist, but if you explicitly set a leaf to its default it exists. Configuration is what you have sent in edit-config. Cisco) defaults don't exist. if you explicitly set a leaf to its default it disappears. Configuration is everything without defaults. Ericsson) Defaults always exist. Configuration is what drives the device. We want to accomodate all in YANG. ---------------------------------------------------- Defaults potentially effect the following stuff: 1) concept of the default Solution: - Add to "7.6 The leaf Statement" Leafs with a default value, may or may not exist in the conceptual datastore. 2) get-config/get reply content - Implement the Netconf with-defaults extension, this can force all default values to be returned. I will take the draft to NETCONF. 3) evaluation of the must/when/unique constraints - "7.8.3 The lists's unique Statement" must be extended: "The unique constraint is conceptually evaluated on all nodes in the data tree, and all leafs with default values." must and when are already OK leafs with defaults are considered as existing during the evaluation of must/when 4) Are the must constraints on a default leafs evaluated Already OK 5) success of edit-config create/delete Different nodes might give different answers to an edit-config operation, but this is not crucial. Error on delete is not important. Intead of create: replace or merge can be used. The different behaviour is a consequence of 1). It can be described as a capability in the with-defaults draft. (The manager has the option to just ignore the capability.) 6) Existence of np-contrainers Already OK Depends on whether default leafs exist. No additional text needed. --------------040102050107000908040503 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 --------------040102050107000908040503-- From netmod-bounces@ietf.org Tue Oct 28 18:03: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 CBCD63A69BB; Tue, 28 Oct 2008 18:03: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 C61563A6CA6 for ; Tue, 28 Oct 2008 18:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_LOOK=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 e0R0398Fwhcy for ; Tue, 28 Oct 2008 18:03:05 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C7A083A6C25 for ; Tue, 28 Oct 2008 18:03:04 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D422F204F4 for ; Wed, 29 Oct 2008 02:03:02 +0100 (CET) X-AuditID: c1b4fb3e-af787bb00000537b-fe-4907b641aa02 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8876620101 for ; Wed, 29 Oct 2008 02:02:57 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 02:02:56 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 02:02:55 +0100 Message-ID: <4907B63F.4070409@ericsson.com> Date: Wed, 29 Oct 2008 02:02:55 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: multipart/mixed; boundary="------------000203080408080805000409" X-OriginalArrivalTime: 29 Oct 2008 01:02:55.0942 (UTC) FILETIME=[13DA4660:01C93962] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] RPCs in lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org This is a multi-part message in MIME format. --------------000203080408080805000409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, On the October Netmod interim and later on the mailing list IMHO there was support to introduce rpcs inside lists and containers because a good number of stakeholders are already using or planning to use similar features. Here are two possible solutions of the rpc-in-list concept. One using the existing rpc statement and an alternative with a new action statement. A common introduction could be: -------------------------------------- The most basic way to think about rpcs/actions related to lists/containers is to think about the following constructs: Allowed today: ------------- container root { list mainList { key mainId; leaf mainId {type string;} } list interface { key interfaceId; leaf interfaceId {type string;} } } rpc restart { input { leaf callingPoint { type instanceidentifier; } } } augment "/restart/input" { when "substring(/restart/input/callingPoint,'/root/mainList')"; leaf firstLeafForRestartInMainList { type string; } } augment "/restart/input" { when "substring(/restart/input/callingPoint,'/root/interface')"; leaf firstLeafForRestartInterface { type string; } } =================================================================== I would rather like to see a proper syntax for this: container root { list mainList { key mainId; leaf mainId {type string;} rpc restart { input { leaf firstLeafForRestartInMainList { type string; } } } } list interface { key interfaceId; leaf interfaceId {type string;} } rpc restart { input { leaf firstLeafForRestartInterface { type string; } } } } } -------------------------------------------------------------- The above two definitions would result in the same XML on the wire, which already today, a YANG compliant agent must accept (if such agent already exists :-). In a way the shorter notation can be considered syntactic sugar for defining rpc statements. For the second notation - Readability, - Understandability - Writability is much better. If the rpc/action really manipulates the managed entity described by the list/container, then the rpc's definition should be done together with the list/container, and we should not force the reader to find the related rpc 3 pages earlier just because it has to be defined on the top level. Encapsulating all definitions affecting the specific list/container, including both data and rpcs, is a good thing. If the rpc is clearly related to the list/container a kind of pointer to the specific list/container should be included in the rpc. There are two options when defining the actions/rpcs in lists/containers statements: - Use the existing rpc statement or alternatively use a new action statement. The two are similar in many ways except the implicit calling-point parameter and the encoding. I provided both options in the attached files. My proposal is to use the rpc statement, as top level rpcs and rpcs inside lists have more in common then what differentiates them. Balazs --------------000203080408080805000409 Content-Type: text/plain; name="rpc.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rpc.txt" Rpcs in lists/containers text for the YANG standard using the existing rpc statement ---------------------------------------------------------------- ADD: rpc will be added as a substatement to list, container and grouping. ** The rpc Statement @rpc@ The "rpc" statement is used to define a NETCONF RPC method. It takes one argument, which is an identifier, followed by a block of substatements that holds detailed rpc information. This argument is the name of the RPC, and is used as the element name directly under the element, as designated by the substitution group "rpcOperation" in ^RFC4741^. The "rpc" statement defines an rpc node in the schema tree. Under the rpc node, an input node with the name "input", and an output node with the name "output" are also defined. The nodes "input" and "output" are defined in the module's namespace. NEW START------------------------------------------------------------------------------ If the rpc statement is a substatement of a container, a list or is part of a grouping that is used inside a container or a list, the NETCONF RPC invocation must have as it's first, implicitly defined, parameter the calling-point parameter which must contain an instance-identifier pointing to a data node, an existing container or list entry, coresponding to the schema location where the rpc is defined. The RPC is conceptually invoked on that container or list-entry. NEW END------------------------------------------------------------------------------ *** The rpc's Substatements !! table !! head ! substatement ! section ! cardinality !! row ! description ! ^description^ ! 0..1 !! row ! grouping ! ^grouping^ ! 0..n !! row ! if-feature ! ^if-feature^ ! 0..n !! row ! input ! ^input^ ! 0..1 !! row ! output ! ^output^ ! 0..1 !! row ! reference ! ^reference^ ! 0..1 !! row ! status ! ^status^ ! 0..1 !! row ! typedef ! ^typedef^ ! 0..n *** The input Statement @input@ The "input" statement, which is optional, is used to define input parameters to the RPC method. It does not take an argument. The substatements to "input" defines nodes under the RPC's input node. If a container in the input tree has a "presence" statement, the container need not be present in a NETCONF RPC invocation. If a leaf in the input tree has a "mandatory" statement with the value "true", the leaf MUST be present in a NETCONF RPC invocation. If a leaf in the input tree has a default value, the NETCONF server MUST internally use this default if the leaf is not present in a NETCONF RPC invocation. If a "config" or "must" statement is present for any node in the input tree, it is ignored. **** The input's Substatements !! table !! head ! substatement ! section ! cardinality !! row ! anyxml ! ^anyxml^ ! 0..n !! row ! augment ! ^augment^ ! 0..n !! row ! choice ! ^choice^ ! 0..n !! row ! container ! ^container^ ! 0..n !! row ! grouping ! ^grouping^ ! 0..n !! row ! leaf ! ^leaf^ ! 0..n !! row ! leaf-list ! ^leaf-list^ ! 0..n !! row ! list ! ^list^ ! 0..n !! row ! typedef ! ^typedef^ ! 0..n !! row ! uses ! ^uses^ ! 0..n *** The output Statement @output@ The "output" statement, which is optional, is used to define output parameters to the RPC method. It does not take an argument. The substatements to "output" defines nodes under the RPC's output node. If a container in the output tree has a "presence" statement, the container need not be present in a NETCONF RPC reply If a leaf in the output tree has a "mandatory" statement with the value "true", the leaf MUST be present in a NETCONF RPC reply. If a leaf in the output tree has a default value, the NETCONF client MUST internally use this default if the leaf is not present in a NETCONF RPC reply. If a "config" or "must" statement is present for any node in the output tree, it is ignored. **** The output's Substatements !! table !! head ! substatement ! section ! cardinality !! row ! anyxml ! ^anyxml^ ! 0..n !! row ! augment ! ^augment^ ! 0..n !! row ! choice ! ^choice^ ! 0..n !! row ! container ! ^container^ ! 0..n !! row ! grouping ! ^grouping^ ! 0..n !! row ! leaf ! ^leaf^ ! 0..n !! row ! leaf-list ! ^leaf-list^ ! 0..n !! row ! list ! ^list^ ! 0..n !! row ! typedef ! ^typedef^ ! 0..n !! row ! uses ! ^uses^ ! 0..n *** XML Encoding Rules An rpc node is encoded as a child XML element to the element defined in ^RFC4741^. The element's name is the rpc's identifier, and its XML namespace is the module's XML namespace. Input parameters are encoded as child XML elements to the rpc node's XML element, in the same order as they are defined within the input statement. NEW START------------------------------------------------------------------------------ If the rpc statement is a substatement of a container, a list or is part of a grouping that is used inside a container or a list the element will have as it's first child element the calling-point parameter, preceeding any elements from the input statement. NEW END------------------------------------------------------------------------------ If the rpc method invocation succeeded, and no output parameters are returned, the contains a single element defined in ^RFC4741^. If output parameters are returned, they are encoded as child elements to the element defined in ^RFC4741^, in the same order as they are defined within the output statement. *** Usage Example The following example defines an RPC method: module rock { namespace "http://example.net/rock"; prefix rock; rpc rock-the-house { input { leaf zip-code { type string; } } } } A corresponding XML encoding of the complete rpc and rpc-reply: 27606-0100 NEW START------------------------------------------------------------------------------ The following example defines an RPC method inside a list: module restart { namespace "http://example.net/restart"; prefix restart; list interface { key name; leaf name { type string; } rpc restart { input { leaf immediate { type boolean; } } } } } A corresponding XML encoding of the complete rpc: /interface[name='eth0'] true The encoding of the rpc-reply is the same as above. NEW END------------------------------------------------------------------------------ --------------000203080408080805000409 Content-Type: text/plain; name="actions-2.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="actions-2.txt" Actions text for YANG standard using a new "action" statement --------------------------------------------------------------- Mention action everywhere rpc is mentioned !!! Action will be a substatement of list, container and grouping. Groupings with actions can only be used inside lists or containers. If uses puts them on the top level they are considered a YANG error. NEW START------------------------------------------------------------------------------ ** The action Statement @action@ The "action" statement is used to define a NETCONF RPC method. It takes one argument, which is an identifier, the name of the action, followed by a block of substatements that hold detailed input and output information. The action statement is very similar to the rpc statement, however the NETCONF RPC encoding of an action will convey a conceptual calling point parameter. This MUST point to an existing container or list entry, corresponding to the schema location where the action is defined. The NETCONF RPC is conceptually invoked on that container or list-entry. The "action" statement defines an action node in the schema tree. Under the action node, an input node with the name "input", and an output node with the name "output" are also defined. The nodes "input" and "output" are defined in the module's namespace. The input node defines the explicitly specified parameters of the to the NETCONF RPC method. The output node defines output parameters in the RPC-REPLY. *** The actions's Substatements !! table !! head ! substatement ! section ! cardinality !! row ! description ! ^description^ ! 0..1 !! row ! grouping ! ^grouping^ ! 0..n !! row ! if-feature ! ^if-feature^ ! 0..n !! row ! input ! ^input^ ! 0..1 !! row ! output ! ^output^ ! 0..1 !! row ! reference ! ^reference^ ! 0..1 !! row ! status ! ^status^ ! 0..1 !! row ! typedef ! ^typedef^ ! 0..n *** XML Encoding Rules An action node is encoded as the content of the element defined in ^RFC4741^. Under the element there will be a single action element from the yang namespace. This will contain a single element. Inside the element an XML subtree will be contained in a manner similar to the operation, according to the possibly multiple levels of lists and containers containing the action. For containers no leafs or leaf-lists will be encoded, for lists only the key leafs will be encoded. Contained lists and containers are included in the encoding, only if they are needed to follow the containment hierarchy all the way down to the action. The above XML subtree will point out the callingpoint in the same manner as an element to be changed is pointed out by the XML hierarchy in the operation. At the appropriate level of containment an element with the name defined by the action statement's argument will be present. TODO: textual description of encoding needs improvement. Input parameters are encoded as subsequent XML child elements, in the same order as they are defined within the input statement. If the NETCONF RPC method invocation succeeded, and no output parameters are returned, the contains a single element defined in ^RFC4741^. If output parameters are returned, they are encoded as child elements to the element defined in ^RFC4741^, in the same order as they are defined within the output statement. *** Usage Example The following example defines an action: module reset { namespace "http://example.net/reset"; prefix reset; list interface { key name; leaf name { type string; } action reset { input { leaf immediate { type boolean; } } } } } A corresponding XML encoding of the complete RPC and RPC-REPLY: eth0 true --------------000203080408080805000409 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 --------------000203080408080805000409-- From netmod-bounces@ietf.org Tue Oct 28 20:19: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 D67DC3A689C; Tue, 28 Oct 2008 20:19: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 46C073A6966 for ; Tue, 28 Oct 2008 20:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=0.390, 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 Yg8tS7x8hGHQ for ; Tue, 28 Oct 2008 20:19:36 -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 66D453A689C for ; Tue, 28 Oct 2008 20:19:36 -0700 (PDT) Received: (qmail 85858 invoked from network); 29 Oct 2008 03:19:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 29 Oct 2008 03:19:34 -0000 X-YMail-OSG: E9lEO8sVM1kDuWJrGWCo13i1K07AnPu6HBvsbGTvfMzPYfB72mZJk0ReVGa.wK0m8SqMxOndbQzy256xT4KZmcqHjAJTx1ABRrBo1ENgPoHaaGaGKWLm9jTH8RsXuYX455rKSqK5vyB_aW6mLzQcoiwY X-Yahoo-Newman-Property: ymail-3 Message-ID: <4907D644.7040806@netconfcentral.com> Date: Tue, 28 Oct 2008 20:19:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Balazs Lengyel References: <4907B63F.4070409@ericsson.com> In-Reply-To: <4907B63F.4070409@ericsson.com> Cc: NETMOD Working Group Subject: Re: [netmod] RPCs in lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Balazs Lengyel wrote: > Hello, > On the October Netmod interim and later on the mailing list IMHO there > was support to introduce rpcs inside lists and containers because a good > number of stakeholders are already using or planning to use similar > features. > > Here are two possible solutions of the rpc-in-list concept. One using > the existing rpc statement and an alternative with a new action > statement. A common introduction could be: > I think this first approach is OK, as long as none of the identifiers in the data-def-stmts are duplicated. Eventually, we might work on YANG 3.0, as Juergen suggests, and at that time, maybe YANG++ will be around to replace YANG. We should not add complexity in YANG clauses now to get 1 OO feature, instead of some big changes later that support lots of OO features. The 1.0 release train needs to leave the station now! Andy > -------------------------------------- > > The most basic way to think about rpcs/actions related to > lists/containers is to think about > the following constructs: > > Allowed today: > ------------- > > container root { > list mainList { > key mainId; > leaf mainId {type string;} > } > > list interface { > key interfaceId; > leaf interfaceId {type string;} > } > } > > rpc restart { > input { > leaf callingPoint { type instanceidentifier; } > } > } > > augment "/restart/input" { > when "substring(/restart/input/callingPoint,'/root/mainList')"; > leaf firstLeafForRestartInMainList { type string; } > } > > augment "/restart/input" { > when "substring(/restart/input/callingPoint,'/root/interface')"; > leaf firstLeafForRestartInterface { type string; } > } > > =================================================================== > > I would rather like to see a proper syntax for this: > > container root { > list mainList { > key mainId; > leaf mainId {type string;} > > rpc restart { > input { > leaf firstLeafForRestartInMainList { type string; } > } > } > } > > list interface { > key interfaceId; > leaf interfaceId {type string;} > } > rpc restart { > input { > leaf firstLeafForRestartInterface { type string; } > } > } > } > } > > -------------------------------------------------------------- > > The above two definitions would result in the same XML on the wire, > which already today, a YANG compliant agent must accept (if such agent > already exists :-). > In a way the shorter notation can be considered syntactic sugar for > defining rpc statements. > > For the second notation > - Readability, > - Understandability > - Writability > is much better. > > If the rpc/action really manipulates the managed entity > described by the list/container, then the rpc's definition should be > done together with the > list/container, and we should not force the reader to find the related > rpc 3 pages earlier just > because it has to be defined on the top level. > > Encapsulating all definitions affecting the specific list/container, > including both data and rpcs, is a good thing. > > If the rpc is clearly related to the list/container a kind of pointer to > the specific > list/container should be included in the rpc. > > > > > There are two options when defining the actions/rpcs in lists/containers > statements: > > - Use the existing rpc statement or alternatively use a new action > statement. The two are similar in many ways except the implicit > calling-point parameter and the encoding. I provided > both options in the attached files. > > My proposal is to use the rpc statement, as top level rpcs and rpcs > inside lists have more in common then what differentiates them. > > Balazs > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Tue Oct 28 20: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 F0B483A6880; Tue, 28 Oct 2008 20: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 0017C3A6A73 for ; Tue, 28 Oct 2008 20:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.793 X-Spam-Level: X-Spam-Status: No, score=-2.793 tagged_above=-999 required=5 tests=[AWL=-0.544, 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 u7GveF9cMTOM for ; Tue, 28 Oct 2008 20:47:19 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 047EA3A6880 for ; Tue, 28 Oct 2008 20:47:19 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 97DB5C0048; Wed, 29 Oct 2008 04:47:17 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Z+oZOn85miz5; Wed, 29 Oct 2008 04:47:08 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 164CCC001D; Wed, 29 Oct 2008 04:47:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CF94682DFF2; Wed, 29 Oct 2008 04:47:06 +0100 (CET) Date: Wed, 29 Oct 2008 04:47:06 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20081029034706.GA2467@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group References: <4907895C.3010807@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4907895C.3010807@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: NETMOD Working Group Subject: Re: [netmod] YANG notification content proposal 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, Oct 28, 2008 at 02:51:24PM -0700, Andy Bierman wrote: [...] > I think this will make YANG notifications better: > * easier to understand > * more consistent with SMIv2 notifications > * allows arbitrary content, not just leafs > * XPath allows simpler and less verbose encoding than XML > for specifying the path from root with all the key values > * notification-only content and copy of config object content > are clearly distinguished, and each is easy to specify Carrying XPATH in instance documents is IMHO a major change and it might take some effort to convince myself this is goodness. /js PS: I am wondering why all this is supposed to be notification specific. I can very well envision to carry "objects" as RPC input/output parameters - so if a new mechanism is needed (and I am not convinced yet) it should probably more general. -- 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 Oct 29 01:46:26 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 029C33A69F4; Wed, 29 Oct 2008 01:46:26 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3A0C28C27D for ; Wed, 29 Oct 2008 01:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id becWXCMUIPv0 for ; Wed, 29 Oct 2008 01:46:23 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0E3983A69F4 for ; Wed, 29 Oct 2008 01:46:23 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B1B5C20CC4 for ; Wed, 29 Oct 2008 09:46:06 +0100 (CET) X-AuditID: c1b4fb3c-ae8cfbb0000015b5-ae-490822ce67da Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9AC5B20DD3 for ; Wed, 29 Oct 2008 09:46:06 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 09:46:06 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 09:46:06 +0100 Content-Disposition: inline From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 29 Oct 2008 09:46:05 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Message-Id: <200810290946.06001.david.partain@ericsson.com> X-OriginalArrivalTime: 29 Oct 2008 08:46:06.0368 (UTC) FILETIME=[C83CC200:01C939A2] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Proposed consensus mail on yang-00776: "Augmentable Groupings" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings, This is a call for consensus about issue 'yang-00776: "Augmentable Groupings"'. See the wiki at http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00776 After a very brief discussion, the rough consensus of the interim meeting was NOT to include this change at this time. PLEASE speak up if you favor or object to this decision (including people who attended the interim). Silence is impossible to interpret. Cheers, David(s) _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 01:47: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 19DDA3A69F4; Wed, 29 Oct 2008 01:47: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 7E62D3A69F4 for ; Wed, 29 Oct 2008 01:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJDhRJymCIbz for ; Wed, 29 Oct 2008 01:47:53 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 6682C3A6877 for ; Wed, 29 Oct 2008 01:47:53 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C27E322194 for ; Wed, 29 Oct 2008 09:44:50 +0100 (CET) X-AuditID: c1b4fb3e-aff88bb00000537b-fa-49082282e295 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A9ECB21577 for ; Wed, 29 Oct 2008 09:44:50 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 09:44:50 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 09:44:50 +0100 Content-Disposition: inline From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 29 Oct 2008 09:44:49 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Message-Id: <200810290944.49931.david.partain@ericsson.com> X-OriginalArrivalTime: 29 Oct 2008 08:44:50.0525 (UTC) FILETIME=[9B0808D0:01C939A2] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Proposed scope of the DSDL mapping 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, (Again, fixed-width fonts might be needed to make sense of what's below.) At the interim meeting, we discussed the scope of the DSDL mapping work at some length. Ladislav Lhotka wondered about the language and positioning of DSDL mapping in the architecture document. The DSDL mapping should express in a formal way what the YANG draft says. The question was primarily about whether the purpose of the DSDL mapping is for validation of the configuration datastore _and_ the validation of PDUs or if it's limited to only the former. Ladislav has been initially targeting the former in the DSDL mapping work he has been doing. So, something like this.... Full DB PDUs .yang -> .dsdl -> xslt -> get-config.dsdl -> xslt -> edit-config.dsdl -> xslt -> copy-config.dsdl -> xslt -> rpc1.dsdl -> xslt -> rpcN.dsdl The .dsdl document created from the YANG module(s) will be useful for the entire configuration datastore. Thereafter, XSLT scripts can be used to do appropriate work to validate PDUs. The consensus of the room at the interim was that the initial focus for the mapping document will be the full datastore (generating the .dsdl above). In order to be able to do this, you have to have access to all of the YANG modules used by the system. Ladislav explained that since the inclusion mechanism is different, the modularity won't be maintained. Rather than individual .dsdl files for each of the input YANG modules, it's a "cooked module" containing the combination of all of the YANG modules. Thereafter, the WG will be consider whether to work farther on the PDU part, but still in the mapping document. This is a recognition of the concern voiced by David Harrington that we can't focus on everything that might be useful, so let's focus on something concrete that can be useful. Cheers, David(s) _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 01:51: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 4D82D3A6877; Wed, 29 Oct 2008 01:51: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 83DC03A6C92 for ; Wed, 29 Oct 2008 01:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.033, 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 et3kMqaP-W5k for ; Wed, 29 Oct 2008 01:51:45 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 39AF13A6877 for ; Wed, 29 Oct 2008 01:51:45 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7032420379 for ; Wed, 29 Oct 2008 09:51:43 +0100 (CET) X-AuditID: c1b4fb3e-acf82bb00000537b-39-4908241f2131 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4E324201C6 for ; Wed, 29 Oct 2008 09:51:43 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 09:51:43 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 09:51:43 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 29 Oct 2008 09:51:42 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200810290951.42732.david.partain@ericsson.com> X-OriginalArrivalTime: 29 Oct 2008 08:51:43.0132 (UTC) FILETIME=[90F6DDC0:01C939A3] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Proposed consensus on yang-01281: conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Greetings, This is a call for consensus about issue 'yang-1281: conformance'. See the wiki at http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-01281 for an introduction. PLEASE speak up if you favor the changes or object to the text (including people who attended the interim). On Oct 3, Martin Bj=F6rklund and Phil Shafer proposed how YANG should handle conformance. That proposal was published as a delta of the current YANG draft. Mail about the proposal can be found at http://www.ietf.org/mail-archive/web/netmod/current/msg01281.html The discussion at the interim focused very heavily on so-called deviations and (1) if they should be documented in a standardized way and (2) if so, whether the proposal should be used. (For those familiar with SNMP, this is much like AGENT-CAPABILITIES for SNMP.) Do we want to be able to document where there are deviations or not? Discussion: * David Harrington: what is the economic incentive for vendors to document their deviations? Andy agrees that this is not going to happen. * J=FCrgen Sch=F6nw=E4lder: by the time we got to AGENT-CAPABILITIES in SNMP, the battle was already lost. * Martin Bj=F6rklund: we want to make it possible to get the variations from the box. Martin's tools actually can use the deviations to drive what their tools do. * David Partain: could the deviations be useful even if vendors don't produce the document? e.g., user communities? * David Harrington: What about conditional compliance? How do we handle that? * Andy Bierman: if this is done, wants to see it in a separate document, rather than as part of the YANG language specification. * David Harrington: the deviations might not be something within the charter. Ladislav Lhotka said that we are the ones defining what's in the language, so we can make it in charter by making it part of the language. * David Partain: we're trying to provide three sets of input to the configuration management application - the module itself, the conformance level to which they conform, and the deviation files written by a vendor or by the user community, all to be able to drive the application better. "When we've run our applications against device foo, we've seen the following behavior" and document it formally as a deviation. I would argue that this deviation fills exactly the same role as the AGENT-CAPABILITIES was supposed to fill. * David Reid: that's in theory a good thing and something that we still want, even if it hasn't been successful in SNMP. * David Harrington: the AGENT-CAPABILITIES has been shown not to work. If you want to design something that does work, it's going to be difficult. Maybe this should be done where benchmarking work can be done rather than in this working group. Not our job to describe how they report how well something does work. Mehmet Ersue: it's a report that you can't really verify. * David Partain: I think the deviations would be something built up internally within an operator. Andy Bierman: yes, for internal documentation. Phil Shafer: or the network service provider lists could exchange information about deviations on the list. * Mehmet Ersue: would this be optional? Martin Bj=F6rklund: yes. * Andy Bierman: this is at the level of release notes. If there's a mandatory node in a data model, the deviation says it's not there, how will the application (client) actually continue to work? Martin Bj=F6rklund: mandatory isn't any different from any other deviation. The client application can adapt to the fact of that deviation. * Andy Bierman : The text must state that deviations in no way state a level of conformance. In fact, they mean you are NOT conformant. Phil Shafer: I disagree. If I have a node that doesn't have an upper bound and I advertise that I'm limited, that doesn't make me non-conformant. There are going to be things that you can deviate on that do not automatically make yourself non-conformant. Martin Bj=F6rklund: we need to work out the details. * Ladislav Lhotka: why can't you define your model to deal with the deviations? Andy Bierman: sometimes you should model things in the module itself that reflect the deviation (i.e., how to show what the current resource possibilities are for a table). Martin Bj=F6rklund: there might be hardware limits for a resource that should be reflected in the deviations. Questions posed regarding this issue: 1. Should there be a formal way of describing the deviations of a particular device? There was rough consensus that we should have a formal syntax for documenting deviations. 2. Should this work be done in this working group? There was almost complete consensus that it should (David Harrington opposed.) 3. Should the document say anything about how to organize these statements in a module? A long discussion about whether to intermingle these statements with other language constructs. David Partain recommended that we state that one SHOULD put the deviations in a separate module. Should we have a statement that says whether this should be in a separate module or not? Juergen: this is organizational; we shouldn't go there. Editor: There is no documented consensus on this question. 4. Are we reasonably happy with the syntax (with caveat that there is tweaking and clarification to be done)? There was rough consensus that we start with the syntax as it currently is. Cheers, David(s) _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 02: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 78A003A67E7; Wed, 29 Oct 2008 02: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 0F7E43A69F5 for ; Wed, 29 Oct 2008 02:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 qp6tXMQk4KCv for ; Wed, 29 Oct 2008 02:35:36 -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 23CF43A67E7 for ; Wed, 29 Oct 2008 02:35:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,505,1220241600"; d="scan'208";a="140225084" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 29 Oct 2008 05:35:34 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 29 Oct 2008 05:35:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 29 Oct 2008 10:35:33 +0100 Message-ID: In-Reply-To: <200810290951.42732.david.partain@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Proposed consensus on yang-01281: conformance Thread-Index: Ack5o5uIQyi7okeeTEaTc5um6amnEwABZmjA References: <200810290951.42732.david.partain@ericsson.com> From: "Romascanu, Dan (Dan)" To: "David Partain" , Subject: Re: [netmod] Proposed consensus on yang-01281: conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Contributor opinions: > -----Original Message----- > From: netmod-bounces@ietf.org ... > > Questions posed regarding this issue: > > 1. Should there be a formal way of describing the deviations > of a particular device? There was rough consensus that we > should have a formal syntax for documenting deviations. I support this. > > 2. Should this work be done in this working group? There > was almost complete consensus that it should (David Harrington > opposed.) I support doing it in this WG as part of NETMOD definition. > > 3. Should the document say anything about how to organize > these statements in a module? A long discussion about > whether to intermingle these statements with other language > constructs. > David Partain recommended that we state that one SHOULD put > the deviations in a separate module. Should we have a > statement that says whether this should be in a separate > module or not? > Juergen: this is organizational; we shouldn't go there. Editor: > There is no documented consensus on this question. Having missed the 'long discussion' I am not sure I understand all the details and arguments, but putting deviations in a separate module makes more sense to me. > > 4. Are we reasonably happy with the syntax (with caveat that > there is tweaking and clarification to be done)? There was > rough consensus that we start with the syntax as it currently is. Good starting point. Dan _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 03:25: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 2C8263A683F; Wed, 29 Oct 2008 03:25: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 DC08F3A68B9 for ; Wed, 29 Oct 2008 03:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.161 X-Spam-Level: X-Spam-Status: No, score=-6.161 tagged_above=-999 required=5 tests=[AWL=0.088, 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 SccAFd5iKTpX for ; Wed, 29 Oct 2008 03:25:41 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id ADA143A683F for ; Wed, 29 Oct 2008 03:25:40 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2FDE52100F; Wed, 29 Oct 2008 11:24:17 +0100 (CET) X-AuditID: c1b4fb3c-aa8c7bb0000015b5-41-490839d0e3aa Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F36E9211F9; Wed, 29 Oct 2008 11:24:16 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 11:24:16 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 11:24:16 +0100 Message-ID: <490839CF.8000007@ericsson.com> Date: Wed, 29 Oct 2008 11:24:15 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <4907895C.3010807@netconfcentral.com> In-Reply-To: <4907895C.3010807@netconfcentral.com> X-OriginalArrivalTime: 29 Oct 2008 10:24:16.0731 (UTC) FILETIME=[7F2AD2B0:01C939B0] X-Brightmail-Tracker: AAAAAA== Cc: NETMOD Working Group Subject: Re: [netmod] YANG notification content proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Isn't the leafref supposed to solve this problem? Instead of locally creating the leafs in the notification you just reference them. Balazs Andy Bierman wrote: > Hi, > > I do think the YANG notification construct is quite good enough. > SMIv2 provides an OBJECTS list in the notification definition, > so copies of 'real' objects can be easily included in the > payload without any redefining needed. > > YANG requires 'local' nodes to be created within the notification > statement, which are like SMIv2 'notification-only' objects. > The problem is that this mode is the exception, not the > common case. > > A NETCONF notification cannot really support an SMIv2-style object. > You have to provide the entire XML instance tree for the root > to any given 'object' node. There is no XML 'varbind', > which contains a fully specified object instance ID and > a value. > > This would only work well if the YANG to XML encoding was something > like SMIv2: > > Implied XML content from the object-stmt: > > container object { > config false; > leaf id { type instance-identifier; } > anyxml value; > } > > Example notification-stmt: > > notification mtu-changed { > description "Return the new MTU value when it changes."; > > object /if:interfaces/if:interface/if:mtu { > description > "Identifies the interface instance that changed, > and the new MTU value for that interface."; > } > > leaf changed-by { > description "Indicates how the MTU was changed."; > type enumeration { > enum other; > enum agent; > enum manager; > } > } > } > > Example PDU: > > > > 2008-10-28T14:46:04.000-07:00 > > > /if:interfaces/if:interface[if:name='eth0']/if:mtu > 1518 > > manager > > > > I think this will make YANG notifications better: > * easier to understand > * more consistent with SMIv2 notifications > * allows arbitrary content, not just leafs > * XPath allows simpler and less verbose encoding than XML > for specifying the path from root with all the key values > * notification-only content and copy of config object content > are clearly distinguished, and each is easy to specify > > > Andy > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 04:37: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 2B3ED3A69F5; Wed, 29 Oct 2008 04:37: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 78EC43A6AEA for ; Wed, 29 Oct 2008 04:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.325, 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 xY6P91MIIynX for ; Wed, 29 Oct 2008 04:37:21 -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 A14533A69F5 for ; Wed, 29 Oct 2008 04:37:21 -0700 (PDT) Received: (qmail 20935 invoked from network); 29 Oct 2008 11:37:20 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 29 Oct 2008 11:37:18 -0000 X-YMail-OSG: 9kmW3RoVM1n7taqMvKkv1NAq_4kE8Rkt7AiCX629m9DJBgX.FSQd94uPMY2wr0glvArhhJI.TiHg0inKbibvPLQkB_SGUWvaExa0Zse3aIRqMiY95_haG0P4BmfrtIl5qkBDw7UI0OGZPUQVEoA3w58H X-Yahoo-Newman-Property: ymail-3 Message-ID: <49084AED.7050106@netconfcentral.com> Date: Wed, 29 Oct 2008 04:37:17 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Balazs Lengyel References: <4907895C.3010807@netconfcentral.com> <490839CF.8000007@ericsson.com> In-Reply-To: <490839CF.8000007@ericsson.com> Cc: NETMOD Working Group Subject: Re: [netmod] YANG notification content proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: > Isn't the leafref supposed to solve this problem? > Instead of locally creating the leafs in the notification you just > reference them. leafref only works when you specify all the keys. It falls apart as soon as the desired leaf is nested within 2 or more lists. But I agree with Juergen that this is not a notification-only issue. Certainly anything send in a notification can also be sent in an . I don't mind punting this, and every single new feature, since YANG is already too complicated. The 80/20 rule has to kick in before the draft tops 200 pages. > Balazs Andy > > Andy Bierman wrote: >> Hi, >> >> I do think the YANG notification construct is quite good enough. >> SMIv2 provides an OBJECTS list in the notification definition, >> so copies of 'real' objects can be easily included in the >> payload without any redefining needed. >> >> YANG requires 'local' nodes to be created within the notification >> statement, which are like SMIv2 'notification-only' objects. >> The problem is that this mode is the exception, not the >> common case. >> >> A NETCONF notification cannot really support an SMIv2-style object. >> You have to provide the entire XML instance tree for the root >> to any given 'object' node. There is no XML 'varbind', >> which contains a fully specified object instance ID and >> a value. >> >> This would only work well if the YANG to XML encoding was something >> like SMIv2: >> >> Implied XML content from the object-stmt: >> >> container object { >> config false; >> leaf id { type instance-identifier; } >> anyxml value; >> } >> >> Example notification-stmt: >> >> notification mtu-changed { >> description "Return the new MTU value when it changes."; >> >> object /if:interfaces/if:interface/if:mtu { >> description >> "Identifies the interface instance that changed, >> and the new MTU value for that interface."; >> } >> >> leaf changed-by { >> description "Indicates how the MTU was changed."; >> type enumeration { >> enum other; >> enum agent; >> enum manager; >> } >> } >> } >> >> Example PDU: >> >> >> >> 2008-10-28T14:46:04.000-07:00 >> >> >> /if:interfaces/if:interface[if:name='eth0']/if:mtu >> 1518 >> >> manager >> >> >> >> I think this will make YANG notifications better: >> * easier to understand >> * more consistent with SMIv2 notifications >> * allows arbitrary content, not just leafs >> * XPath allows simpler and less verbose encoding than XML >> for specifying the path from root with all the key values >> * notification-only content and copy of config object content >> are clearly distinguished, and each is easy to specify >> >> >> 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 Oct 29 04:55: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 E00D03A682E; Wed, 29 Oct 2008 04:55: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 6B8C13A686D for ; Wed, 29 Oct 2008 04:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.746 X-Spam-Level: X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[AWL=1.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 Za33LwYwUjpx for ; Wed, 29 Oct 2008 04:55:55 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 92C163A682E for ; Wed, 29 Oct 2008 04:55:55 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 28E0076C4F7; Wed, 29 Oct 2008 12:55:53 +0100 (CET) Date: Wed, 29 Oct 2008 12:55:13 +0100 (CET) Message-Id: <20081029.125513.173963703.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <4907A049.10709@ericsson.com> References: <4907A049.10709@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] defaults - needed updates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Balazs Lengyel wrote: > 1) concept of the default > Solution: > ==== ADD: > Add to "7.6 The leaf Statement" > "Leafs with a default value, may or may not exist in the conceptual > datastore. " I think this makes sense. > 2) get-config/get reply content > - Implement the Netconf with-defaults extension, this can > force all default values to be returned. I will take the draft to NETCONF. > ===== ADD: > reference to the with-defaults draft. Do you want to force servers implementing YANG to also implement :with-defaults? Or simply mention the problem and add a reference to a solution (:with-defaults)? > 3) evaluation of the must/when/unique constraints > - "7.8.3 The list's unique Statement" must be extended: > ===== ADD: > "The unique constraint is conceptually evaluated on all nodes in the > data tree, and all leafs with default values." How about this: OLD: In a valid configuration, the combined values of all the leaf instances specified in the string MUST be unique within all list entry instances. NEW: In a valid configuration, the combined values of all the leaf instances specified in the string, including leafs with default values, MUST be unique within all list entry instances. > 5) success of edit-config create/delete > Different nodes might give different answers to an edit-config > operation, but this is not crucial. Error on delete is > not important. Instead of create: replace or merge can be used. > The different behavior is a consequence of 1). It can be described as a > capability in the with-defaults draft. > (The manager has the option to just ignore the capability.) I think this one falls out from 1) above. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 05:55: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 69DE23A6CE6; Wed, 29 Oct 2008 05:55: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 5FAB53A6D05 for ; Wed, 29 Oct 2008 05:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[AWL=0.650, 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 utVGQ0UWQHsH for ; Wed, 29 Oct 2008 05:55: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 CF1F53A6CE6 for ; Wed, 29 Oct 2008 05:55:02 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9974376C4F7; Wed, 29 Oct 2008 13:55:01 +0100 (CET) Date: Wed, 29 Oct 2008 13:54:57 +0100 (CET) Message-Id: <20081029.135457.60677113.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <490629BC.2050407@netconfcentral.com> References: <4905DA5F.5010104@netconfcentral.com> <20081027.211806.219004300.mbj@tail-f.com> <490629BC.2050407@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] data model 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 Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi, > > Wouldn't it work if we do import by revision, and add your conformance > > statement minus uses-import? > > There can be multiple conformance statements, specifying different > > conformance levels. The conformance level is advertised in the hello > > message. If no conformance level is advertised, the agent claims full > > conformance to all features it advertises. > > Each conformance level specify the 'object-variance' for each leaf / > > subtree it modifies: > > conformance partial { > > description > > "Devices that cannot modify XXX in their hardware may claim > > partial conformance."; > > object-variance "/top/foo/bar" { > > config false; > > } object-variance "/top/foo/baz" { > > config false; > > } } > > conformance read-only { > > // the entire module is read only on this conformance level > > object-variance "/top" { > > config false; > > } > > } > > > > I like this a lot, but import-by-revision is irrelevant to > the problem of partial conformance levels. Agreed. I just meant that your conformance idea could also work with import-by revision, it doesn't have to include used-import. > IMO, this solves part of the ipfix request: fine-grained mods > to full conformance. Yes. > The capability mechanism in the protocol > already exists for course-grained conformance, so I don't > see why feature/if-feature is a must-have right now. But then we're saying that if you want to partition your module, you must split it into several modules, each with its own namespace etc. The feature construct is supposed to make a more light-weight construct available to the module designer. One module is reported as one capability. Each module can have zero or more features (or "sub-capabilities"). I like your 'conformance' statement for specifying conformance levels, and I think it works nicely togther with 'feature' and 'deviation'. It also works with "import by revision", if we decide to do that. I would like to see a detailed proposal for this conformance statement, and I'm prepared to work on this. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 05:56: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 807EE3A67A6; Wed, 29 Oct 2008 05:56: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 48D4B3A6885 for ; Wed, 29 Oct 2008 05:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.167 X-Spam-Level: X-Spam-Status: No, score=-6.167 tagged_above=-999 required=5 tests=[AWL=0.082, 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 F9bmuAQoFfs6 for ; Wed, 29 Oct 2008 05:56:02 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 246123A6CE6 for ; Wed, 29 Oct 2008 05:55:37 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DB8D12122D for ; Wed, 29 Oct 2008 13:54:04 +0100 (CET) X-AuditID: c1b4fb3c-ac0cabb0000015b5-06-49085ceced8a Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C3F0D21229 for ; Wed, 29 Oct 2008 13:54:04 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 13:54:04 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 13:54:04 +0100 Message-ID: <49085CEB.7080701@ericsson.com> Date: Wed, 29 Oct 2008 13:54:03 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Partain References: <200810290946.06001.david.partain@ericsson.com> In-Reply-To: <200810290946.06001.david.partain@ericsson.com> X-OriginalArrivalTime: 29 Oct 2008 12:54:04.0624 (UTC) FILETIME=[6C5E7500:01C939C5] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Proposed consensus mail on yang-00776: "Augmentable Groupings" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I am sad but I agree with the consensus. Balazs David Partain wrote: > Greetings, > > This is a call for consensus about issue > 'yang-00776: "Augmentable Groupings"'. See the wiki at > http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00776 > > After a very brief discussion, the rough consensus of the interim > meeting was NOT to include this change at this time. > > PLEASE speak up if you favor or object to this decision > (including people who attended the interim). Silence is > impossible to interpret. > > Cheers, > > David(s) > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 06:01: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 F1E253A686B; Wed, 29 Oct 2008 06:01: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 1634B3A686B for ; Wed, 29 Oct 2008 06:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.172 X-Spam-Level: X-Spam-Status: No, score=-6.172 tagged_above=-999 required=5 tests=[AWL=0.077, 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 oXrSN2gDldZe for ; Wed, 29 Oct 2008 06:01:04 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 293743A6885 for ; Wed, 29 Oct 2008 06:01:04 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5758720DDD; Wed, 29 Oct 2008 14:01:02 +0100 (CET) X-AuditID: c1b4fb3c-ab0c8bb0000015b5-56-49085e8e0b58 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 30FB420997; Wed, 29 Oct 2008 14:01:02 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 14:01:02 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 14:01:01 +0100 Message-ID: <49085E8D.4010300@ericsson.com> Date: Wed, 29 Oct 2008 14:01:01 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <4907A049.10709@ericsson.com> <20081029.125513.173963703.mbj@tail-f.com> In-Reply-To: <20081029.125513.173963703.mbj@tail-f.com> X-OriginalArrivalTime: 29 Oct 2008 13:01:01.0947 (UTC) FILETIME=[651CE4B0:01C939C6] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] defaults - needed updates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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, > > Balazs Lengyel wrote: > >> 1) concept of the default >> Solution: >> ==== ADD: >> Add to "7.6 The leaf Statement" >> "Leafs with a default value, may or may not exist in the conceptual >> datastore. " > > I think this makes sense. > >> 2) get-config/get reply content >> - Implement the Netconf with-defaults extension, this can >> force all default values to be returned. I will take the draft to NETCONF. >> ===== ADD: >> reference to the with-defaults draft. > > Do you want to force servers implementing YANG to also implement > :with-defaults? Or simply mention the problem and add a reference to > a solution (:with-defaults)? BALAZS: Just recommend the implementation and add reference. > > >> 3) evaluation of the must/when/unique constraints >> - "7.8.3 The list's unique Statement" must be extended: >> ===== ADD: >> "The unique constraint is conceptually evaluated on all nodes in the >> data tree, and all leafs with default values." > > How about this: > > OLD: > In a valid configuration, the combined values of all the leaf > instances specified in the string MUST be unique within all list entry > instances. > > NEW: > In a valid configuration, the combined values of all the leaf > instances specified in the string, including leafs with default > values, MUST be unique within all list entry instances. > BALAZS: OK > >> 5) success of edit-config create/delete >> Different nodes might give different answers to an edit-config >> operation, but this is not crucial. Error on delete is >> not important. Instead of create: replace or merge can be used. >> The different behavior is a consequence of 1). It can be described as a >> capability in the with-defaults draft. >> (The manager has the option to just ignore the capability.) > > I think this one falls out from 1) above. BALAZS: OK _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 06:29: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 79A6F3A6CE1; Wed, 29 Oct 2008 06:29: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 58B063A686B for ; Wed, 29 Oct 2008 06:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.177 X-Spam-Level: X-Spam-Status: No, score=-6.177 tagged_above=-999 required=5 tests=[AWL=0.072, 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 oPCIkq3be+rh for ; Wed, 29 Oct 2008 06:29:13 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 53C7F3A6D09 for ; Wed, 29 Oct 2008 06:29:13 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4A02E213FE for ; Wed, 29 Oct 2008 14:28:19 +0100 (CET) X-AuditID: c1b4fb3c-ad8cdbb0000015b5-b3-490864f37fe7 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2A6D520A29 for ; Wed, 29 Oct 2008 14:28:19 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 14:28:18 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 14:28:18 +0100 Message-ID: <490864F2.9000109@ericsson.com> Date: Wed, 29 Oct 2008 14:28:18 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETMOD Working Group X-OriginalArrivalTime: 29 Oct 2008 13:28:18.0796 (UTC) FILETIME=[34C03AC0:01C939CA] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Function freeze - call for consensus ??? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, I would like to propose that the workgroup agrees on a function freeze for YANG. Anything that was not proposed by the end of November, should go into YANG 2.0. This can be changed if we have very strong support/consensus for some new feature, but could we set this as a guideline? Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 06:32: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 A691D3A6894; Wed, 29 Oct 2008 06:32: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 0502A3A68F3 for ; Wed, 29 Oct 2008 06:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.068, 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 G7lAms0Q+3Ru for ; Wed, 29 Oct 2008 06:32:09 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9DD523A6894 for ; Wed, 29 Oct 2008 06:32:09 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BDE7720D4C for ; Wed, 29 Oct 2008 14:32:07 +0100 (CET) X-AuditID: c1b4fb3c-b00d2bb0000015b5-ea-490865d753ad Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A02D12078F for ; Wed, 29 Oct 2008 14:32:07 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 14:32:07 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 14:32:06 +0100 Message-ID: <490865D6.4000100@ericsson.com> Date: Wed, 29 Oct 2008 14:32:06 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETMOD Working Group X-OriginalArrivalTime: 29 Oct 2008 13:32:07.0326 (UTC) FILETIME=[BCF723E0:01C939CA] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Proposals for the agenda X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello David and David, Some items I would like to see on the NETMOD agenda: - rpcs in lists - default handling - allowed substatements of groupings - function freeze for YANG 1.0 Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 07: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 335383A6D21; Wed, 29 Oct 2008 07: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 567BB3A6D29 for ; Wed, 29 Oct 2008 07:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[AWL=0.433, 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 9NH2zx0RAeiX for ; Wed, 29 Oct 2008 07:37:45 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 034253A6889 for ; Wed, 29 Oct 2008 07:37:45 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 2D47B76C4F7; Wed, 29 Oct 2008 15:37:43 +0100 (CET) Date: Wed, 29 Oct 2008 15:37:39 +0100 (CET) Message-Id: <20081029.153739.92872679.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20081026095003.GA2622@elstar.local> References: <20081026095003.GA2622@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] types-011: multiple lexical representations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi, Juergen Schoenwaelder wrote: > Some types allow multiple representations of the same value. A good > example are IPv6 addresses, e.g. ::1 and 0:0:0:0:0:0:0:1. This raises > several questions: > > 1) We need to define how comparisions are done. At the interim, there > was agreement that comparisons are done in the value space so the > fact that there might be different lexical representations for the > same value becomes a non-issue. (This needs to be confirmed on the > mailing list.) I agree with this. > 2) At the interim meeting, there was agreement to define normalization > rules - the basic idea here is the following: > > a) implementations MUST accept normalized values as input > b) implementations MUST generate normalized values as output > c) implementations MAY accept non-normalized values as input I do not agree with c. Which I guess means that I don't agree with b either. I see a value in having both a normalized value and a less constrained lexical value if the rules were: a') implementations MUST accept normalized values as input b') implementations SHOULD generate normalized values as output c') implementations MUST accept non-normalized values as input If we do a + b in your list, then I don't think we should bother with specifying anything but the normalized value. > In general, it was preferred that implementations do not have to > remember the representation that was used to configure a value. It > should be sufficient to just store the value. (This needs to be > confirmed on the mailing list.) I agree with this. > 3) There was no agreement how we write down normalization rules are the > interim meeting. There are several options: > > (1) we simply add text to description statements > > (2) we introduce a separate statement with a separate description > clause, e.g. > > normalization { > description "turn all characters to lower case"; > } Or maybe 'normalization "turn on all characters to lower case";' > (3) we introduce a separate statement with a separate description > clause and allow an additional pattern that can be more > restrictive for normalized values, e.g. > > normalization { > pattern "[a-z]"; > description "normalized representation is in lower case"; > } I wouldn't mind (3), but I don't think it is necessary. I like (2) better than (1) because it tells a module designer that YANG recognizes the problem of normalization, and provides a solution for it. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 07:49: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 7C1D83A6D2F; Wed, 29 Oct 2008 07:49: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 BFED328C10A for ; Wed, 29 Oct 2008 07:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.363, 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 oiJNsOZ0Wja1 for ; Wed, 29 Oct 2008 07:48:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C61293A6D2E for ; Wed, 29 Oct 2008 07:48:59 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D9D7C002E; Wed, 29 Oct 2008 15:48:58 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jI2ONKW51jpV; Wed, 29 Oct 2008 15:48:53 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 440C3C002D; Wed, 29 Oct 2008 15:48:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2368283C915; Wed, 29 Oct 2008 15:48:52 +0100 (CET) Date: Wed, 29 Oct 2008 15:48:51 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20081029144851.GA19261@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20081026095003.GA2622@elstar.local> <20081029.153739.92872679.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20081029.153739.92872679.mbj@tail-f.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] types-011: multiple lexical representations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, Oct 29, 2008 at 03:37:39PM +0100, Martin Bjorklund wrote: [...] > I wouldn't mind (3), but I don't think it is necessary. I like (2) > better than (1) because it tells a module designer that YANG > recognizes the problem of normalization, and provides a solution for > it. A module designer either puts in the right text or not because he either understands the issue or not. I do not think that the existance of an additional keyword has much impact on whether the designer understands the issue or not. So I personally can live with (3) although (1) might be good enough - depends a little bit on the rules though and what the regex really means. In other words, I think (2) is a bad choice. /js PS: The URI type in the collection of YANG types actually has normalization text that was carried over from the corresponding SMIv2 TC definition. This tells me that we dealt with some of this before by using description clauses. -- 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 Oct 29 08:02: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 A811D28C3AF; Wed, 29 Oct 2008 08:02: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 0820628C3D6 for ; Wed, 29 Oct 2008 08:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[AWL=0.325, 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 L+dkKHyGl4yb for ; Wed, 29 Oct 2008 08:01:54 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 214ED28C3CE for ; Wed, 29 Oct 2008 08:01:16 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id DF67C76C4F7; Wed, 29 Oct 2008 16:01:14 +0100 (CET) Date: Wed, 29 Oct 2008 16:01:12 +0100 (CET) Message-Id: <20081029.160112.210635359.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20081029144851.GA19261@elstar.local> References: <20081026095003.GA2622@elstar.local> <20081029.153739.92872679.mbj@tail-f.com> <20081029144851.GA19261@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] types-011: multiple lexical representations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Juergen Schoenwaelder wrote: > On Wed, Oct 29, 2008 at 03:37:39PM +0100, Martin Bjorklund wrote: > > [...] > > > I wouldn't mind (3), but I don't think it is necessary. I like (2) > > better than (1) because it tells a module designer that YANG > > recognizes the problem of normalization, and provides a solution for > > it. > > A module designer either puts in the right text or not because he > either understands the issue or not. Sure, but with an explicit keyword the module designer that *does* think about the issue knows that the concept is supported in the language. And maybe the explicit keyword will help the designer understand the issue and remember to think about it. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 09:26:50 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FD1C3A68CE; Wed, 29 Oct 2008 09:26:50 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D3593A6A8A for ; Wed, 29 Oct 2008 09:26:49 -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 tgIB6vStQD25 for ; Wed, 29 Oct 2008 09:26:48 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id F0DEA3A68CE for ; Wed, 29 Oct 2008 09:26:47 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id B227CD800BD for ; Wed, 29 Oct 2008 17:26:45 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20081029.153739.92872679.mbj@tail-f.com> References: <20081026095003.GA2622@elstar.local> <20081029.153739.92872679.mbj@tail-f.com> Organization: CESNET Date: Wed, 29 Oct 2008 17:26:46 +0100 Message-Id: <1225297606.15270.27.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] types-011: multiple lexical representations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTdCAyOS4gMTAuIDIwMDggdiAxNTozNyArMDEwMDoK PiBIaSwKPiAKPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMt dW5pdmVyc2l0eS5kZT4gd3JvdGU6Cj4gPiBTb21lIHR5cGVzIGFsbG93IG11bHRpcGxlIHJlcHJl c2VudGF0aW9ucyBvZiB0aGUgc2FtZSB2YWx1ZS4gQSBnb29kCj4gPiBleGFtcGxlIGFyZSBJUHY2 IGFkZHJlc3NlcywgZS5nLiA6OjEgYW5kIDA6MDowOjA6MDowOjA6MS4gVGhpcyByYWlzZXMKPiA+ IHNldmVyYWwgcXVlc3Rpb25zOgo+ID4gCj4gPiAxKSBXZSBuZWVkIHRvIGRlZmluZSBob3cgY29t cGFyaXNpb25zIGFyZSBkb25lLiBBdCB0aGUgaW50ZXJpbSwgdGhlcmUKPiA+ICAgIHdhcyBhZ3Jl ZW1lbnQgdGhhdCBjb21wYXJpc29ucyBhcmUgZG9uZSBpbiB0aGUgdmFsdWUgc3BhY2Ugc28gdGhl Cj4gPiAgICBmYWN0IHRoYXQgdGhlcmUgbWlnaHQgYmUgZGlmZmVyZW50IGxleGljYWwgcmVwcmVz ZW50YXRpb25zIGZvciB0aGUKPiA+ICAgIHNhbWUgdmFsdWUgYmVjb21lcyBhIG5vbi1pc3N1ZS4g KFRoaXMgbmVlZHMgdG8gYmUgY29uZmlybWVkIG9uIHRoZQo+ID4gICAgbWFpbGluZyBsaXN0LikK PiAKPiBJIGFncmVlIHdpdGggdGhpcy4KCisxCgo+ICAgICBhJykgaW1wbGVtZW50YXRpb25zIE1V U1QgYWNjZXB0IG5vcm1hbGl6ZWQgdmFsdWVzIGFzIGlucHV0Cj4gICAgIGInKSBpbXBsZW1lbnRh dGlvbnMgU0hPVUxEIGdlbmVyYXRlIG5vcm1hbGl6ZWQgdmFsdWVzIGFzIG91dHB1dAo+ICAgICBj JykgaW1wbGVtZW50YXRpb25zIE1VU1QgYWNjZXB0IG5vbi1ub3JtYWxpemVkIHZhbHVlcyBhcyBp bnB1dAoKKzEKCj4gCj4gSWYgd2UgZG8gYSArIGIgaW4geW91ciBsaXN0LCB0aGVuIEkgZG9uJ3Qg dGhpbmsgd2Ugc2hvdWxkIGJvdGhlciB3aXRoCj4gc3BlY2lmeWluZyBhbnl0aGluZyBidXQgdGhl IG5vcm1hbGl6ZWQgdmFsdWUuCj4gCj4gCj4gPiAgICBJbiBnZW5lcmFsLCBpdCB3YXMgcHJlZmVy cmVkIHRoYXQgaW1wbGVtZW50YXRpb25zIGRvIG5vdCBoYXZlIHRvCj4gPiAgICByZW1lbWJlciB0 aGUgcmVwcmVzZW50YXRpb24gdGhhdCB3YXMgdXNlZCB0byBjb25maWd1cmUgYSB2YWx1ZS4gIEl0 Cj4gPiAgICBzaG91bGQgYmUgc3VmZmljaWVudCB0byBqdXN0IHN0b3JlIHRoZSB2YWx1ZS4gIChU aGlzIG5lZWRzIHRvIGJlCj4gPiAgICBjb25maXJtZWQgb24gdGhlIG1haWxpbmcgbGlzdC4pCj4g Cj4gSSBhZ3JlZSB3aXRoIHRoaXMuCgorMQoKPiAKPiA+IDMpIFRoZXJlIHdhcyBubyBhZ3JlZW1l bnQgaG93IHdlIHdyaXRlIGRvd24gbm9ybWFsaXphdGlvbiBydWxlcyBhcmUgdGhlCj4gPiAgICBp bnRlcmltIG1lZXRpbmcuIFRoZXJlIGFyZSBzZXZlcmFsIG9wdGlvbnM6Cj4gPiAKPiA+ICAgICgx KSB3ZSBzaW1wbHkgYWRkIHRleHQgdG8gZGVzY3JpcHRpb24gc3RhdGVtZW50cwo+ID4gCj4gPiAg ICAoMikgd2UgaW50cm9kdWNlIGEgc2VwYXJhdGUgc3RhdGVtZW50IHdpdGggYSBzZXBhcmF0ZSBk ZXNjcmlwdGlvbgo+ID4gICAgICAgIGNsYXVzZSwgZS5nLgo+ID4gCj4gPiAgICAgICAgbm9ybWFs aXphdGlvbiB7Cj4gPiAgICAgICAgICBkZXNjcmlwdGlvbiAidHVybiBhbGwgY2hhcmFjdGVycyB0 byBsb3dlciBjYXNlIjsKPiA+ICAgICAgICB9Cj4gCj4gT3IgbWF5YmUgJ25vcm1hbGl6YXRpb24g InR1cm4gb24gYWxsIGNoYXJhY3RlcnMgdG8gbG93ZXIgY2FzZSI7Jwo+IAo+IAo+ID4gICAgKDMp IHdlIGludHJvZHVjZSBhIHNlcGFyYXRlIHN0YXRlbWVudCB3aXRoIGEgc2VwYXJhdGUgZGVzY3Jp cHRpb24KPiA+ICAgICAgICBjbGF1c2UgYW5kIGFsbG93IGFuIGFkZGl0aW9uYWwgcGF0dGVybiB0 aGF0IGNhbiBiZSBtb3JlCj4gPiAgICAgICAgcmVzdHJpY3RpdmUgZm9yIG5vcm1hbGl6ZWQgdmFs dWVzLCBlLmcuCj4gPiAKPiA+ICAgICAgICBub3JtYWxpemF0aW9uIHsKPiA+ICAgICAgICAgIHBh dHRlcm4gIlthLXpdIjsKPiA+IAkgZGVzY3JpcHRpb24gIm5vcm1hbGl6ZWQgcmVwcmVzZW50YXRp b24gaXMgaW4gbG93ZXIgY2FzZSI7Cj4gPiAgICAgICAgfQo+IAo+IEkgd291bGRuJ3QgbWluZCAo MyksIGJ1dCBJIGRvbid0IHRoaW5rIGl0IGlzIG5lY2Vzc2FyeS4gIEkgbGlrZSAoMikKPiBiZXR0 ZXIgdGhhbiAoMSkgYmVjYXVzZSBpdCB0ZWxscyBhIG1vZHVsZSBkZXNpZ25lciB0aGF0IFlBTkcK PiByZWNvZ25pemVzIHRoZSBwcm9ibGVtIG9mIG5vcm1hbGl6YXRpb24sIGFuZCBwcm92aWRlcyBh IHNvbHV0aW9uIGZvcgo+IGl0LgoKSSBwcmVmZXIgKDIpLCBhbmQgdGhpbmsgYWJvdXQgKDMpIGZv ciBZQU5HIDIuMC4KCkFjdHVhbGx5LCB0aGVyZSBpcyBhbm90aGVyIG9wdGlvbiB3aGljaCBEVExM IHRyaWVzIHRvIGltcGxlbWVudDogcHJvdmlkZQpleHByZXNzaW9ucyBmb3Igb2J0YWluaW5nIHRo ZSB2YWx1ZS1zcGFjZSB2YWx1ZSBmcm9tIHZhcmlvdXMgbGV4aWNhbApyZXByZXNlbnRhdGlvbnMu IEZvciBleGFtcGxlLCBJUHY0IGFkZHJlc3NlcyB3b3VsZCBiZSBtYXBwZWQgdG8gdWludDMyCmlu IHRoZSB2YWx1ZSBzcGFjZS4KCkxhZGEKCj4gCj4gCj4gL21hcnRpbgo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gbmV0bW9kIG1haWxpbmcgbGlzdAo+ IG5ldG1vZEBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0bW9kCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1h aWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Wed Oct 29 09:32:05 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67E373A6AF7; Wed, 29 Oct 2008 09:32:05 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 688523A6ABE for ; Wed, 29 Oct 2008 09:32:04 -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 aaduELZNcMcN for ; Wed, 29 Oct 2008 09:32:03 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 8B8FF3A6889 for ; Wed, 29 Oct 2008 09:32:03 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 90598D800BD; Wed, 29 Oct 2008 17:32:01 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20081029.160112.210635359.mbj@tail-f.com> References: <20081026095003.GA2622@elstar.local> <20081029.153739.92872679.mbj@tail-f.com> <20081029144851.GA19261@elstar.local> <20081029.160112.210635359.mbj@tail-f.com> Organization: CESNET Date: Wed, 29 Oct 2008 17:32:02 +0100 Message-Id: <1225297922.15270.32.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] types-011: multiple lexical representations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTdCAyOS4gMTAuIDIwMDggdiAxNjowMSArMDEwMDoK PiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0 eS5kZT4gd3JvdGU6Cj4gPiBPbiBXZWQsIE9jdCAyOSwgMjAwOCBhdCAwMzozNzozOVBNICswMTAw LCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOgo+ID4gCj4gPiBbLi4uXQo+ID4gIAo+ID4gPiBJIHdv dWxkbid0IG1pbmQgKDMpLCBidXQgSSBkb24ndCB0aGluayBpdCBpcyBuZWNlc3NhcnkuICBJIGxp a2UgKDIpCj4gPiA+IGJldHRlciB0aGFuICgxKSBiZWNhdXNlIGl0IHRlbGxzIGEgbW9kdWxlIGRl c2lnbmVyIHRoYXQgWUFORwo+ID4gPiByZWNvZ25pemVzIHRoZSBwcm9ibGVtIG9mIG5vcm1hbGl6 YXRpb24sIGFuZCBwcm92aWRlcyBhIHNvbHV0aW9uIGZvcgo+ID4gPiBpdC4KPiA+IAo+ID4gQSBt b2R1bGUgZGVzaWduZXIgZWl0aGVyIHB1dHMgaW4gdGhlIHJpZ2h0IHRleHQgb3Igbm90IGJlY2F1 c2UgaGUKPiA+IGVpdGhlciB1bmRlcnN0YW5kcyB0aGUgaXNzdWUgb3Igbm90Lgo+IAo+IFN1cmUs IGJ1dCB3aXRoIGFuIGV4cGxpY2l0IGtleXdvcmQgdGhlIG1vZHVsZSBkZXNpZ25lciB0aGF0ICpk b2VzKgo+IHRoaW5rIGFib3V0IHRoZSBpc3N1ZSBrbm93cyB0aGF0IHRoZSBjb25jZXB0IGlzIHN1 cHBvcnRlZCBpbiB0aGUKPiBsYW5ndWFnZS4gIEFuZCBtYXliZSB0aGUgZXhwbGljaXQga2V5d29y ZCB3aWxsIGhlbHAgdGhlIGRlc2lnbmVyCj4gdW5kZXJzdGFuZCB0aGUgaXNzdWUgYW5kIHJlbWVt YmVyIHRvIHRoaW5rIGFib3V0IGl0LgoKUmlnaHQsIGFuZCBkZXNjcmlwdGlvbnMgc29tZXRpbWVz IGRlYWwgd2l0aCBvdGhlciB0aGluZ3MgYW5kIG1heSBiZQpxdWl0ZSBsb25nLCBpbiB3aGljaCBj YXNlIGl0IHdvdWxkIGJlIGVhc3kgdG8gbWlzcyB0aGUgcGFydCBhYm91dApub3JtYWxpemF0aW9u LgoKTGFkYQoKPiAKPiAKPiAvbWFydGluCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KPiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4gbmV0bW9kQGlldGYub3Jn Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QKLS0gCkxhZGlz bGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1v ZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo= From netmod-bounces@ietf.org Wed Oct 29 10:01: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 21B733A6A1C; Wed, 29 Oct 2008 10:01: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 202883A6A1C for ; Wed, 29 Oct 2008 10:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5xS7m9UZtG3 for ; Wed, 29 Oct 2008 10:01:35 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 70BF83A635F for ; Wed, 29 Oct 2008 10:01:35 -0700 (PDT) Received: (qmail 82048 invoked from network); 29 Oct 2008 17:01:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 29 Oct 2008 17:01:31 -0000 X-YMail-OSG: iBBc1PIVM1l9myxAGev08SfcahtyKoFmPRRI6DOd5JQnPawoFN8vBT4SRN3MNQHKxvauytnwUd22BRmpaEvnvjLDfuEIGIiCjQN1yRAr42ENey7n6kxN1SSUOL0QpJsKNBSucJMUzWNw1hiZS6QOeXY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <490896E9.2000901@netconfcentral.com> Date: Wed, 29 Oct 2008 10:01:29 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Ladislav Lhotka References: <20081026095003.GA2622@elstar.local> <20081029.153739.92872679.mbj@tail-f.com> <1225297606.15270.27.camel@missotis> In-Reply-To: <1225297606.15270.27.camel@missotis> Cc: netmod@ietf.org Subject: Re: [netmod] types-011: multiple lexical representations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: ..... > >>> 3) There was no agreement how we write down normalization rules are the >>> interim meeting. There are several options: >>> >>> (1) we simply add text to description statements >>> >>> (2) we introduce a separate statement with a separate description >>> clause, e.g. >>> >>> normalization { >>> description "turn all characters to lower case"; >>> } >> Or maybe 'normalization "turn on all characters to lower case";' >> >> >>> (3) we introduce a separate statement with a separate description >>> clause and allow an additional pattern that can be more >>> restrictive for normalized values, e.g. >>> >>> normalization { >>> pattern "[a-z]"; >>> description "normalized representation is in lower case"; >>> } >> I wouldn't mind (3), but I don't think it is necessary. I like (2) >> better than (1) because it tells a module designer that YANG >> recognizes the problem of normalization, and provides a solution for >> it. > > I prefer (2), and think about (3) for YANG 2.0. > I prefer (1). I do not see why normalization implementation issues deserve their own description clause. It isn't more important than what the knob does, or security concerns, or network impact, etc. Multiple description clauses will just lead to lots of CLRs about what text goes where. (3) sounds nice for YANG 3.0. If we try to automate everything now, YANG will collapse under its own weight before taking its first baby steps. > Actually, there is another option which DTLL tries to implement: provide > expressions for obtaining the value-space value from various lexical > representations. For example, IPv4 addresses would be mapped to uint32 > in the value space. > > Lada > >> >> /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 10:19: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 97D9B3A68C1; Wed, 29 Oct 2008 10:19: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 0127A3A6A7F for ; Wed, 29 Oct 2008 10:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWa8UnBIlR+j for ; Wed, 29 Oct 2008 10:19:29 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 1C2C63A68C1 for ; Wed, 29 Oct 2008 10:19:29 -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 NAA16749; Wed, 29 Oct 2008 13:19:05 -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 NAA05240; Wed, 29 Oct 2008 13:19:05 -0400 (EDT) Message-Id: <200810291719.NAA05240@adminfs.snmp.com> To: David Partain From: David Reid In-reply-to: Your message of Tue, 28 Oct 2008 16:12:37 +0100. <200810281612.37126.david.partain@ericsson.com> Date: Wed, 29 Oct 2008 13:19:04 -0400 Cc: netmod@ietf.org Subject: Re: [netmod] Proposed consensus mail on yang-00413: import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > This is a call for consensus about issue > 'yang-00413: import by revision'. See the wiki at > http://wiki.tools.ietf.org/wg/netmod/trac/wiki/Issues_yang#issue-00413 > for an introduction. As long as we come up with a good solution for the cases like IANA ifType, I am not opposed to import by revision. I would prefer import by revision to be optional, with no revision meaning that I want the most current revision. But I know that was not the prevailing opinion at the interim. I would also be happy if we did not do import by revision at all. -David Reid _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 10: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 AB4AD3A6883; Wed, 29 Oct 2008 10: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 9BE843A6883 for ; Wed, 29 Oct 2008 10:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yeu-kDBX8tmi for ; Wed, 29 Oct 2008 10:19:56 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id E1A3C3A68C1 for ; Wed, 29 Oct 2008 10:19:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=QlSEue+gDuq6Nk6znQlOFNtp8GcfKBeBTyc0YQz3Q8WPVt2ZDBXpU7F515oXB4tK; 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.165.6.12] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KvEhi-00066S-SU for netmod@ietf.org; Wed, 29 Oct 2008 13:19:35 -0400 Message-ID: <004601c939ea$863ac9e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20081026095003.GA2622@elstar.local><20081029.153739.92872679.mbj@tail-f.com><20081029144851.GA19261@elstar.local><20081029.160112.210635359.mbj@tail-f.com> <1225297922.15270.32.camel@missotis> Date: Wed, 29 Oct 2008 10:19:38 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e427ad35af0e64c531fdb149ca6340ad2c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.6.12 Subject: Re: [netmod] types-011: multiple lexical representations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 I certainly don't want to derail what appears to be a WG consensus, I think it's important to keep in mind that this direction (comparisons in "the value space", accepting non-normalized input from clients, and more-or- less ad hoc normalization rules associated with new bits of data at the time they are defined) has serious implications if there is ever a need to support delegation / subagent architectures or generic repositories. It requires the parts of a system analogous to a master agent to have the ability to dynamically acquire new rules corresponding to the normalized comparison functions for new subagents, or for the master agent to "farm out" the comparisons to the subagent. While this is reasonable for filter-like applications, for handling instance naming it scales badly. I know this from first-hand experience, as the path being taken by netmod here is the one that was taken by CMIP, and this is one of the things that most CMIP people will admit was a mistake that could have easily been avoided. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 10:32: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 A6B7C3A683F; Wed, 29 Oct 2008 10:32: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 88A883A6B11 for ; Wed, 29 Oct 2008 10:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 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 bv8O+z-nBByv for ; Wed, 29 Oct 2008 10:32:00 -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 B4CE33A683F for ; Wed, 29 Oct 2008 10:32:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=gCY45Q/bkqdV38q46mcG27WeFMi9SA4/DHmWYjsStB/5/1j4RyBb7Ttj7Nb3uPXn; 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.165.6.12] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KvEtN-0007qM-NY for netmod@ietf.org; Wed, 29 Oct 2008 13:31:37 -0400 Message-ID: <007501c939ec$36248d40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20081026095003.GA2622@elstar.local> <20081029.153739.92872679.mbj@tail-f.com><1225297606.15270.27.camel@missotis> <490896E9.2000901@netconfcentral.com> Date: Wed, 29 Oct 2008 10:31: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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e45e1fb259ebabaa546c14a75246c75bd4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.6.12 Subject: Re: [netmod] types-011: multiple lexical representations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: "Ladislav Lhotka" > Cc: > Sent: Wednesday, October 29, 2008 10:01 AM > Subject: Re: [netmod] types-011: multiple lexical representations .... > I do not see why normalization implementation issues > deserve their own description clause. It isn't more > important than what the knob does, or security concerns, > or network impact, etc. Think RFC 3454 as the starting point for human-readable text if one does ad hoc normalization rules. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 12:26: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 872623A67D7; Wed, 29 Oct 2008 12:26: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 BBF863A67AC for ; Wed, 29 Oct 2008 12:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KFJWreCN7RL for ; Wed, 29 Oct 2008 12:26:05 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 431863A691A for ; Wed, 29 Oct 2008 12:26:04 -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 PAA27749 for ; Wed, 29 Oct 2008 15:24:28 -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 PAA06970 for ; Wed, 29 Oct 2008 15:24:20 -0400 (EDT) Message-Id: <200810291924.PAA06970@adminfs.snmp.com> To: netmod@ietf.org From: David Reid In-reply-to: Your message of Tue, 28 Oct 2008 22:27:10 +0100. <20081028.222710.251029462.mbj@tail-f.com> Date: Wed, 29 Oct 2008 15:24:19 -0400 Subject: Re: [netmod] Proposed consensus mail on yang-00000: module update rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I like the text Martin wrote on change rules. In general, I like the idea of listing what is allowed and saying everything else is not allowed since we can't possible list everything that is not allowed. But there are some cases that may be ambiguous if we don't explicitly say it is not allowed. For example: Can I change an int8 to an int16? The consensus at the interim was no, but someone reading the spec may interpret that change as simply expanding the range and thus be a legal change. Are leaf order changes allowed? Again, the consensus at the interim was no, but that may not be clear in the spec. It is clear that you cannot delete a leaf, but it is not clear that you cannot change to ordering. -David Reid > > > * Updating a Module > > As experience is gained with a module, it may be desirable to revise > that module. However, changes are not allowed if they have any > potential to cause interoperability problems between a client using an > original specification and a server using an updated specification. > > For any published change, a new "revision" statement (^revision^) > SHOULD be included in front of the existing revision statements. > Furthermore, any necessary changes MUST be applied to any meta > statements, including the "organization" and "contact" statements > (^organization^, ^contact^). > > Note that definitions contained in a module are available to be > imported by any other module, and are referenced in "import" > statements via the module name. Thus, a module name MUST NOT be > changed. Furthermore, the "namespace" statement MUST NOT be changed, > since all XML elements are encoded in the namespace. > > Obsolete definitions MUST NOT be removed from modules since their > identifiers may still be referenced by other modules. > > A definition may be revised in any of the following ways: > > - An "enumeration" type may have new enums added, provided the old > enums's values do not change. > - A "bits" type may have new bits added, provided the old bits's > positions do not change. > - A "range", "length", or "pattern" statement may expand the allowed > value space. > - A "default" statement may be added. > - A "units" statement may be added. > - A "reference" statement may be added or updated. > - A "must" statement may be removed or its constraint relaxed. > - A "mandatory" statement may be removed or changed from "true" to > "false". > - A "min-elements" statement may be removed, or changed to require less > elements. > - A "max-elements" statement may be removed, or changed to allow more > elements. > - A "description" statement may be added or clarified without changing > the semantics of the definition. > - New typedefs, groupings, rpc, notifications, extensions, features, > and identities may be added. > - New data definition statements may be added if they do not add > mandatory nodes (^mandatory-nodes^) to existing nodes, or if they > are conditionally dependent on a new feature (i.e. have a > "if-feature" statement which refers to a new feature). > - A new "case" statement may be added. > - A node that was non-configuration may be changed to represent > configuration, provided it is not mandatory (^mandatory-nodes^). > - An "if-feature" statement may be removed, provided its node is not > mandatory (^mandatory-nodes^). > - A "status" statement may be added, or changed from "current" to > "deprecated" or "obsolete", or from "deprecated" to "obsolete". > - A "type" statement may be replaced with another "type" statement > which does not change the syntax or semantics of the type. For > example, an inline type definition may be replaced with a typedef. > - Any set of data definition nodes may be replaced with another set of > syntactically and semantically equivalent nodes. For example, a set > of leafs may be replaced by a uses of a grouping with the same > leafs. > - A module may be split into a set of submodules, or submodule may be > removed, provided the definitions in the module do not change in any > other way than allowed here. > - The "prefix" statment may be changed, provided all local uses of the > prefix also are changed. > > Otherwise, if the semantics of any previous definition are changed > (i.e. if a non-editorial change is made to any definition other than > those specifically allowed above), then this MUST be achieved by a new > definition with a new identifier. > > [Editor's Note: These rules work as long as we have import/include by > revision] _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 12: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 C1B913A685A; Wed, 29 Oct 2008 12: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 55B8F3A68F4 for ; Wed, 29 Oct 2008 12:59:23 -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 udrBuvQH-p19 for ; Wed, 29 Oct 2008 12:59:22 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id B84C93A685A for ; Wed, 29 Oct 2008 12:59:21 -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 PAA01209 for ; Wed, 29 Oct 2008 15:58:51 -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 PAA07517 for ; Wed, 29 Oct 2008 15:58:49 -0400 (EDT) Message-Id: <200810291958.PAA07517@adminfs.snmp.com> To: netmod@ietf.org From: David Reid In-reply-to: Your message of Wed, 29 Oct 2008 09:51:42 +0100. <200810290951.42732.david.partain@ericsson.com> Date: Wed, 29 Oct 2008 15:58:48 -0400 Subject: Re: [netmod] Proposed consensus on yang-01281: conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org > 1. Should there be a formal way of describing the deviations of > a particular device? Yes. > > 2. Should this work be done in this working group? Yes. > 3. Should the document say anything about how to organize these > statements in a module? I like David Partain's recommendation to say one SHOULD put the deviations in a separate module. > 4. Are we reasonably happy with the syntax (with caveat that > there is tweaking and clarification to be done)? This is a good starting point. -David Reid _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 13:34: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 835B53A6984; Wed, 29 Oct 2008 13:34: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 3D0E23A6984 for ; Wed, 29 Oct 2008 13:34: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 oPBCCEOWW9q9 for ; Wed, 29 Oct 2008 13:34:19 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 562C83A69D4 for ; Wed, 29 Oct 2008 13:33:59 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Wed, 29 Oct 2008 13:34:18 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, 29 Oct 2008 13:28: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, 29 Oct 2008 13:28:11 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Oct 2008 13:28: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 m9TKSAM50157; Wed, 29 Oct 2008 13:28:10 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m9TKNU6n063057; Wed, 29 Oct 2008 20:23:31 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200810292023.m9TKNU6n063057@idle.juniper.net> To: "Randy Presuhn" In-reply-to: <004601c939ea$863ac9e0$6801a8c0@oemcomputer> Date: Wed, 29 Oct 2008 16:23:30 -0400 From: Phil Shafer X-OriginalArrivalTime: 29 Oct 2008 20:28:10.0858 (UTC) FILETIME=[DC63D4A0:01C93A04] Cc: netmod@ietf.org Subject: Re: [netmod] types-011: multiple lexical representations X-BeenThere: netmod@ietf.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: >It requires the parts >of a system analogous to a master agent to have the ability >to dynamically acquire new rules corresponding to the normalized >comparison functions for new subagents, or for the master >agent to "farm out" the comparisons to the subagent. Yes, this is definitely a weakness, but I see the issue as lesser for agents and greater for managers. If an applications loads "mine.yang" and it defines a new type, the app won't automatically know how to canonicalize values. So if I make a "junos:ipprefix-or-interface" type, it won't know that "10/8" gets canonicalized to "10.0.0.0/8". This isn't good, but having a canonical form beats treating "10/8" and "10.0.0.0/8" as distinct prefixes. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 13: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 C7AB53A69D2; Wed, 29 Oct 2008 13: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 62D613A6B1E for ; Wed, 29 Oct 2008 13:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.163 X-Spam-Level: X-Spam-Status: No, score=-1.163 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwO0JAyM7EHY for ; Wed, 29 Oct 2008 13:41: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 150B43A69D4 for ; Wed, 29 Oct 2008 13:41:35 -0700 (PDT) Received: (qmail 18660 invoked from network); 29 Oct 2008 20:41:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 29 Oct 2008 20:41:33 -0000 X-YMail-OSG: QrWwE_YVM1lMfXXKufdzgWoq3nusCNXUO2_Ld8A3ttJbn6Y791Hjy4C5weCPFDn_kGT0i.472u6VwdLa9XCkxcsUKOl5dPpKHnAwL_ze7AZztd.G6rUC3rlxbqHXJDbRv9w- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4908CA7C.9050204@netconfcentral.com> Date: Wed, 29 Oct 2008 13:41:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETMOD Working Group Subject: [netmod] ordered-by statement Qs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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, yang-01, sec. 7.7.6: What error should be generated if an 'insert' or 'key'/'value' attributes are present in an element other than a list or leaf-list? Or an ordered-by system list or leaf-list? What error should be generated if an 'insert' or 'key'/'value' attributes are present in a 'delete' operation? What error should be generated if 'insert' equals 'first' or 'last', and the 'value' attribute is present? sec. 7.8.7: In the "move barney before fred" example on p65, the operation attribute is 'merge'. Shouldn't it be 'replace'? The example looks like it would result in a duplicate 'barney' entry which would cause an error. If merge and replace are supposed to do the same thing here (move), then make that clear in the draft. Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 14:25: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 E98C728C3F6; Wed, 29 Oct 2008 14: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 DBD8928C3F6 for ; Wed, 29 Oct 2008 14:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.581 X-Spam-Level: X-Spam-Status: No, score=-1.581 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4D7iTIzBE8oY for ; Wed, 29 Oct 2008 14:25: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 0C9B328C401 for ; Wed, 29 Oct 2008 14:25:02 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 0CA1776C4F7; Wed, 29 Oct 2008 22:24:53 +0100 (CET) Date: Wed, 29 Oct 2008 22:24:52 +0100 (CET) Message-Id: <20081029.222452.83521868.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <200810291924.PAA06970@adminfs.snmp.com> References: <20081028.222710.251029462.mbj@tail-f.com> <200810291924.PAA06970@adminfs.snmp.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netmod@ietf.org Subject: Re: [netmod] Proposed consensus mail on yang-00000: module update rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Reid wrote: > Can I change an int8 to an int16? The consensus at the interim was no, but > someone reading the spec may interpret that change as simply expanding the > range and thus be a legal change. I'm guessing that it is this text that is not clear: OLD: A "type" statement may be replaced with another "type" statement which does not change the syntax or semantics of the type. For example, an inline type definition may be replaced with a typedef. Is this text sufficient: NEW: A "type" statement may be replaced with another "type" statement which does not change the syntax or semantics of the type. For example, an inline type definition may be replaced with a typedef, but a int8 type cannot be replaced by a int16, since the syntax would change. > Are leaf order changes allowed? Again, the consensus at the interim was no, > but that may not be clear in the spec. It is clear that you cannot delete a > leaf, but it is not clear that you cannot change to ordering. Is this text ok: In statements which have any data definition statements as substatements, those data definition substatements MUST NOT be reordered. Should I add an example? For example, the order among all leafs defined in a list must be maintained. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 14:29: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 999FE3A6AB8; Wed, 29 Oct 2008 14:29: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 172F328C350 for ; Wed, 29 Oct 2008 14:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4HsSNUnP6KP for ; Wed, 29 Oct 2008 14:29:29 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 370E63A6AB8 for ; Wed, 29 Oct 2008 14:29:29 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 0433376C4F7; Wed, 29 Oct 2008 22:29:22 +0100 (CET) Date: Wed, 29 Oct 2008 22:29:19 +0100 (CET) Message-Id: <20081029.222919.172640909.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200810292023.m9TKNU6n063057@idle.juniper.net> References: <004601c939ea$863ac9e0$6801a8c0@oemcomputer> <200810292023.m9TKNU6n063057@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] types-011: multiple lexical representations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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: > "Randy Presuhn" writes: > >It requires the parts > >of a system analogous to a master agent to have the ability > >to dynamically acquire new rules corresponding to the normalized > >comparison functions for new subagents, or for the master > >agent to "farm out" the comparisons to the subagent. > > Yes, this is definitely a weakness, but I see the issue as lesser > for agents and greater for managers. If an applications loads > "mine.yang" and it defines a new type, the app won't automatically > know how to canonicalize values. So if I make a > "junos:ipprefix-or-interface" type, it won't know that "10/8" gets > canonicalized to "10.0.0.0/8". This isn't good, but having a > canonical form beats treating "10/8" and "10.0.0.0/8" as distinct > prefixes. I think that if we take Randy's comment seriously, there are only two alternatives: don't allow multiple representations of the same value, or have a formal syntax to specify how the canonical form is derived from the multiple representations (i.e. do something like DTLL). IMO the latter is not feasible, so that leaves us with having a one-to-one mapping between the lexical space and the value space. Did I get this right Randy? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 14:55:20 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B47B3A6A96; Wed, 29 Oct 2008 14:55:20 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2524C3A6AFC for ; Wed, 29 Oct 2008 14:55: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 d2aj3fTM2JVN for ; Wed, 29 Oct 2008 14:55:08 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 837A43A6A96 for ; Wed, 29 Oct 2008 14:55:06 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Wed, 29 Oct 2008 14:55:07 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, 29 Oct 2008 14:54:53 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Oct 2008 14:54:53 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 14:54: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 m9TLsqM10497; Wed, 29 Oct 2008 14:54:52 -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 m9TLoC23063580; Wed, 29 Oct 2008 21:50:13 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200810292150.m9TLoC23063580@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20081029.222452.83521868.mbj@tail-f.com> Date: Wed, 29 Oct 2008 17:50:12 -0400 From: Phil Shafer X-OriginalArrivalTime: 29 Oct 2008 21:54:53.0327 (UTC) FILETIME=[F94D99F0:01C93A10] Cc: netmod@ietf.org Subject: Re: [netmod] Proposed consensus mail on yang-00000: module update rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: > A "type" statement may be replaced with another "type" statement > which does not change the syntax or semantics of the type. For > example, an inline type definition may be replaced with a typedef, > but a int8 type cannot be replaced by a int16, since the syntax > would change. If you think of text (XML) representation, the difference between int8 and int16 is a matter of range. If we want to make the "type size guarantee" that we talked about at the interim, perhaps the best way to say this (without talking about implementation-specific issues like "sizeof" is to just say you can't change the base type which underlies the chain of derived types (the ultimate base type). This makes the rule concrete without talking about "syntax", "size", or anything similar. The "digress" should have a good explanation of why we do/need this. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 14:55: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 1E9193A6767; Wed, 29 Oct 2008 14:55: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 39E083A69D4 for ; Wed, 29 Oct 2008 14:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJdfF3fFakTA for ; Wed, 29 Oct 2008 14:55:49 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D70623A6B0F for ; Wed, 29 Oct 2008 14:55:40 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9712376C4F7; Wed, 29 Oct 2008 22:55:39 +0100 (CET) Date: Wed, 29 Oct 2008 22:55:36 +0100 (CET) Message-Id: <20081029.225536.17933246.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4908CA7C.9050204@netconfcentral.com> References: <4908CA7C.9050204@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] ordered-by statement Qs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, > > yang-01, sec. 7.7.6: > > What error should be generated if an 'insert' or 'key'/'value' > attributes are present in an element other than a list > or leaf-list? Or an ordered-by system list or leaf-list? I'm doing std 'unknown-attribute'. > What error should be generated if an 'insert' or 'key'/'value' > attributes are present in a 'delete' operation? [checking the code...] I don't catch this error today, but I believe it should also be 'unknown-attribute'. > What error should be generated if 'insert' equals 'first' > or 'last', and the 'value' attribute is present? Also 'unknown-attribute'. Do you agree, and do you think it should be explicitly stated in the text? > sec. 7.8.7: > > In the "move barney before fred" example on p65, > the operation attribute is 'merge'. Shouldn't > it be 'replace'? The example looks like it > would result in a duplicate 'barney' entry > which would cause an error. If merge and replace > are supposed to do the same thing here (move), > then make that clear in the draft. 'replace' in this example would move the user barney, but the barney user would be empty; no and no . You would ask the server to replace the existing user barney with the new one you provide, at the new location. The current text says: the attributes "insert" and "key" [...] can be used during "create" operations to insert a new list entry, or during "merge" or "replace" operations to insert a new list entry or move an existing one. Would this be better: the attributes "insert" and "key" [...] can be used during "create" operations to insert a new list entry, or during "replace" operations to insert a new list entry or move and replace an existing one, or during "merge" operations to insert a new list entry or move an existing one. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 15:00: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 0845528C3EB; Wed, 29 Oct 2008 15:00: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 BF1E428C3F3 for ; Wed, 29 Oct 2008 15:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.209, 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 PSUFN+cl-VgO for ; Wed, 29 Oct 2008 15:00:16 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id F0B2528C3EB for ; Wed, 29 Oct 2008 15:00:15 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id B34E976C4F7; Wed, 29 Oct 2008 23:00:14 +0100 (CET) Date: Wed, 29 Oct 2008 23:00:12 +0100 (CET) Message-Id: <20081029.230012.198011659.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200810292150.m9TLoC23063580@idle.juniper.net> References: <20081029.222452.83521868.mbj@tail-f.com> <200810292150.m9TLoC23063580@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] Proposed consensus mail on yang-00000: module update rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Phil Shafer wrote: > If we want to make the "type > size guarantee" that we talked about at the interim, perhaps the > best way to say this (without talking about implementation-specific > issues like "sizeof" is to just say you can't change the base type > which underlies the chain of derived types (the ultimate base type). Yes, I was thinking of using the term "base type", but as the term is defined, it can't really be used. So we might say "the base type which underlies the chain of derived types", but if we do this we really have to explain what this means, probably in a separate subsection. For example, how are unions treated? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 15:08: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 72D8728C3FE; Wed, 29 Oct 2008 15:08: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 71FDF28C401 for ; Wed, 29 Oct 2008 15:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.312, 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 TrqlAhyX0L-e for ; Wed, 29 Oct 2008 15:08:35 -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 C81E828C3F7 for ; Wed, 29 Oct 2008 15:08:35 -0700 (PDT) Received: (qmail 33094 invoked from network); 29 Oct 2008 22:08:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 29 Oct 2008 22:08:33 -0000 X-YMail-OSG: uz3XWPEVM1kfLZt5ZfpYS_IS5Ztsw0HaxF2IsefQy4.IjqSJPsIx8zQKD_TPghpvVCZKwV54T1pQOfz1JOifGqTCwSzg6a31AxsF1AVQBjRQ5fWZfQcw9HAS6RYSCwSdgpSgaRoD6W4XmNa8yO_ozsiyYHxLyAH8FxozUHboCpWio9eg5DFRMX5cqL2lLVcDDfqRtia9mgmSm8Ft5VR4y6SN X-Yahoo-Newman-Property: ymail-5 Message-ID: <4908DEDF.1040807@netconfcentral.com> Date: Wed, 29 Oct 2008 15:08:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <004601c939ea$863ac9e0$6801a8c0@oemcomputer> <200810292023.m9TKNU6n063057@idle.juniper.net> <20081029.222919.172640909.mbj@tail-f.com> In-Reply-To: <20081029.222919.172640909.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] types-011: multiple lexical representations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Phil Shafer wrote: >> "Randy Presuhn" writes: >>> It requires the parts >>> of a system analogous to a master agent to have the ability >>> to dynamically acquire new rules corresponding to the normalized >>> comparison functions for new subagents, or for the master >>> agent to "farm out" the comparisons to the subagent. >> Yes, this is definitely a weakness, but I see the issue as lesser >> for agents and greater for managers. If an applications loads >> "mine.yang" and it defines a new type, the app won't automatically >> know how to canonicalize values. So if I make a >> "junos:ipprefix-or-interface" type, it won't know that "10/8" gets >> canonicalized to "10.0.0.0/8". This isn't good, but having a >> canonical form beats treating "10/8" and "10.0.0.0/8" as distinct >> prefixes. > > I think that if we take Randy's comment seriously, there are only two > alternatives: don't allow multiple representations of the same value, > or have a formal syntax to specify how the canonical form is derived > from the multiple representations (i.e. do something like DTLL). IMO > the latter is not feasible, so that leaves us with having a one-to-one > mapping between the lexical space and the value space. > What happened to the Postel Principle? A NETCONF agent should not break because it get +4 instead or 4, or leading whitespace, etc. An SNMP agent accepts more than one ASN.1/BER encoding, accepts varbinds in any order, etc. to make it easier on applications. Let's not do something intended to help applications which actually makes things worse. > Did I get this right Randy? > > > /martin > ___ Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 15: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 0C3243A68D6; Wed, 29 Oct 2008 15: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 5D9A23A689D for ; Wed, 29 Oct 2008 15:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lc6D4XW8zol5 for ; Wed, 29 Oct 2008 15:28:07 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id A22413A68D6 for ; Wed, 29 Oct 2008 15:28:07 -0700 (PDT) Received: (qmail 24809 invoked from network); 29 Oct 2008 22:28:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 29 Oct 2008 22:28:05 -0000 X-YMail-OSG: CS6gx.YVM1nesV5BdjMtNEmD_9q6DneBtBMsYiCIOLr3mkvasSYkK8XIo3efRKOIJU8gM6.8X.3D5jYAGHQ8a22.qXtFcMcvku87g3DMKEXRAcFGN_WSJsXFBjwnqE7MG6O.NCYvNftUBhNZi4tsgDR6 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4908E373.4050604@netconfcentral.com> Date: Wed, 29 Oct 2008 15:28:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <4908CA7C.9050204@netconfcentral.com> <20081029.225536.17933246.mbj@tail-f.com> In-Reply-To: <20081029.225536.17933246.mbj@tail-f.com> Cc: netmod@ietf.org Subject: Re: [netmod] ordered-by statement Qs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> yang-01, sec. 7.7.6: >> >> What error should be generated if an 'insert' or 'key'/'value' >> attributes are present in an element other than a list >> or leaf-list? Or an ordered-by system list or leaf-list? > > I'm doing std 'unknown-attribute'. > >> What error should be generated if an 'insert' or 'key'/'value' >> attributes are present in a 'delete' operation? > > [checking the code...] I don't catch this error today, but I believe > it should also be 'unknown-attribute'. > >> What error should be generated if 'insert' equals 'first' >> or 'last', and the 'value' attribute is present? > > Also 'unknown-attribute'. > > Do you agree, and do you think it should be explicitly stated in the > text? > OK, same here; We don't want to give the impression of listing every error in the text, so it is probably not worth mentioning >> sec. 7.8.7: >> >> In the "move barney before fred" example on p65, >> the operation attribute is 'merge'. Shouldn't >> it be 'replace'? The example looks like it >> would result in a duplicate 'barney' entry >> which would cause an error. If merge and replace >> are supposed to do the same thing here (move), >> then make that clear in the draft. > > 'replace' in this example would move the user barney, but the barney > user would be empty; no and no . You would ask the > server to replace the existing user barney with the new one you > provide, at the new location. > > The current text says: > > the attributes "insert" and "key" [...] can be used during > "create" operations to insert a new list entry, or during "merge" > or "replace" operations to insert a new list entry or move an > existing one. > > Would this be better: > > the attributes "insert" and "key" [...] can be used during > "create" operations to insert a new list entry, or during "replace" > operations to insert a new list entry or move and replace an > existing one, or during "merge" operations to insert a new list > entry or move an existing one. > OK -- merge and replace are not the same -- they work just as specified in 4741: 1) find the matching entry; if it exists then merge or replace the PDU version into this entry 2) move the resulting entry, as requested with the insert attribute > > /martin > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 18:01: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 519363A67A8; Wed, 29 Oct 2008 18:01: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 B976B3A6935 for ; Wed, 29 Oct 2008 18:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eae+gIZsmqjZ for ; Wed, 29 Oct 2008 18:01:46 -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 B313C3A67A8 for ; Wed, 29 Oct 2008 18:01:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=PLUUVY9KsNI+osVwy4TxMD3Uac3IUCIfA0WwXtF8e+T8gjq6dh+Fw+tGOS7XojTL; 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.211] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KvLux-0003Wk-Bv for netmod@ietf.org; Wed, 29 Oct 2008 21:01:43 -0400 Message-ID: <001501c93a2b$1615c520$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <004601c939ea$863ac9e0$6801a8c0@oemcomputer><200810292023.m9TKNU6n063057@idle.juniper.net> <20081029.222919.172640909.mbj@tail-f.com> Date: Wed, 29 Oct 2008 18:01:46 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e4c05a29482f7024f0a50c1f497a647a1e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.204.211 Subject: Re: [netmod] types-011: multiple lexical representations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Martin Bjorklund" > To: > Cc: ; > Sent: Wednesday, October 29, 2008 2:29 PM > Subject: Re: [netmod] types-011: multiple lexical representations > > Phil Shafer wrote: > > "Randy Presuhn" writes: > > >It requires the parts > > >of a system analogous to a master agent to have the ability > > >to dynamically acquire new rules corresponding to the normalized > > >comparison functions for new subagents, or for the master > > >agent to "farm out" the comparisons to the subagent. > > > > Yes, this is definitely a weakness, but I see the issue as lesser > > for agents and greater for managers. If an applications loads > > "mine.yang" and it defines a new type, the app won't automatically > > know how to canonicalize values. So if I make a > > "junos:ipprefix-or-interface" type, it won't know that "10/8" gets > > canonicalized to "10.0.0.0/8". This isn't good, but having a > > canonical form beats treating "10/8" and "10.0.0.0/8" as distinct > > prefixes. > > I think that if we take Randy's comment seriously, there are only two > alternatives: don't allow multiple representations of the same value, > or have a formal syntax to specify how the canonical form is derived > from the multiple representations (i.e. do something like DTLL). IMO > the latter is not feasible, so that leaves us with having a one-to-one > mapping between the lexical space and the value space. > > Did I get this right Randy? Close enough. :-) The distinction between scoping and filtering in the CMIP world permits less draconian solutions there. The cases where only matching for equality would be needed can be handled by canonicalization alone. More elaborate matching rules (e.g., ordering, or substring (substring of IPv6 address, anyone?)) get much more complicated. I don't know what the right answer wil be here, just that it's something that requires very careful thought if you think there will be a need to support multiple, independently-developed software components that implement the various models supported in a system. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 18:07: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 7EFDA3A6D69; Wed, 29 Oct 2008 18:07: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 399013A67A8 for ; Wed, 29 Oct 2008 18:07:34 -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 kuajCvy4VhNr for ; Wed, 29 Oct 2008 18:07:33 -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 42C183A6D6F for ; Wed, 29 Oct 2008 18:07:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=hm+hrn9dnww2I+EQ6dGRwwxhwSnJGdcRvfWNFkx5ynpdhcEBeoMSVDIXDKB9ZehM; 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.211] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KvM0a-0001ry-2f for netmod@ietf.org; Wed, 29 Oct 2008 21:07:32 -0400 Message-ID: <002401c93a2b$e7153020$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <004601c939ea$863ac9e0$6801a8c0@oemcomputer> <200810292023.m9TKNU6n063057@idle.juniper.net><20081029.222919.172640909.mbj@tail-f.com> <4908DEDF.1040807@netconfcentral.com> Date: Wed, 29 Oct 2008 18:07:38 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e49456b3a92fb1c9d56fe6ca76414e0902350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.204.211 Subject: Re: [netmod] types-011: multiple lexical representations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Andy Bierman" > To: "Martin Bjorklund" > Cc: > Sent: Wednesday, October 29, 2008 3:08 PM > Subject: Re: [netmod] types-011: multiple lexical representations ... > What happened to the Postel Principle? > A NETCONF agent should not break because it get +4 instead or 4, > or leading whitespace, etc. An SNMP agent accepts more > than one ASN.1/BER encoding, accepts varbinds in any order, etc. > to make it easier on applications. Let's not do something > intended to help applications which actually makes things worse. ... If we're bringing in SNMP, let's use the correct analogy. The rules for the encoding of INDEX values into an Object Identifier are a clear example of the kind of canonicalization I'm concerned about. There is exactly one correct encoding here, with well-defined (albeit funky) rules for ordering and comparison for equality. This is one of the things SNMP got right. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 19:21: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 A77453A6824; Wed, 29 Oct 2008 19:21: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 579563A6D7F for ; Wed, 29 Oct 2008 19:21: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 O4MsyEFDFkHo for ; Wed, 29 Oct 2008 19:21:33 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 564493A6824 for ; Wed, 29 Oct 2008 19:21:31 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Wed, 29 Oct 2008 19:21:32 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Oct 2008 19:19:58 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Oct 2008 19:19:58 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 19:19: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 m9U2JuM32032; Wed, 29 Oct 2008 19:19:56 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m9U2FBNk065233; Thu, 30 Oct 2008 02:15:12 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200810300215.m9U2FBNk065233@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20081029.230012.198011659.mbj@tail-f.com> Date: Wed, 29 Oct 2008 22:15:11 -0400 From: Phil Shafer X-OriginalArrivalTime: 30 Oct 2008 02:19:57.0373 (UTC) FILETIME=[00DA6ED0:01C93A36] Cc: netmod@ietf.org Subject: Re: [netmod] Proposed consensus mail on yang-00000: module update rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: >For example, how are unions treated? The root base type of a union is "union", so you should be able to do anything without triggering venom from size conscious programmers. Of course, this means that anyone who cares about extensibility will use unions of a single type, which defeats the whole purpose of this type lockdown (which is quite fine with me). IMHO you need to be able to handle strings, since that's XML's root base type. Any optimizations on top of that are merely optimizations, and code should be able to revert to strings where needed (on the client side). Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Wed Oct 29 23:37: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 585DB3A687A; Wed, 29 Oct 2008 23:37: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 96FE03A687A for ; Wed, 29 Oct 2008 23:37:32 -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 fqkVYTlg6OUI for ; Wed, 29 Oct 2008 23:37:32 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id CA0793A6781 for ; Wed, 29 Oct 2008 23:37: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 0EF45D800BD for ; Thu, 30 Oct 2008 07:37:08 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20081029.222919.172640909.mbj@tail-f.com> References: <004601c939ea$863ac9e0$6801a8c0@oemcomputer> <200810292023.m9TKNU6n063057@idle.juniper.net> <20081029.222919.172640909.mbj@tail-f.com> Organization: CESNET Date: Thu, 30 Oct 2008 07:37:07 +0100 Message-Id: <1225348627.24841.12.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [netmod] types-011: multiple lexical representations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBTdCAyOS4gMTAuIDIwMDggdiAyMjoyOSArMDEwMDoK Cj4gSSB0aGluayB0aGF0IGlmIHdlIHRha2UgUmFuZHkncyBjb21tZW50IHNlcmlvdXNseSwgdGhl cmUgYXJlIG9ubHkgdHdvCj4gYWx0ZXJuYXRpdmVzOiAgZG9uJ3QgYWxsb3cgbXVsdGlwbGUgcmVw cmVzZW50YXRpb25zIG9mIHRoZSBzYW1lIHZhbHVlLAo+IG9yIGhhdmUgYSBmb3JtYWwgc3ludGF4 IHRvIHNwZWNpZnkgaG93IHRoZSBjYW5vbmljYWwgZm9ybSBpcyBkZXJpdmVkCj4gZnJvbSB0aGUg bXVsdGlwbGUgcmVwcmVzZW50YXRpb25zIChpLmUuIGRvIHNvbWV0aGluZyBsaWtlIERUTEwpLiAg SU1PCj4gdGhlIGxhdHRlciBpcyBub3QgZmVhc2libGUsIHNvIHRoYXQgbGVhdmVzIHVzIHdpdGgg aGF2aW5nIGEgb25lLXRvLW9uZQo+IG1hcHBpbmcgYmV0d2VlbiB0aGUgbGV4aWNhbCBzcGFjZSBh bmQgdGhlIHZhbHVlIHNwYWNlLgo+IApUaGUgZm9ybWVyIG9wdGlvbiBpcyBJTU8gbm90IHJlYWxp c3RpYy4gTXVsdGlwbGUgbGV4aWNhbCByZXByZXNlbnRhdGlvbnMKYXJlIGFsbG93ZWQgZm9yIG51 bWVyaWMgdHlwZXMsIHNvIHdoeSBzaG91ZG4ndCB0aGV5IGJlIGZvciBvdGhlciB0eXBlcz8KTXkg dW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSBtYXBwaW5nIGZyb20gbGV4aWNhbCB0byB2YWx1ZSBz cGFjZSBoYXMgdG8KYmUgImhhcmR3aXJlZCIgaW4gdGhlIGFnZW50IG9yIG1hbmFnZXIgY29kZSBh bnl3YXkgc28gdGhhdCBpdHMgdmVyYmFsCnNwZWNpZmljYXRpb24gaW4gZGVzY3JpcHRpb24gb3Ig d2hhdGV2ZXIgc3RyaW5ncyBzaG91bGQgaW4gcHJpbmNpcGxlCnN1ZmZpY2UuIExvYWRpbmcgbmV3 IHR5cGVzIGR5bmFtaWNhbGx5IGFuZCBiZWluZyBhYmxlIHRvIGhhbmRsZSB0aGVtCmNvcnJlY3Rs eSBpcyBhbm90aGVyIGxlYWd1ZS4KCkxhZGEKCi0tIApMYWRpc2xhdiBMaG90a2EsIENFU05FVApQ R1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Thu Oct 30 02:16: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 642393A67D0; Thu, 30 Oct 2008 02:16: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 0F5993A68F2 for ; Thu, 30 Oct 2008 02:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=-0.311, 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 loa5Op9Ls429 for ; Thu, 30 Oct 2008 02:16:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 12D7A3A680C for ; Thu, 30 Oct 2008 02:15:42 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 40EB8C002D; Thu, 30 Oct 2008 10:15:38 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yfV0aYLHf-Jy; Thu, 30 Oct 2008 10:15:33 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C3139C0004; Thu, 30 Oct 2008 10:15:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D604083D0FE; Thu, 30 Oct 2008 10:15:31 +0100 (CET) Date: Thu, 30 Oct 2008 10:15:31 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20081030091531.GC19487@elstar.local> Mail-Followup-To: Phil Shafer , Martin Bjorklund , netmod@ietf.org References: <20081029.222452.83521868.mbj@tail-f.com> <200810292150.m9TLoC23063580@idle.juniper.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200810292150.m9TLoC23063580@idle.juniper.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] Proposed consensus mail on yang-00000: module update rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, Oct 29, 2008 at 05:50:12PM -0400, Phil Shafer wrote: > Martin Bjorklund writes: > > A "type" statement may be replaced with another "type" statement > > which does not change the syntax or semantics of the type. For > > example, an inline type definition may be replaced with a typedef, > > but a int8 type cannot be replaced by a int16, since the syntax > > would change. > > If you think of text (XML) representation, the difference between > int8 and int16 is a matter of range. If we want to make the "type > size guarantee" that we talked about at the interim, perhaps the > best way to say this (without talking about implementation-specific > issues like "sizeof" is to just say you can't change the base type > which underlies the chain of derived types (the ultimate base type). > This makes the rule concrete without talking about "syntax", "size", > or anything similar. The "digress" should have a good explanation > of why we do/need this. I agree with this approach, at least for simple types. For unions and such things we might need additional text. /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 Oct 30 03:14:14 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8F2F28C137; Thu, 30 Oct 2008 03:14:14 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CADB228C170 for ; Thu, 30 Oct 2008 03:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.486 X-Spam-Level: X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_45=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 f2SyJTTQipxL for ; Thu, 30 Oct 2008 03:14:12 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 11DAC28C273 for ; Thu, 30 Oct 2008 03:14:12 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 09F0E76C502; Thu, 30 Oct 2008 11:14:10 +0100 (CET) Date: Thu, 30 Oct 2008 11:14:09 +0100 (CET) Message-Id: <20081030.111409.230716977.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49033F03.40402@netconfcentral.com> References: <49033F03.40402@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] canonical data type representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > I think the YANG draft should add a short section > after each 'Lexicographic Representation' section, > defining the canonical format for value-space comparison. Ok. I will add such subsections. > There is (hopefully) a single authoritative reference > that can be used for each 'borrowed' data type, > like string, float32, binary (base64), int32, etc. For the float types, I guess there is a canonical format defined (somewhere). Does anybody know? Should we copy&paste from the XSD spec? > An enum can be any string (with no leading or trailing WSP). > Enum comparisons must use the same normalization rules as > the 'string' data type. I suggest we do not do any Unicode normalization of strings. Another problem is the types where the XML prefix is part of the encoding (i.e. "instance-identifier" and "identityref"). Should we do as XSD does for the QName type, i.e. don't define a canonical representation? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Oct 30 04:52: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 19C613A6891; Thu, 30 Oct 2008 04:52: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 458BF3A6982 for ; Thu, 30 Oct 2008 04:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_45=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 3ADWgbXa90xQ for ; Thu, 30 Oct 2008 04:52:44 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7D08A3A6891 for ; Thu, 30 Oct 2008 04:52:44 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id D15A3D800C8; Thu, 30 Oct 2008 12:52:38 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20081030.111409.230716977.mbj@tail-f.com> References: <49033F03.40402@netconfcentral.com> <20081030.111409.230716977.mbj@tail-f.com> Organization: CESNET Date: Thu, 30 Oct 2008 12:52:39 +0100 Message-Id: <1225367559.24841.20.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] canonical data type representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiDEjHQgMzAuIDEwLiAyMDA4IHYgMTE6MTQgKzAxMDA6 Cgo+IEZvciB0aGUgZmxvYXQgdHlwZXMsIEkgZ3Vlc3MgdGhlcmUgaXMgYSBjYW5vbmljYWwgZm9y bWF0IGRlZmluZWQKPiAoc29tZXdoZXJlKS4gIERvZXMgYW55Ym9keSBrbm93PyAgIFNob3VsZCB3 ZSBjb3B5JnBhc3RlIGZyb20gdGhlIFhTRAoKSUVFRSA3NTQKCj4gc3BlYz8KCllBTkcgY291bGQg dXNlIFhTRCBkYXRhdHlwZXMgZm9yIGFsbCBidWlsdC1pbiB0eXBlcyBhbmQgcmVmZXIgdG8gdGhl IFczQwpzcGVjLiBRTmFtZSBpcyB0aGVyZSwgdG9vLgoKTGFkYQoKPiAKPiA+IEFuIGVudW0gY2Fu IGJlIGFueSBzdHJpbmcgKHdpdGggbm8gbGVhZGluZyBvciB0cmFpbGluZyBXU1ApLgo+ID4gRW51 bSBjb21wYXJpc29ucyBtdXN0IHVzZSB0aGUgc2FtZSBub3JtYWxpemF0aW9uIHJ1bGVzIGFzCj4g PiB0aGUgJ3N0cmluZycgZGF0YSB0eXBlLgo+IAo+IEkgc3VnZ2VzdCB3ZSBkbyBub3QgZG8gYW55 IFVuaWNvZGUgbm9ybWFsaXphdGlvbiBvZiBzdHJpbmdzLgo+IAo+IEFub3RoZXIgcHJvYmxlbSBp cyB0aGUgdHlwZXMgd2hlcmUgdGhlIFhNTCBwcmVmaXggaXMgcGFydCBvZiB0aGUKPiBlbmNvZGlu ZyAoaS5lLiAiaW5zdGFuY2UtaWRlbnRpZmllciIgYW5kICJpZGVudGl0eXJlZiIpLiAgU2hvdWxk IHdlIGRvCj4gYXMgWFNEIGRvZXMgZm9yIHRoZSBRTmFtZSB0eXBlLCBpLmUuIGRvbid0IGRlZmlu ZSBhIGNhbm9uaWNhbAo+IHJlcHJlc2VudGF0aW9uPwo+IAo+IAo+IAo+IC9tYXJ0aW4KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IG5ldG1vZCBtYWls aW5nIGxpc3QKPiBuZXRtb2RAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZAotLSAKTGFkaXNsYXYgTGhvdGthLCBDRVNORVQKUEdQIEtleSBJRDog RTc0RThDMEMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From netmod-bounces@ietf.org Thu Oct 30 04:57: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 399AC3A67AB; Thu, 30 Oct 2008 04:57: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 4CAC13A67AB for ; Thu, 30 Oct 2008 04:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=-0.272, 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 gV70uRya0rzY for ; Thu, 30 Oct 2008 04:57: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 1014C3A6405 for ; Thu, 30 Oct 2008 04:57:25 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7135FC000F; Thu, 30 Oct 2008 12:57:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6xtnMRVBu-1a; Thu, 30 Oct 2008 12:57:08 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7ABA6C000A; Thu, 30 Oct 2008 12:57:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8E00E83D597; Thu, 30 Oct 2008 12:57:07 +0100 (CET) Date: Thu, 30 Oct 2008 12:57:07 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20081030115707.GA19756@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , netmod@ietf.org References: <004601c939ea$863ac9e0$6801a8c0@oemcomputer> <200810292023.m9TKNU6n063057@idle.juniper.net> <20081029.222919.172640909.mbj@tail-f.com> <4908DEDF.1040807@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4908DEDF.1040807@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netmod@ietf.org Subject: Re: [netmod] types-011: multiple lexical representations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org On Wed, Oct 29, 2008 at 03:08:31PM -0700, Andy Bierman wrote: > Martin Bjorklund wrote: >> >> I think that if we take Randy's comment seriously, there are only two >> alternatives: don't allow multiple representations of the same value, >> or have a formal syntax to specify how the canonical form is derived >> from the multiple representations (i.e. do something like DTLL). IMO >> the latter is not feasible, so that leaves us with having a one-to-one >> mapping between the lexical space and the value space. >> > > What happened to the Postel Principle? > A NETCONF agent should not break because it get +4 instead or 4, > or leading whitespace, etc. An SNMP agent accepts more > than one ASN.1/BER encoding, accepts varbinds in any order, etc. > to make it easier on applications. Let's not do something > intended to help applications which actually makes things worse. One option is indeed to define a single lexical representation for all YANG types, that is you can't formally ship ::1 as an IPv6 address and you have to use 0:0:0:0:0:0:0:1 instead. Then we can leave it to implementations to apply the postel principle and to accept ::1 where this is feasible. This way, the standard is clean and we have moved the problem into implementation space. We also accept potential surprises of users who might run into unexpected interoperability problems if they start to rely on the "lenient" behaviour of NETCONF implementations. Is this the way to go? This surely makes many pattern much simpler but still requires somewhat complex text to write down the specifics of the lexical representation so that we actually achieve a 1:1 mapping. /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 Oct 30 05:04: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 95DF13A6405; Thu, 30 Oct 2008 05:04: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 0C3B63A6405 for ; Thu, 30 Oct 2008 05:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.479 X-Spam-Level: X-Spam-Status: No, score=-1.479 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_45=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 mqM7A0hb4mf7 for ; Thu, 30 Oct 2008 05:04:01 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 410943A68E5 for ; Thu, 30 Oct 2008 05:04:01 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3B5FE76C502; Thu, 30 Oct 2008 13:03:59 +0100 (CET) Date: Thu, 30 Oct 2008 13:03:57 +0100 (CET) Message-Id: <20081030.130357.206588354.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1225367559.24841.20.camel@missotis> References: <49033F03.40402@netconfcentral.com> <20081030.111409.230716977.mbj@tail-f.com> <1225367559.24841.20.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] canonical data type representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDEjHQgMzAuIDEwLiAyMDA4IHYgMTE6MTQgKzAxMDA6DQo+IA0KPiA+IEZv ciB0aGUgZmxvYXQgdHlwZXMsIEkgZ3Vlc3MgdGhlcmUgaXMgYSBjYW5vbmljYWwgZm9ybWF0IGRl ZmluZWQNCj4gPiAoc29tZXdoZXJlKS4gIERvZXMgYW55Ym9keSBrbm93PyAgIFNob3VsZCB3ZSBj b3B5JnBhc3RlIGZyb20gdGhlIFhTRA0KPiANCj4gSUVFRSA3NTQNCg0KSXMgdGhlcmUgYSBjYW5v bmljYWwgZm9ybSBzcGVjaWZpZWQgdGhlcmU/ICBJIHdvdWxkbid0IGtub3csIGIvYyBJDQpjYW4n dCByZWFkIHRoZWlyIHN0YW5kYXJkIGFzIEknbSBub3QgYSBtZW1iZXIuDQoNCg0KL21hcnRpbg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1h aWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Thu Oct 30 05:09: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 E409C3A67E5; Thu, 30 Oct 2008 05:09: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 78AA23A691D for ; Thu, 30 Oct 2008 05:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_45=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 CvN4wMjeuzv4 for ; Thu, 30 Oct 2008 05:09:28 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id BD07F3A67E5 for ; Thu, 30 Oct 2008 05:09:28 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 636D5D800C8; Thu, 30 Oct 2008 13:09:27 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20081030.130357.206588354.mbj@tail-f.com> References: <49033F03.40402@netconfcentral.com> <20081030.111409.230716977.mbj@tail-f.com> <1225367559.24841.20.camel@missotis> <20081030.130357.206588354.mbj@tail-f.com> Organization: CESNET Date: Thu, 30 Oct 2008 13:09:27 +0100 Message-Id: <1225368567.24841.32.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: netmod@ietf.org Subject: Re: [netmod] canonical data type representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.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 TWFydGluIEJqb3JrbHVuZCBww63FoWUgdiDEjHQgMzAuIDEwLiAyMDA4IHYgMTM6MDMgKzAxMDA6 Cj4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToKPiA+IE1hcnRpbiBC am9ya2x1bmQgcMOtxaFlIHYgxIx0IDMwLiAxMC4gMjAwOCB2IDExOjE0ICswMTAwOgo+ID4gCj4g PiA+IEZvciB0aGUgZmxvYXQgdHlwZXMsIEkgZ3Vlc3MgdGhlcmUgaXMgYSBjYW5vbmljYWwgZm9y bWF0IGRlZmluZWQKPiA+ID4gKHNvbWV3aGVyZSkuICBEb2VzIGFueWJvZHkga25vdz8gICBTaG91 bGQgd2UgY29weSZwYXN0ZSBmcm9tIHRoZSBYU0QKPiA+IAo+ID4gSUVFRSA3NTQKPiAKPiBJcyB0 aGVyZSBhIGNhbm9uaWNhbCBmb3JtIHNwZWNpZmllZCB0aGVyZT8gIEkgd291bGRuJ3Qga25vdywg Yi9jIEkKPiBjYW4ndCByZWFkIHRoZWlyIHN0YW5kYXJkIGFzIEknbSBub3QgYSBtZW1iZXIuCgpO ZWl0aGVyIGFtIEkuIEkgY291bGQgcHJvYmFibHkgZ2V0IHRoZSBzdGFuZGFyZCBzb21ld2hlcmUg YnV0IHBlcmhhcHMgd2UKY291bGQganVzdCBjcmVhdGl2ZWx5IHJldXNlIHRoZSB0ZXh0IGZyb20g dGhlIFhTRCBzcGVjLgoKTGFkYQoKPiAKPiAKPiAvbWFydGluCi0tIApMYWRpc2xhdiBMaG90a2Es IENFU05FVApQR1AgS2V5IElEOiBFNzRFOEMwQwoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcK aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK From netmod-bounces@ietf.org Thu Oct 30 09: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 A7CE728C128; Thu, 30 Oct 2008 09: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 9061A28C12F for ; Thu, 30 Oct 2008 09:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0xedOs4KANM for ; Thu, 30 Oct 2008 09:44:19 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 874CA3A6A3F for ; Thu, 30 Oct 2008 09:44:19 -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 MAA13711; Thu, 30 Oct 2008 12:44:17 -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 MAA20541; Thu, 30 Oct 2008 12:44:17 -0400 (EDT) Message-Id: <200810301644.MAA20541@adminfs.snmp.com> To: Martin Bjorklund From: David Reid In-reply-to: Your message of Wed, 29 Oct 2008 22:24:52 +0100. <20081029.222452.83521868.mbj@tail-f.com> Date: Thu, 30 Oct 2008 12:44:16 -0400 Cc: netmod@ietf.org Subject: Re: [netmod] Proposed consensus mail on yang-00000: module update rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org I like the proposed changes. On the reorder issue, I like the example. It is not absolutely necessary, but I think it helps. -David Reid > David Reid wrote: > > Can I change an int8 to an int16? The consensus at the interim was no, but > > someone reading the spec may interpret that change as simply expanding the > > range and thus be a legal change. > > I'm guessing that it is this text that is not clear: > > OLD: > > A "type" statement may be replaced with another "type" statement > which does not change the syntax or semantics of the type. For > example, an inline type definition may be replaced with a typedef. > > Is this text sufficient: > > NEW: > > A "type" statement may be replaced with another "type" statement > which does not change the syntax or semantics of the type. For > example, an inline type definition may be replaced with a typedef, > but a int8 type cannot be replaced by a int16, since the syntax > would change. > > > > Are leaf order changes allowed? Again, the consensus at the interim was no, > > but that may not be clear in the spec. It is clear that you cannot delete a > > leaf, but it is not clear that you cannot change to ordering. > > Is this text ok: > > In statements which have any data definition statements as > substatements, those data definition substatements MUST NOT be > reordered. > > Should I add an example? > > For example, the order among all leafs defined in a list must be > maintained. > > > /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Oct 30 10:25:29 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F083A69D3; Thu, 30 Oct 2008 10:25:29 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64ED23A6A9E for ; Thu, 30 Oct 2008 10:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=0.244, 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 lhToQCwwOySn for ; Thu, 30 Oct 2008 10:25:22 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 9E68C3A6A45 for ; Thu, 30 Oct 2008 10:25:18 -0700 (PDT) Received: (qmail 42258 invoked from network); 30 Oct 2008 17:25:17 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 30 Oct 2008 17:25:15 -0000 X-YMail-OSG: RYpgSGwVM1nl5I9EBHi9OlRekKZi3r7ftkU4kMWejlGrHE52RJStyhAo1CK2dJZ2jbfHHLjo7YVljSDttbfpwSzoEMOPc8A3mqDEJAUkf0pOg5grVqlxa38oWSNksxov6Yg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4909EDF9.2030704@netconfcentral.com> Date: Thu, 30 Oct 2008 10:25:13 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: David Reid References: <200810301644.MAA20541@adminfs.snmp.com> In-Reply-To: <200810301644.MAA20541@adminfs.snmp.com> Cc: netmod@ietf.org Subject: Re: [netmod] Proposed consensus mail on yang-00000: module update rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org David Reid wrote: > I like the proposed changes. On the reorder issue, I like the example. It is > not absolutely necessary, but I think it helps. >.... >> NEW: >> >> A "type" statement may be replaced with another "type" statement >> which does not change the syntax or semantics of the type. For >> example, an inline type definition may be replaced with a typedef, >> but a int8 type cannot be replaced by a int16, since the syntax >> would change. >> Not the syntax, it is the semantics that will change. The meaning of 'min' and 'max' in ranges is fixed, based on the specific typedef chain. Changing int8 to int16 changes the upper-bound, and the meaning of any 'max' keyword upstream in the typedef chain. >> >>> Are leaf order changes allowed? Again, the consensus at the interim was no, >>> but that may not be clear in the spec. It is clear that you cannot delete a >>> leaf, but it is not clear that you cannot change to ordering. >> Is this text ok: >> >> In statements which have any data definition statements as >> substatements, those data definition substatements MUST NOT be >> reordered. >> >> Should I add an example? >> >> For example, the order among all leafs defined in a list must be >> maintained. >> perhaps there should be an addition to the 'Terms' section for the term 'schema order'? Any data-def-stmt reordering (in groupings too) should be an error. Reordering enums or bits is an error. I owe Martin some text on canonical ordering, and hopefully it will be clear that the position of any nodes ordered by YANG file definition (sibling order within a parent construct) should remain stable for the lifetime of the module. >> >> /martin Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Oct 30 10:57:15 2008 Return-Path: X-Original-To: netmod-archive@ietf.org Delivered-To: ietfarch-netmod-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8830B3A6A68; Thu, 30 Oct 2008 10:57:15 -0700 (PDT) X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BFB73A6ADB for ; Thu, 30 Oct 2008 10:57:14 -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 LGe9-1bX6K02 for ; Thu, 30 Oct 2008 10:57:10 -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 8395F3A6AD9 for ; Thu, 30 Oct 2008 10:57:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=mo3lQQjovLmBTxO6XkXkyiVDWcv8cvsERGyKLAZzNGO6cPW5eKFqjUK9dF5zhDrg; 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.165.6.158] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KvblU-000785-MQ for netmod@ietf.org; Thu, 30 Oct 2008 13:57:01 -0400 Message-ID: <003401c93ab8$ee303520$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200810301644.MAA20541@adminfs.snmp.com> <4909EDF9.2030704@netconfcentral.com> Date: Thu, 30 Oct 2008 10:57:09 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e46ffe0358fd660ad389989b88bef7c42a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.6.158 Subject: Re: [netmod] Proposed consensus mail on yang-00000: module update rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hi - > From: "Andy Bierman" > To: "David Reid" > Cc: > Sent: Thursday, October 30, 2008 10:25 AM > Subject: Re: [netmod] Proposed consensus mail on yang-00000: module update rules ... > Not the syntax, it is the semantics that will change. > The meaning of 'min' and 'max' in ranges is fixed, > based on the specific typedef chain. Changing int8 to int16 > changes the upper-bound, and the meaning of any 'max' keyword > upstream in the typedef chain. ... This is actually an argument against adding values to a range in general. Perhaps not surprisingly, this is consistent with the GDMO rules for subclassing - a subclass can only *restrict*, not extend, the ranges of inherited attributes in those kinds of models. Though at first glance this might seem backwards, it's actually the right thing to do. (I'm agreeing with Andy) Even though netmod isn't O-O, it may be helpful to think of it this way: a standardized superclass in that world typically sets out the *architectural* constraints on whatever sort of thing is being described, and vendor-specific subclasses derived from that superclass impose the additional limitations that characterize particular implementations. In that view, the only permissible refinement of an attribute would be to further constrain its value set from the set of values that are *architecturally* possible in the superclass. This is *NOT* how things worked in SNMP SMI, which explicitly allows adding values to enumerations, for example. Consequently, I think this group needs to think about metamodels (in the very broad sense) a bit, because a lot of the decisions about what are and what are not "compatible" changes / extensions will flow from it. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Oct 30 12:56: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 D93593A6894; Thu, 30 Oct 2008 12:56: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 340683A6A45 for ; Thu, 30 Oct 2008 12:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.174, 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 9L-j1CRPpTTT for ; Thu, 30 Oct 2008 12:56: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 C57423A6A6C for ; Thu, 30 Oct 2008 12:56:35 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 8101E616001; Thu, 30 Oct 2008 20:56:33 +0100 (CET) Date: Thu, 30 Oct 2008 20:56:28 +0100 (CET) Message-Id: <20081030.205628.248965819.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <003401c93ab8$ee303520$6801a8c0@oemcomputer> References: <200810301644.MAA20541@adminfs.snmp.com> <4909EDF9.2030704@netconfcentral.com> <003401c93ab8$ee303520$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] Proposed consensus mail on yang-00000: module update rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org "Randy Presuhn" wrote: > Consequently, I think this group needs to think about metamodels (in > the very broad sense) a bit, because a lot of the decisions about what > are and what are not "compatible" changes / extensions will flow from it. All module upgrade rules we have are derived from two design goals: - Protect old clients We want a client that uses version x of a module to be able to function when talking to a server implementing version x+1. - Protect importers A new published module version must not break existing other modules that imports from the module. So for example, the value space of a leaf must not be restricted in the new version, since if e.g. an enumeration is removed, an old client that tries to set the removed value will fail. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Thu Oct 30 12:57: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 509123A6951; Thu, 30 Oct 2008 12:57: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 C5D123A6A6C for ; Thu, 30 Oct 2008 12:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fug4P675r1oG for ; Thu, 30 Oct 2008 12:57: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 F30983A6951 for ; Thu, 30 Oct 2008 12:57:36 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 7C20D616001; Thu, 30 Oct 2008 20:57:35 +0100 (CET) Date: Thu, 30 Oct 2008 20:57:33 +0100 (CET) Message-Id: <20081030.205733.109314597.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4909EDF9.2030704@netconfcentral.com> References: <200810301644.MAA20541@adminfs.snmp.com> <4909EDF9.2030704@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] Proposed consensus mail on yang-00000: module update rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Andy Bierman wrote: > David Reid wrote: > > I like the proposed changes. On the reorder issue, I like the example. It is > > not absolutely necessary, but I think it helps. > >.... > >> NEW: > >> > >> A "type" statement may be replaced with another "type" statement > >> which does not change the syntax or semantics of the type. For > >> example, an inline type definition may be replaced with a typedef, > >> but a int8 type cannot be replaced by a int16, since the syntax > >> would change. > >> > > Not the syntax, it is the semantics that will change. > The meaning of 'min' and 'max' in ranges is fixed, > based on the specific typedef chain. Changing int8 to int16 > changes the upper-bound, and the meaning of any 'max' keyword > upstream in the typedef chain. The editor does not understand the edits. Can you provide some text? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Oct 31 10:10: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 C6FAB3A6987; Fri, 31 Oct 2008 10:10: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 5828A3A6C1F for ; Fri, 31 Oct 2008 10:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhRVUk2iMInA for ; Fri, 31 Oct 2008 10:10:10 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 1A5163A6A0B for ; Fri, 31 Oct 2008 10:10:09 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 85497221B1; Fri, 31 Oct 2008 18:10:04 +0100 (CET) X-AuditID: c1b4fb3e-abf80bb00000537b-6a-490b3bec5276 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6AA77221A2; Fri, 31 Oct 2008 18:10:04 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Oct 2008 18:10:04 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Oct 2008 18:10:04 +0100 Message-ID: <490B3BEB.20608@ericsson.com> Date: Fri, 31 Oct 2008 18:10:03 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <200810301644.MAA20541@adminfs.snmp.com> <4909EDF9.2030704@netconfcentral.com> <003401c93ab8$ee303520$6801a8c0@oemcomputer> <20081030.205628.248965819.mbj@tail-f.com> In-Reply-To: <20081030.205628.248965819.mbj@tail-f.com> X-OriginalArrivalTime: 31 Oct 2008 17:10:04.0113 (UTC) FILETIME=[8429FC10:01C93B7B] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Proposed consensus mail on yang-00000: module update rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Hello, IMHO it would be nice to have these two principles in the text. Balazs Martin Bjorklund wrote: > "Randy Presuhn" wrote: >> Consequently, I think this group needs to think about metamodels (in >> the very broad sense) a bit, because a lot of the decisions about what >> are and what are not "compatible" changes / extensions will flow from it. > > All module upgrade rules we have are derived from two design goals: > > - Protect old clients > We want a client that uses version x of a module to be able to > function when talking to a server implementing version x+1. > > - Protect importers > A new published module version must not break existing other > modules that imports from the module. > > So for example, the value space of a leaf must not be restricted in > the new version, since if e.g. an enumeration is removed, an old > client that tries to set the removed value will fail. > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From netmod-bounces@ietf.org Fri Oct 31 10:14: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 746393A6C2F; Fri, 31 Oct 2008 10:14: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 EB5DB3A695A for ; Fri, 31 Oct 2008 10:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 I6St+0qVStQ5 for ; Fri, 31 Oct 2008 10:14:18 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 835813A6C34 for ; Fri, 31 Oct 2008 10:14:18 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3750C2134B; Fri, 31 Oct 2008 18:14:16 +0100 (CET) X-AuditID: c1b4fb3c-ac8cbbb0000015b5-63-490b3ce8634b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 16B022060B; Fri, 31 Oct 2008 18:14:16 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Oct 2008 18:14:15 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Oct 2008 18:14:15 +0100 Message-ID: <490B3CE7.1050007@ericsson.com> Date: Fri, 31 Oct 2008 18:14:15 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <200810281602.50774.david.partain@ericsson.com> <200810282054.QAA18022@adminfs.snmp.com> <20081028.222710.251029462.mbj@tail-f.com> In-Reply-To: <20081028.222710.251029462.mbj@tail-f.com> X-OriginalArrivalTime: 31 Oct 2008 17:14:15.0704 (UTC) FILETIME=[1A1FB980:01C93B7C] X-Brightmail-Tracker: AAAAAA== Cc: netmod@ietf.org Subject: Re: [netmod] Proposed consensus mail on yang-00000: module update rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netmod-bounces@ietf.org Errors-To: netmod-bounces@ietf.org Martin Bjorklund wrote: > A definition may be revised in any of the following ways: > > - New data definition statements may be added if they do not add > mandatory nodes (^mandatory-nodes^) to existing nodes, or if they > are conditionally dependent on a new feature (i.e. have a > "if-feature" statement which refers to a new feature). BALAZS: So a new mandatory leaf at the root level is allowed? I think it must not. That is a clear incompatible change will brake old managers. Balazs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod