From j.schoenwaelder@jacobs-university.de Mon Mar 4 12:07:21 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28CF21F8ED4 for ; Mon, 4 Mar 2013 12:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.989 X-Spam-Level: X-Spam-Status: No, score=-102.989 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVnzq1jQqHD8 for ; Mon, 4 Mar 2013 12:07:21 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA2D21F8AB4 for ; Mon, 4 Mar 2013 12:07:21 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F2DD920BD6; Mon, 4 Mar 2013 21:07:19 +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 BCsnp8sdVJdw; Mon, 4 Mar 2013 21:07:19 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A7B420A1F; Mon, 4 Mar 2013 21:07:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CE7D324D4797; Mon, 4 Mar 2013 21:07:29 +0100 (CET) Date: Mon, 4 Mar 2013 21:07:29 +0100 From: Juergen Schoenwaelder To: "Lisa Huang (yihuan)" Message-ID: <20130304200729.GA9167@elstar.local> Mail-Followup-To: "Lisa Huang (yihuan)" , "netmod@ietf.org" References: <559E176269AD64429F1582D4EB94F86FCB426A@xmb-aln-x03.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <559E176269AD64429F1582D4EB94F86FCB426A@xmb-aln-x03.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] New Version ACL Yang model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 20:07:21 -0000 On Tue, Feb 26, 2013 at 10:42:23PM +0000, Lisa Huang (yihuan) wrote: > Hi, > > This is a new version of ACL Yang model I-D. Yesterday, we missed the deadline since I did not read the time zone information carefully enough. As Juergen kindly suggested, I attached the new version in email to make it available to the WG. > A miracle just happened an draft-huang-netmod-acl-02.txt showed up in the I-D repository so that we have easy access to diffs etc. http://tools.ietf.org/html/draft-huang-netmod-acl-02 /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From david.kessens@nsn.com Tue Mar 5 16:04:53 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CF121F853C for ; Tue, 5 Mar 2013 16:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70uVLNq4vIsW for ; Tue, 5 Mar 2013 16:04:53 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id B221321F852B for ; Tue, 5 Mar 2013 16:04:52 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r2604pXw000405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 6 Mar 2013 01:04:51 +0100 Received: from localhost.localdomain ([10.138.53.242]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r2604ngj024562 for ; Wed, 6 Mar 2013 01:04:50 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.5/8.14.5) with ESMTP id r2604m4P005247 for ; Tue, 5 Mar 2013 16:04:48 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.5/8.14.5/Submit) id r2604mDR005246 for netmod@ietf.org; Tue, 5 Mar 2013 16:04:48 -0800 Date: Tue, 5 Mar 2013 16:04:48 -0800 From: David Kessens To: netmod@ietf.org Message-ID: <20130306000448.GF2854@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 330 X-purgate-ID: 151667::1362528291-0000547A-E0F236A7/0-0/0-0 Subject: [netmod] Last Call draft-ietf-netmod-snmp-cfg-01 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 00:04:53 -0000 I would hereby like to start a Last Call for: http://tools.ietf.org/html/draft-ietf-netmod-snmp-cfg-01 Please indicate your support by Wed March 20, 2013. Or alternatively, let us know in the same timeframe whether there are still issues that need to be resolved. Thanks! David Kessens co-chair netmod wg --- From david.kessens@nsn.com Tue Mar 5 16:05:55 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2715811E80D2 for ; Tue, 5 Mar 2013 16:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1GoiSTQjYBA for ; Tue, 5 Mar 2013 16:05:54 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAAF21F86BA for ; Tue, 5 Mar 2013 16:05:42 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r2605gVs001921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 6 Mar 2013 01:05:42 +0100 Received: from localhost.localdomain ([10.138.53.242]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r2605e9K026882 for ; Wed, 6 Mar 2013 01:05:41 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.5/8.14.5) with ESMTP id r2605dhc005278 for ; Tue, 5 Mar 2013 16:05:39 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.5/8.14.5/Submit) id r2605dKp005277 for netmod@ietf.org; Tue, 5 Mar 2013 16:05:39 -0800 Date: Tue, 5 Mar 2013 16:05:39 -0800 From: David Kessens To: netmod@ietf.org Message-ID: <20130306000539.GG2854@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 340 X-purgate-ID: 151667::1362528342-0000547A-44CF8D7F/0-0/0-0 Subject: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 00:05:55 -0000 Hi, I would hereby like to start a Last Call for: http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-05 Please indicate your support by Wed March 20, 2013. Or alternatively, let us know in the same timeframe whether there are still issues that need to be resolved. Thanks! David Kessens co-chair netmod wg --- From jeffrey.K.lange@ge.com Wed Mar 6 05:30:38 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D5C21F874F for ; Wed, 6 Mar 2013 05:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZanQRXmBlvH0 for ; Wed, 6 Mar 2013 05:30:38 -0800 (PST) Received: from exprod5og116.obsmtp.com (exprod5og116.obsmtp.com [64.18.0.147]) by ietfa.amsl.com (Postfix) with ESMTP id D829A21F869E for ; Wed, 6 Mar 2013 05:30:37 -0800 (PST) Received: from alpmlip13.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob116.postini.com ([64.18.4.12]) with SMTP ID DSNKUTdE/Z08+SZ/BgKp+6413D83Kni6itoJ@postini.com; Wed, 06 Mar 2013 05:30:37 PST Received: from unknown (HELO alpmlef08.e2k.ad.ge.com) ([3.159.18.17]) by alpmlip13.e2k.ad.ge.com with ESMTP; 06 Mar 2013 08:30:35 -0500 Received: from cinmlef17.e2k.ad.ge.com ([3.159.213.93]) by alpmlef08.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Mar 2013 08:30:36 -0500 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by cinmlef17.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Mar 2013 08:30:35 -0500 Received: from CINMBCNA09.e2k.ad.ge.com (3.159.212.38) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 6 Mar 2013 08:30:31 -0500 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.118]) by CINMBCNA09.e2k.ad.ge.com ([169.254.3.33]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 08:30:31 -0500 From: "Lange, Jeffrey K (GE Energy Management)" To: David Kessens , "netmod@ietf.org" Thread-Topic: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) Thread-Index: AQHOGf5h4BW34ttQAUyqw4UcXS8iLJiYqReg Date: Wed, 6 Mar 2013 13:30:30 +0000 Message-ID: References: <20130306000539.GG2854@nsn.com> In-Reply-To: <20130306000539.GG2854@nsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Mar 2013 13:30:35.0589 (UTC) FILETIME=[C8ADEF50:01CE1A6E] Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 13:30:39 -0000 This references: [I-D.lange-netmod-iana-timezones] Lange, J., "IANA Timezone Database YANG Module", draft-lange-netmod-iana-timezones-01 (work in progress), June 2012. Which technically "expired" Does something need to happen to bring this bac= k from the grave? Or is this OK? -Jeff > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of David Kessens > Sent: Tuesday, March 05, 2013 7:06 PM > To: netmod@ietf.org > Subject: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) >=20 >=20 > Hi, >=20 > I would hereby like to start a Last Call for: >=20 > http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-05 >=20 > Please indicate your support by Wed March 20, 2013. Or alternatively, let= us > know in the same timeframe whether there are still issues that need to be > resolved. >=20 > Thanks! >=20 > David Kessens > co-chair netmod wg > --- > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From j.schoenwaelder@jacobs-university.de Wed Mar 6 05:42:45 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10D021F89FD for ; Wed, 6 Mar 2013 05:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.063 X-Spam-Level: X-Spam-Status: No, score=-103.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTb1ajPs0I0y for ; Wed, 6 Mar 2013 05:42:45 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4A38E21F89E2 for ; Wed, 6 Mar 2013 05:42:45 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 54EB920BE5; Wed, 6 Mar 2013 14:42:44 +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 CS8U0x2ityTw; Wed, 6 Mar 2013 14:42:44 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E65A820BDB; Wed, 6 Mar 2013 14:42:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6D89D24DA3FF; Wed, 6 Mar 2013 14:42:54 +0100 (CET) Date: Wed, 6 Mar 2013 14:42:54 +0100 From: Juergen Schoenwaelder To: "Lange, Jeffrey K (GE Energy Management)" Message-ID: <20130306134254.GC19899@elstar.local> Mail-Followup-To: "Lange, Jeffrey K (GE Energy Management)" , David Kessens , "netmod@ietf.org" References: <20130306000539.GG2854@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 13:42:46 -0000 On Wed, Mar 06, 2013 at 01:30:30PM +0000, Lange, Jeffrey K (GE Energy Management) wrote: > This references: > > [I-D.lange-netmod-iana-timezones] > Lange, J., "IANA Timezone Database YANG Module", > draft-lange-netmod-iana-timezones-01 (work in progress), > June 2012. > > Which technically "expired" Does something need to happen to bring this back from the grave? Or is this OK? I think this is not perfect but OK for now. The document is still available here: http://tools.ietf.org/html/draft-lange-netmod-iana-timezones-01 /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From per@tail-f.com Wed Mar 6 06:02:33 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34C421F85FC for ; Wed, 6 Mar 2013 06:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH7ErTjcTFqG for ; Wed, 6 Mar 2013 06:02:32 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C2C2F21F85A1 for ; Wed, 6 Mar 2013 06:02:32 -0800 (PST) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id E4E341200D5E for ; Wed, 6 Mar 2013 15:02:30 +0100 (CET) Message-ID: <51374C76.8070902@tail-f.com> Date: Wed, 06 Mar 2013 15:02:30 +0100 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110120 Thunderbird/3.1.7 MIME-Version: 1.0 To: netmod@ietf.org References: <20130306000539.GG2854@nsn.com> In-Reply-To: <20130306000539.GG2854@nsn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 14:02:33 -0000 Hi, I have reviewed this draft, and have comments only on the crypt-hash typedef and its use for the password leaf in the user list. The only issue that I think really *needs* to be resolved is that the Wikipedia link is wrong, referencing crypt(1) rather than crypt(3) - i.e. OLD: Wikipedia: http://en.wikipedia.org/wiki/Crypt_(Unix) NEW: Wikipedia: http://en.wikipedia.org/wiki/Crypt_(C) Other than that I have some questions that may or may not need to be addressed: 1. Is it a problem that there is no "real" specification of the algorithms used for the hashing? I.e. not MD5/SHA, but how they are applied. As far as I can see, the IEEE 1003.1-2008 reference that "looks" like it may be to a spec says basically just The algorithm is implementation-defined. and The values returned by this function need not be portable among XSI-conformant systems. Of course there are "reference implementations" of the algorithms in at least FreeBSD libc and glibc. Should (could) these be referenced somehow? 2. If "implementation-defined" is the answer to 1, is there any point in specifying the formats at all? Obviously a NETCONF client can not in general configure a pre-hashed password in this case. 3. The "reference implementations" of type 5 and 6 allow for an additional 'rounds' parameter with a value in the range 1000 .. 999999999 (default is 5000), i.e. the "hashed value" can be e.g. "$5$rounds=10000$saltstringsaltst$3xv.VbSHBb41AL9AvLeujZkZRBAwqFMz2.". This is not allowed by the pattern in the typedef - should it be? 4. Should there be some text about how a server chooses between the algorithms when hashing a cleartext password (assuming it supports more than one, of course)? --Per Hedeland From phil@juniper.net Wed Mar 6 12:11:52 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AC021F8A43 for ; Wed, 6 Mar 2013 12:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5gZIuVxMa5p for ; Wed, 6 Mar 2013 12:11:51 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id A0F2A21F89A4 for ; Wed, 6 Mar 2013 12:11:44 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUTejAIbB0INZqkInddo68ptQtoFGgCjg@postini.com; Wed, 06 Mar 2013 12:11:47 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 6 Mar 2013 12:09:09 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r26K98325593; Wed, 6 Mar 2013 12:09:08 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id r26K8H5c006746; Wed, 6 Mar 2013 15:08:37 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201303062008.r26K8H5c006746@idle.juniper.net> To: Per Hedeland In-Reply-To: <51374C76.8070902@tail-f.com> Date: Wed, 6 Mar 2013 15:08:17 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 20:11:52 -0000 Here are some additional comments on the draft: 2.1: having location as an opaque field renders it useless for automation. In JUNOS, our [system location] contains: attribute country-code { help "Two-letter country code"; type string; } attribute postal-code { help "Zip code or postal code"; type string; } attribute npa-nxx { help "First six digits of phone number (area code plus exchange)"; type string; } attribute latitude { help "Latitude in degree format"; type string; } attribute longitude { help "Longitude in degree format"; type string; } attribute altitude { help "Feet above (or below) sea level"; type int; } attribute lata { help "Long-distance service area"; type string; } attribute vcoord { help "Bellcore vertical coordinate"; type string; } attribute hcoord { help "Bellcore horizontal coordinate"; type string; } attribute building { help "Building name"; type string; } attribute floor { help "Floor of the building"; type int; } attribute rack { help "Rack number"; type uint; } These were the requirements from our customers >10 years ago and seem to be enough for everyone. (Okay, altitude was my addition.....) Fix: add additional fields. 2.3 says publickey and password are both required, but this need not be true. I've been turning off ssh passwords on my public boxes to keep the script kiddies at bay. RADIUS is also mentioned as a "need", but there are many others (tacplus, skey, etc). Fix: don't call out specific technology requirements. 3.1: Is "name" the DNS name of the device? Can we say that, either here or in the description? "administratively assigned system name" doesn't mean much to the average reader. 3.2: Why have use-ntp? Why not have [system ntp] a purpose container? You list ntp-server (nuke the leading "ntp-"), but not peers or boot servers. You are missing authentication keys, source address, version, polling interval constraints (min and max), broadcast server and client info, and multicast client info. re: enabled: would be good to make a generic means for this, so we don't need to put this knob on every container. 3.3: In JUNOS, we call out the local domain explicitly, distinct from the domain search path. This is similar to the "domain" and "search" fields in BSD's resolv.conf. 3.4: Should RADIUS config be in a distinct module, augmenting this one? Using a feature work, but skey, tacplus, etc need config also. Are we saying that RADIUS is the only modern/needed one? 3.5: The user-authentication-order must says: must '(. = "sys:radius" and ../../radius/server) or' + '(. != "sys:radius")' { which is '. != "sys:radius" || ../../radius/server', right? Passwords without the leading $ are old-school style. Support them? In the same vein, JUNOS uses $9$ for obfuscating secret data to avoid allowing over-the-shoulder password stealing. It's only obfuscation, but is still useful for secrets that we need in plain text later and cannot use just the hash. Similar with systems that use a single "master password" to encrypt secret data. What is an ssh key's name? Just a user-defined handle? Why not use the complete ssh key as the key? Why is ssh key data binary? Users require both authentication and authorization. In JUNOS, we put this under a container under "system" named "login" with two lists, "users" and "classes". The login class can be used to constrict (or expand) the user's permissions, as well as setting time of day restrictions, source address restrictions, and cosmetic bits like displaying alarms or help text at login time on the CLI. 3.6: Consider making a leaf under a single operation, ala the BSD shutdown command. Why are the shutdown operations "deny-all"? Thanks, Phil From andy@yumaworks.com Wed Mar 6 12:50:35 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50A421F8CCB for ; Wed, 6 Mar 2013 12:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=1.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sh1SJd6ndG0 for ; Wed, 6 Mar 2013 12:50:30 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0F521F8CD2 for ; Wed, 6 Mar 2013 12:50:26 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id k14so10094235iea.13 for ; Wed, 06 Mar 2013 12:50:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=FwNzdHFefgwhCjbYfVldAiD5mF7DqFjICksa4gS/YWw=; b=hiB1DrGbReogbF5aQsgMXoq/pTzU3RIsiPcnh4l1TGwtIYBBI2iZe4o9coLYg/4MGl u78zVi9Y1RF3pIOiTjbJWMnEywFRcsU5alAQI18FgKXQL1qVHxTb9EHPy+A29u67WRqz m6kzRHmEaSorOVwrv2Ti42JPo59c61kddtxlD/blOjcHi4FM6nIqrRFtsbQE29ZzlF4L HaYy6/Qc3xSPMG6P8DmNMb4bSAwvenVx3OEdVf5xT9bO9JsS9SiYTmIXZ5nTbdB/gTa4 7/09xhV6ystWHRq5hf8bE7pRgty+4N7sdwEkiMnRb5JqZbetFEPGklkXW4IrT8Ve5vLc 7+yw== MIME-Version: 1.0 X-Received: by 10.50.12.137 with SMTP id y9mr12061643igb.57.1362603019002; Wed, 06 Mar 2013 12:50:19 -0800 (PST) Received: by 10.231.93.6 with HTTP; Wed, 6 Mar 2013 12:50:18 -0800 (PST) In-Reply-To: <201303062008.r26K8H5c006746@idle.juniper.net> References: <51374C76.8070902@tail-f.com> <201303062008.r26K8H5c006746@idle.juniper.net> Date: Wed, 6 Mar 2013 12:50:18 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlfvx3TIKZxpZiIw7aMes3s8fkW/eGV2zbHJ251bVgckiWMm/+6QaataohuQ3Z4Esu2Iofc Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 20:50:35 -0000 On Wed, Mar 6, 2013 at 12:08 PM, Phil Shafer wrote: > Here are some additional comments on the draft: > > 2.1: having location as an opaque field renders it useless for > automation. In JUNOS, our [system location] contains: > > attribute country-code { > help "Two-letter country code"; > type string; > } > attribute postal-code { > help "Zip code or postal code"; > type string; > } > attribute npa-nxx { > help "First six digits of phone number (area code plus exchange)"; > type string; > } > attribute latitude { > help "Latitude in degree format"; > type string; > } > attribute longitude { > help "Longitude in degree format"; > type string; > } > attribute altitude { > help "Feet above (or below) sea level"; > type int; > } > attribute lata { > help "Long-distance service area"; > type string; > } > attribute vcoord { > help "Bellcore vertical coordinate"; > type string; > } > attribute hcoord { > help "Bellcore horizontal coordinate"; > type string; > } > attribute building { > help "Building name"; > type string; > } > > attribute floor { > help "Floor of the building"; > type int; > } > > attribute rack { > help "Rack number"; > type uint; > } > > These were the requirements from our customers >10 years ago and seem > to be enough for everyone. (Okay, altitude was my addition.....) > > Fix: add additional fields. The system leaf is intended to be the same value as sysLocation from SNMP. Not sure about all these new feature requests that could have come up any time in the 15 months since draft-00 came out. The WG will have to go through them 1 by 1 I guess. Andy > > 2.3 says publickey and password are both required, but this need > not be true. I've been turning off ssh passwords on my public boxes > to keep the script kiddies at bay. > > RADIUS is also mentioned as a "need", but there are many others > (tacplus, skey, etc). > > Fix: don't call out specific technology requirements. > > 3.1: Is "name" the DNS name of the device? Can we say that, either > here or in the description? "administratively assigned system name" > doesn't mean much to the average reader. > > 3.2: Why have use-ntp? Why not have [system ntp] a purpose container? > > You list ntp-server (nuke the leading "ntp-"), but not peers or boot > servers. You are missing authentication keys, source address, > version, polling interval constraints (min and max), broadcast server > and client info, and multicast client info. > > re: enabled: would be good to make a generic means for this, so we > don't need to put this knob on every container. > > 3.3: In JUNOS, we call out the local domain explicitly, distinct from > the domain search path. This is similar to the "domain" and "search" > fields in BSD's resolv.conf. > > 3.4: Should RADIUS config be in a distinct module, augmenting this > one? Using a feature work, but skey, tacplus, etc need config also. > Are we saying that RADIUS is the only modern/needed one? > > 3.5: The user-authentication-order must says: > > must '(. = "sys:radius" and ../../radius/server) or' > + '(. != "sys:radius")' { > > which is '. != "sys:radius" || ../../radius/server', right? > > Passwords without the leading $ are old-school style. Support them? > > In the same vein, JUNOS uses $9$ for obfuscating secret data to avoid > allowing over-the-shoulder password stealing. It's only obfuscation, > but is still useful for secrets that we need in plain text later and > cannot use just the hash. Similar with systems that use a single > "master password" to encrypt secret data. > > What is an ssh key's name? Just a user-defined handle? Why not use > the complete ssh key as the key? > > Why is ssh key data binary? > > Users require both authentication and authorization. In JUNOS, > we put this under a container under "system" named "login" with two > lists, "users" and "classes". The login class can be used to > constrict (or expand) the user's permissions, as well as setting time > of day restrictions, source address restrictions, and cosmetic bits > like displaying alarms or help text at login time on the CLI. > > 3.6: Consider making a leaf under a single > operation, ala the BSD shutdown command. > > Why are the shutdown operations "deny-all"? > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Wed Mar 6 14:17:38 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E8011E81BF for ; Wed, 6 Mar 2013 14:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.046 X-Spam-Level: X-Spam-Status: No, score=-4.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeDMPKdhQIiY for ; Wed, 6 Mar 2013 14:17:37 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3070911E81B6 for ; Wed, 6 Mar 2013 14:17:37 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 7B5C11200A36; Wed, 6 Mar 2013 23:17:35 +0100 (CET) Date: Wed, 06 Mar 2013 23:17:34 +0100 (CET) Message-Id: <20130306.231734.295558367.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201303062008.r26K8H5c006746@idle.juniper.net> References: <51374C76.8070902@tail-f.com> <201303062008.r26K8H5c006746@idle.juniper.net> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 22:17:38 -0000 Hi Phil, First of all, thank you very much for your review! Phil Shafer wrote: > Here are some additional comments on the draft: > > 2.1: having location as an opaque field renders it useless for > automation. In JUNOS, our [system location] contains: > > attribute country-code { > help "Two-letter country code"; > type string; > } > attribute postal-code { > help "Zip code or postal code"; > type string; > } > attribute npa-nxx { > help "First six digits of phone number (area code plus exchange)"; > type string; > } > attribute latitude { > help "Latitude in degree format"; > type string; > } > attribute longitude { > help "Longitude in degree format"; > type string; > } > attribute altitude { > help "Feet above (or below) sea level"; > type int; > } > attribute lata { > help "Long-distance service area"; > type string; > } > attribute vcoord { > help "Bellcore vertical coordinate"; > type string; > } > attribute hcoord { > help "Bellcore horizontal coordinate"; > type string; > } > attribute building { > help "Building name"; > type string; > } > > attribute floor { > help "Floor of the building"; > type int; > } > > attribute rack { > help "Rack number"; > type uint; > } > > These were the requirements from our customers >10 years ago and seem > to be enough for everyone. (Okay, altitude was my addition.....) > > Fix: add additional fields. This (or parts of it) was discussed in the thread starting with http://www.ietf.org/mail-archive/web/netmod/current/msg07065.html. I guess no real conclusion was made in this thread. > 2.3 says publickey and password are both required, but this need > not be true. Note that section 2 is Objectives - this text just says that the data model must support both publickey and password. > I've been turning off ssh passwords on my public boxes > to keep the script kiddies at bay. > > RADIUS is also mentioned as a "need", but there are many others > (tacplus, skey, etc). Again, this is the design objective. I agree there are other mechanism, see more below. > Fix: don't call out specific technology requirements. > > 3.1: Is "name" the DNS name of the device? Can we say that, either > here or in the description? No, it doesn't have to be the "DNS name of the device" (whatever that is...). > "administratively assigned system name" > doesn't mean much to the average reader. This text is copied from RFC 3418 (sysName) (which is also referenced). > 3.2: Why have use-ntp? Why not have [system ntp] a purpose container? As long as we don't have active/inactive (see Kent's draft), we'll see these kinds of leafs. > You list ntp-server (nuke the leading "ntp-") Agreed, will fix. > but not peers or boot > servers. You are missing authentication keys, source address, > version, polling interval constraints (min and max), broadcast server > and client info, and multicast client info. We had more earlier, but have been going back and forth. See for example http://www.ietf.org/mail-archive/web/netmod/current/msg06529.html for some comments. > re: enabled: would be good to make a generic means for this, so we > don't need to put this knob on every container. > > 3.3: In JUNOS, we call out the local domain explicitly, distinct from > the domain search path. This is similar to the "domain" and "search" > fields in BSD's resolv.conf. In an earlier version of this model we had: The 'domain' keyword of /etc/resolv.conf is not supported, since it is equivalent to 'search' with a single domain. > 3.4: Should RADIUS config be in a distinct module, augmenting this > one? Using a feature work, but skey, tacplus, etc need config also. > Are we saying that RADIUS is the only modern/needed one? RADIUS is the only ietf standards track of the ones you mention. We could put this in a separate module, in order to get a cleaner separation, but then you could argue that we should do that with everything else (ntp, dns, ...) as well, and then this module won't contain much. The current approach is pragmatic; we put in some generally useful parameters, and then the model can be augmented with additional stuff. > 3.5: The user-authentication-order must says: > > must '(. = "sys:radius" and ../../radius/server) or' > + '(. != "sys:radius")' { > > which is '. != "sys:radius" || ../../radius/server', right? Yes, will fix! > Passwords without the leading $ are old-school style. Support them? Actually, they are not supported. The pattern is: pattern "$0$.*|$(1|5|6)$[a-zA-Z0-9./]{2,16}$.*"; > In the same vein, JUNOS uses $9$ for obfuscating secret data to avoid > allowing over-the-shoulder password stealing. It's only obfuscation, > but is still useful for secrets that we need in plain text later and > cannot use just the hash. Similar with systems that use a single > "master password" to encrypt secret data. Yes, we have something similar (for encrypted data). But note that this type is called crypt-hash, and it should be used for this purpose. If you need obfuscated or encrypted data, use another type. > What is an ssh key's name? Just a user-defined handle? Yes. > Why not use > the complete ssh key as the key? It is a bit bulky. > Why is ssh key data binary? B/c it can contain any octets. Note that the textual representation is base64 encoded, which happens to be a common way to represent ssh keys. > Users require both authentication and authorization. In JUNOS, > we put this under a container under "system" named "login" with two > lists, "users" and "classes". The login class can be used to > constrict (or expand) the user's permissions, as well as setting time > of day restrictions, source address restrictions, and cosmetic bits > like displaying alarms or help text at login time on the CLI. Authorization is handled by RFC 6536 (nacm). > 3.6: Consider making a leaf under a single > operation, ala the BSD shutdown command. > > Why are the shutdown operations "deny-all"? It is nacm:default-deny-all. It means that you need an authorization rule in order to reboot/shutdown the device. /martin From bclaise@cisco.com Thu Mar 7 01:35:38 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C332A21F891C for ; Thu, 7 Mar 2013 01:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.697 X-Spam-Level: X-Spam-Status: No, score=-10.697 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ls+W8yRI63zl for ; Thu, 7 Mar 2013 01:35:38 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D1DAE21F8910 for ; Thu, 7 Mar 2013 01:35:37 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r279ZLZY018858; Thu, 7 Mar 2013 10:35:21 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r279YjL2010739; Thu, 7 Mar 2013 10:35:00 +0100 (CET) Message-ID: <51385F35.9000702@cisco.com> Date: Thu, 07 Mar 2013 10:34:45 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Lange, Jeffrey K (GE Energy Management)" , David Kessens , "netmod@ietf.org" References: <20130306000539.GG2854@nsn.com> <20130306134254.GC19899@elstar.local> In-Reply-To: <20130306134254.GC19899@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 09:35:38 -0000 On 6/03/2013 14:42, Juergen Schoenwaelder wrote: > On Wed, Mar 06, 2013 at 01:30:30PM +0000, Lange, Jeffrey K (GE Energy Management) wrote: >> This references: >> >> [I-D.lange-netmod-iana-timezones] >> Lange, J., "IANA Timezone Database YANG Module", >> draft-lange-netmod-iana-timezones-01 (work in progress), >> June 2012. >> >> Which technically "expired" Does something need to happen to bring this back from the grave? Or is this OK? > I think this is not perfect but OK for now. The document is still > available here: > > http://tools.ietf.org/html/draft-lange-netmod-iana-timezones-01 Actually, the reference should be the netmod document. http://tools.ietf.org/html/draft-ietf-netmod-iana-timezones-00. Now, the expiration issue is the same, as it expired on January 10, 2013 Regards, Benoit > > /js > From mbj@tail-f.com Thu Mar 7 01:42:47 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B6C21F8CD2 for ; Thu, 7 Mar 2013 01:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U20lTi1O6WCG for ; Thu, 7 Mar 2013 01:42:47 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 26A9B21F8CD1 for ; Thu, 7 Mar 2013 01:42:47 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A56DB12008D2; Thu, 7 Mar 2013 10:42:45 +0100 (CET) Date: Thu, 07 Mar 2013 10:42:45 +0100 (CET) Message-Id: <20130307.104245.734543211037863901.mbj@tail-f.com> To: bclaise@cisco.com From: Martin Bjorklund In-Reply-To: <51385F35.9000702@cisco.com> References: <20130306134254.GC19899@elstar.local> <51385F35.9000702@cisco.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 09:42:47 -0000 Benoit Claise wrote: > On 6/03/2013 14:42, Juergen Schoenwaelder wrote: > > On Wed, Mar 06, 2013 at 01:30:30PM +0000, Lange, Jeffrey K (GE Energy > > Management) wrote: > >> This references: > >> > >> [I-D.lange-netmod-iana-timezones] > >> Lange, J., "IANA Timezone Database YANG Module", > >> draft-lange-netmod-iana-timezones-01 (work in progress), > >> June 2012. > >> > >> Which technically "expired" Does something need to happen to bring > >> this back from the grave? Or is this OK? > > I think this is not perfect but OK for now. The document is still > > available here: > > > > http://tools.ietf.org/html/draft-lange-netmod-iana-timezones-01 > Actually, the reference should be the netmod document. > http://tools.ietf.org/html/draft-ietf-netmod-iana-timezones-00. > Now, the expiration issue is the same, as it expired on January 10, > 2013 It seems we will publish a new version of the systems draft after WGLC; at this time we can also publish a new version of draft-ietf-netmod-iana-timezones and update the reference. /martin From per@tail-f.com Thu Mar 7 08:58:06 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6A321F8A91 for ; Thu, 7 Mar 2013 08:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwYH2nyah8pi for ; Thu, 7 Mar 2013 08:58:05 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B688A21F8A7E for ; Thu, 7 Mar 2013 08:58:02 -0800 (PST) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1C53412008FC; Thu, 7 Mar 2013 17:58:01 +0100 (CET) Message-ID: <5138C719.8040808@tail-f.com> Date: Thu, 07 Mar 2013 17:58:01 +0100 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110120 Thunderbird/3.1.7 MIME-Version: 1.0 To: Martin Bjorklund References: <51374C76.8070902@tail-f.com> <201303062008.r26K8H5c006746@idle.juniper.net> <20130306.231734.295558367.mbj@tail-f.com> In-Reply-To: <20130306.231734.295558367.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 16:58:06 -0000 On 2013-03-06 23:17, Martin Bjorklund wrote: > > Phil Shafer wrote: [snip] > >> You list ntp-server (nuke the leading "ntp-") > > Agreed, will fix. > >> but not peers or boot >> servers. You are missing authentication keys, source address, >> version, polling interval constraints (min and max), broadcast server >> and client info, and multicast client info. > > We had more earlier, but have been going back and forth. See for > example > http://www.ietf.org/mail-archive/web/netmod/current/msg06529.html for > some comments. Yes - and if we are attempting to specify a standard for configuration of the "NTP reference implementation" (which I don't think we should), there are of course a huge number of other knobs that could be considered "missing", I don't know why the particular list above would be selected. The reference implementation's "peer" directive is covered by the association-type here though (the ref.impl combines the "address" and "association-type" items into a single directive). I'm guessing that "boot server" (not a concept used by the ref.impl AFAIK) is something that is supposed to be used by the (deprecated) 'ntpdate' program or the like, I can't see any reason to have separate config for that. >> 3.3: In JUNOS, we call out the local domain explicitly, distinct from >> the domain search path. This is similar to the "domain" and "search" >> fields in BSD's resolv.conf. > > In an earlier version of this model we had: > > The 'domain' keyword of /etc/resolv.conf is not supported, > since it is equivalent to 'search' with a single domain. And in BSD's (also in others I believe) resolv.conf, "domain" and "search" are mutually exclusive - AFAIK "domain" is retained only for backward compatibility, it used to imply a search list until that was found to be a security problem, and "search" was introduced to make it possible to specify the search list explicitly. >> Passwords without the leading $ are old-school style. Support them? > > Actually, they are not supported. The pattern is: > > pattern "$0$.*|$(1|5|6)$[a-zA-Z0-9./]{2,16}$.*"; I guess the question is whether we should support the original *nix DES-based password type, to which my answer is a definite "no". It was considered insufficiently resistant to brute-force attacks already back in 1995 when the MD5 type was created (and nowadays the creator of the MD5 type advices against *its* use for the same reason). --Per From phil@juniper.net Thu Mar 7 12:12:44 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E685E21F8CE0 for ; Thu, 7 Mar 2013 12:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4XKOyr4bNgs for ; Thu, 7 Mar 2013 12:12:43 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 09A1121F8991 for ; Thu, 7 Mar 2013 12:12:41 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUTj0uF4ZrpK9b4KN/Mb/WQXYLvguvcQf@postini.com; Thu, 07 Mar 2013 12:12:43 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 7 Mar 2013 12:10:30 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r27KAG346271; Thu, 7 Mar 2013 12:10:28 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id r27K9PDo013901; Thu, 7 Mar 2013 15:09:46 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201303072009.r27K9PDo013901@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20130306.231734.295558367.mbj@tail-f.com> Date: Thu, 7 Mar 2013 15:09:25 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 20:12:44 -0000 Martin Bjorklund writes: >> "administratively assigned system name" >> doesn't mean much to the average reader. >This text is copied from RFC 3418 (sysName) (which is also >referenced). Sure, but we don't need to quote the dead sea scrolls ;^) We need a description that is useful to the modern reader, not something with Old Testament language. >> 3.2: Why have use-ntp? Why not have [system ntp] a purpose container? > >As long as we don't have active/inactive (see Kent's draft), we'll see >these kinds of leafs. How about the semi-standard "enable" at least? >We had more earlier, but have been going back and forth. See for >example >http://www.ietf.org/mail-archive/web/netmod/current/msg06529.html for >some comments. If you only model the pasts of NTP that you think are useful, then someone has to make another model containing the rest of the ntp model, which seems poor style. > The 'domain' keyword of /etc/resolv.conf is not supported, > since it is equivalent to 'search' with a single domain. I'd add those words back, since they at least let the reader know it was intentional. >B/c it can contain any octets. Note that the textual representation >is base64 encoded, which happens to be a common way to represent ssh >keys. So the key-data is only the encoded bits? What do you do with the comment? Thanks, Phil From andy@yumaworks.com Thu Mar 7 12:23:41 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0051F21F8C97 for ; Thu, 7 Mar 2013 12:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-QtZPmTxUJB for ; Thu, 7 Mar 2013 12:23:39 -0800 (PST) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id D141521F8C22 for ; Thu, 7 Mar 2013 12:23:38 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id j14so762424lbo.24 for ; Thu, 07 Mar 2013 12:23:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=Uwnu8S8bu0HQAf7jI5jfsq3Sz9iOrXYSNli+Rgjpd3o=; b=K0FT8IiYvZQB2nmJNW7XBTYOUe66lWZ6olZwydujtCBJIuPoaBlpQKAgtDYOLiV3Pp AgLRNMJEfC8jhXnA3KOtUb7RCVl8jN1e3M7qwnAa/Y9fY+MEmRiYBlFByFd5+LDWxEEt HBj24ZIg0HPgygsCetuklLKp4Pb22ZPq/t2Nqq6XcjVIggBwwjFlrh3yfB/onHsuXmVc W326C9klb5JtYJOAq5mHY49gXijWwuRTlhBgtIQkjRd08sGlss/ziGOfQqqgudss/9lu jfxDy2MU+HLabI+p1q85KmVaE/hXsEioKMXc73HKbCNEKhwg2jEJf6AcyxLOhZVCkJqQ LAKQ== MIME-Version: 1.0 X-Received: by 10.112.83.67 with SMTP id o3mr83702lby.7.1362687813347; Thu, 07 Mar 2013 12:23:33 -0800 (PST) Received: by 10.112.75.233 with HTTP; Thu, 7 Mar 2013 12:23:33 -0800 (PST) In-Reply-To: <201303072009.r27K9PDo013901@idle.juniper.net> References: <20130306.231734.295558367.mbj@tail-f.com> <201303072009.r27K9PDo013901@idle.juniper.net> Date: Thu, 7 Mar 2013 12:23:33 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl+NvdITyhUls9YeeMPMSwm4WTmMjjiIOo3jea/W1wnogyJqNTppv3SgKfOfx/LlDrQTpCy Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 20:23:41 -0000 Hi, On Thu, Mar 7, 2013 at 12:09 PM, Phil Shafer wrote: > Martin Bjorklund writes: >>> "administratively assigned system name" >>> doesn't mean much to the average reader. >>This text is copied from RFC 3418 (sysName) (which is also >>referenced). > > Sure, but we don't need to quote the dead sea scrolls ;^) > We need a description that is useful to the modern reader, > not something with Old Testament language. > >>> 3.2: Why have use-ntp? Why not have [system ntp] a purpose container? >> >>As long as we don't have active/inactive (see Kent's draft), we'll see >>these kinds of leafs. > > How about the semi-standard "enable" at least? What is the semi-standard "enable"? You mean a leaf? I prefer a grouping with an enabled leaf that each module uses (instead of cut-and-paste). I prefer leafs over XML attributes because YANG must/when expressions cannot see these flags unless they are leafs in the config. > >>We had more earlier, but have been going back and forth. See for >>example >>http://www.ietf.org/mail-archive/web/netmod/current/msg06529.html for >>some comments. > > If you only model the pasts of NTP that you think are useful, > then someone has to make another model containing the rest of > the ntp model, which seems poor style. We went back and forth on this and many other issues and we intentionally minimized the set of parameters. Perhaps the NTP WG should create a data model to configure every possible parameter, but not the NETMOD WG. > >> The 'domain' keyword of /etc/resolv.conf is not supported, >> since it is equivalent to 'search' with a single domain. > > I'd add those words back, since they at least let the reader know > it was intentional. > >>B/c it can contain any octets. Note that the textual representation >>is base64 encoded, which happens to be a common way to represent ssh >>keys. > > So the key-data is only the encoded bits? What do you do with the > comment? > > Thanks, > Phil Andy From phil@juniper.net Thu Mar 7 12:27:20 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC2C21F8CC9 for ; Thu, 7 Mar 2013 12:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.632 X-Spam-Level: X-Spam-Status: No, score=-6.632 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTZejerFQts8 for ; Thu, 7 Mar 2013 12:27:20 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id BBF9321F8C22 for ; Thu, 7 Mar 2013 12:27:18 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUTj4JnWQfBbhEwSdUQcwV+5fMGtCqKBA@postini.com; Thu, 07 Mar 2013 12:27:20 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 7 Mar 2013 12:25:18 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r27KPH354929; Thu, 7 Mar 2013 12:25:18 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id r27KOQrC014037; Thu, 7 Mar 2013 15:24:47 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201303072024.r27KOQrC014037@idle.juniper.net> To: Per Hedeland In-Reply-To: <5138C719.8040808@tail-f.com> Date: Thu, 7 Mar 2013 15:24:26 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 20:27:20 -0000 Per Hedeland writes: >Yes - and if we are attempting to specify a standard for configuration >of the "NTP reference implementation" (which I don't think we should), >there are of course a huge number of other knobs that could be >considered "missing", I don't know why the particular list above would >be selected. The reference implementation's "peer" directive is covered >by the association-type here though (the ref.impl combines the "address" >and "association-type" items into a single directive). I'm guessing that >"boot server" (not a concept used by the ref.impl AFAIK) is something >that is supposed to be used by the (deprecated) 'ntpdate' program or the >like, I can't see any reason to have separate config for that. My config is based on ntp.org's ntp.conf: server address [key key | autokey] [burst] [iburst] [version version] [prefer] [minpoll minpoll] [maxpoll maxpoll] peer address [key key | autokey] [version version] [prefer] [minpoll minpoll] [maxpoll maxpoll] broadcast address [key key | autokey] [version version] [prefer] [minpoll minpoll] [ttl ttl] manycastclient address [key key | autokey] [version version] [prefer] [minpoll minpoll] [maxpoll maxpoll] [ttl ttl] but yes, there are lots of the more rare options (statistics, discard, etc) that we omit. >And in BSD's (also in others I believe) resolv.conf, "domain" and >"search" are mutually exclusive - AFAIK "domain" is retained only for >backward compatibility, it used to imply a search list until that was >found to be a security problem, and "search" was introduced to make it >possible to specify the search list explicitly. You're right. We no longer use it if search is set. Thanks, Phil From phil@juniper.net Thu Mar 7 12:51:36 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0278921F8AF8 for ; Thu, 7 Mar 2013 12:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.774 X-Spam-Level: X-Spam-Status: No, score=-6.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8WKwSUxtdLv for ; Thu, 7 Mar 2013 12:51:35 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id DCDA321F8AA6 for ; Thu, 7 Mar 2013 12:51:32 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUTj91Axovoj9a4PJKNkk7BFGn3jqQ4Gk@postini.com; Thu, 07 Mar 2013 12:51:35 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 7 Mar 2013 12:48:24 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r27KmN365865; Thu, 7 Mar 2013 12:48:23 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id r27KlMVE014278; Thu, 7 Mar 2013 15:47:42 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201303072047.r27KlMVE014278@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Thu, 7 Mar 2013 15:47:22 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 20:51:36 -0000 Andy Bierman writes: >What is the semi-standard "enable"? I thought other drafts use "enable" instead of "use-xxx", but checking shows both "enable" and "enabled". It defaults to true, which means it will only be set to "false" (explicitly anyway) so it's really more of a "disable" knob. ('leaf disable { type empty; }'?) >You mean a leaf? I prefer a grouping with an enabled leaf >that each module uses (instead of cut-and-paste). That would be fine, and that "grouping enable" could be in a standard module to everyone could include it, if that's what you're after. As it is, the names vary, the placement varies (e.g. radius cannot be disabled, nor can specific ntp servers), and it makes must/when expressions fragile and/or complex. It would be nice to have a single, simple means of enabling and disabling config hierarchies. >We went back and forth on this and many other issues >and we intentionally minimized the set of parameters. >Perhaps the NTP WG should create a data model to configure >every possible parameter, but not the NETMOD WG. Perhaps this should be captured in the document so the reader understands that you are not fully modeling these technologies, but only aiming for the more commonly used features. Thanks, Phil From david.kessens@nsn.com Thu Mar 7 13:29:10 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1CB21F8549 for ; Thu, 7 Mar 2013 13:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L259AOtfikmO for ; Thu, 7 Mar 2013 13:29:09 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5B621F842C for ; Thu, 7 Mar 2013 13:29:06 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r27LSu41012032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Mar 2013 22:28:57 +0100 Received: from localhost.localdomain ([10.138.48.137]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r27LStrG005619; Thu, 7 Mar 2013 22:28:56 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.5/8.14.5) with ESMTP id r27LSsgv030950; Thu, 7 Mar 2013 13:28:54 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.5/8.14.5/Submit) id r27LSpY8030948; Thu, 7 Mar 2013 13:28:51 -0800 Date: Thu, 7 Mar 2013 13:28:51 -0800 From: David Kessens To: Phil Shafer Message-ID: <20130307212851.GY2854@nsn.com> References: <20130306.231734.295558367.mbj@tail-f.com> <201303072009.r27K9PDo013901@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201303072009.r27K9PDo013901@idle.juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 703 X-purgate-ID: 151667::1362691737-0000547A-86C0F71F/0-0/0-0 Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 21:29:10 -0000 Phil, On Thu, Mar 07, 2013 at 03:09:25PM -0500, Phil Shafer wrote: > > >We had more earlier, but have been going back and forth. See for > >example > >http://www.ietf.org/mail-archive/web/netmod/current/msg06529.html for > >some comments. > > If you only model the pasts of NTP that you think are useful, > then someone has to make another model containing the rest of > the ntp model, which seems poor style. The intention of the system model was to cover 90% of cases. More specific data models can be worked on later. It's a judgement call what is 90% and what is the other 10%, but it surely is not needed to support every option/feature under the sun. David Kessens --- From mbj@tail-f.com Thu Mar 7 13:31:53 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A3F21F8B1C for ; Thu, 7 Mar 2013 13:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aBd0Vgd7dkw for ; Thu, 7 Mar 2013 13:31:53 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 119F221F8B16 for ; Thu, 7 Mar 2013 13:31:53 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 1756C12008D2; Thu, 7 Mar 2013 22:31:52 +0100 (CET) Date: Thu, 07 Mar 2013 22:31:51 +0100 (CET) Message-Id: <20130307.223151.270378568.mbj@tail-f.com> To: david.kessens@nsn.com From: Martin Bjorklund In-Reply-To: <20130307212851.GY2854@nsn.com> References: <20130306.231734.295558367.mbj@tail-f.com> <201303072009.r27K9PDo013901@idle.juniper.net> <20130307212851.GY2854@nsn.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 21:31:53 -0000 David Kessens wrote: > > Phil, > > On Thu, Mar 07, 2013 at 03:09:25PM -0500, Phil Shafer wrote: > > > > >We had more earlier, but have been going back and forth. See for > > >example > > >http://www.ietf.org/mail-archive/web/netmod/current/msg06529.html for > > >some comments. > > > > If you only model the pasts of NTP that you think are useful, > > then someone has to make another model containing the rest of > > the ntp model, which seems poor style. > > The intention of the system model was to cover 90% of cases. Right; and to further clarify - 90% of the *use cases*, not 90% of the potential parameters. /martin From mbj@tail-f.com Fri Mar 8 02:12:27 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4837A21F8628 for ; Fri, 8 Mar 2013 02:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tT+3IeXIUx0s for ; Fri, 8 Mar 2013 02:12:26 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7BD21F8545 for ; Fri, 8 Mar 2013 02:12:26 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id D937E12008FC; Fri, 8 Mar 2013 11:12:24 +0100 (CET) Date: Fri, 08 Mar 2013 11:12:24 +0100 (CET) Message-Id: <20130308.111224.1340322135392779942.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201303072047.r27KlMVE014278@idle.juniper.net> References: <201303072047.r27KlMVE014278@idle.juniper.net> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 10:12:27 -0000 Phil Shafer wrote: > Andy Bierman writes: > >What is the semi-standard "enable"? > > I thought other drafts use "enable" instead of "use-xxx", but > checking shows both "enable" and "enabled". It defaults to true, > which means it will only be set to "false" (explicitly anyway) so > it's really more of a "disable" knob. ('leaf disable { type empty; }'?) I am all for consistency. I cannot find other drafts using "enable", and personally I think it is a bit weird to have a verb in the config. So I prefer to have "leaf enabled". > >You mean a leaf? I prefer a grouping with an enabled leaf > >that each module uses (instead of cut-and-paste). > > That would be fine, and that "grouping enable" could be in a standard > module to everyone could include it, if that's what you're after. +1 But where do we put it...? In 6021bis? (ietf-yang-types). /martin From j.schoenwaelder@jacobs-university.de Fri Mar 8 02:53:15 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA03021F862D for ; Fri, 8 Mar 2013 02:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.105 X-Spam-Level: X-Spam-Status: No, score=-103.105 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oC3TW8R-nmrV for ; Fri, 8 Mar 2013 02:53:11 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6011F21F84C8 for ; Fri, 8 Mar 2013 02:53:11 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7241A20BF8; Fri, 8 Mar 2013 11:53: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 kAgHG1zUsWOL; Fri, 8 Mar 2013 11:53:10 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B75B20BF7; Fri, 8 Mar 2013 11:53:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DCB9D24E173E; Fri, 8 Mar 2013 11:53:20 +0100 (CET) Date: Fri, 8 Mar 2013 11:53:20 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20130308105320.GA49578@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] snmp cfg tls X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 10:53:15 -0000 Hi, here are some comments on the submodule ietf-snmp-tls: - should the leafs id and fingerprint have a description? - should the leafs fingerprint and map-type be mandatory? - what about renaming the leaf cert-specified-tm-security-name to simply 'security-name'? - what is the snmpTlstmCertToTSNData column referred to in the description of map-type? I mean, other than for the specified security name case, can this ever happen? Sure, in MIB space, someone could invent something magic - but do we take care about this at this config interface? - should the mapping identities have description clauses that explain what these identities do? I have similiar questions for the corresponding NETCONF over TLS definitions. Perhaps we should sit down next week and make them both consistent doing the right thing... ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From per@tail-f.com Fri Mar 8 02:54:07 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D74E21F84F3 for ; Fri, 8 Mar 2013 02:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLedLTNNwZyK for ; Fri, 8 Mar 2013 02:54:03 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1763221F84F1 for ; Fri, 8 Mar 2013 02:54:03 -0800 (PST) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3E7B612008FC; Fri, 8 Mar 2013 11:54:02 +0100 (CET) Message-ID: <5139C34A.4040609@tail-f.com> Date: Fri, 08 Mar 2013 11:54:02 +0100 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110120 Thunderbird/3.1.7 MIME-Version: 1.0 To: Phil Shafer References: <201303072024.r27KOQrC014037@idle.juniper.net> In-Reply-To: <201303072024.r27KOQrC014037@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 10:54:07 -0000 On 2013-03-07 21:24, Phil Shafer wrote: > > My config is based on ntp.org's ntp.conf: Well, ntp.org provides documentation for the "reference implementation" - the point I tried to make in the earlier discussion is that there are viable alternative implementations. Some of them may even be considered preferrable in some deployments, but they surely do not come with as many knobs, maybe not even a subset that is identical. I.e. I believe a standard model should be implementation-independant as far as possible, and I think the current model mostly fulfills that. --Per From lhotka@nic.cz Fri Mar 8 07:30:11 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267D321F85DB for ; Fri, 8 Mar 2013 07:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZJibH29CnRm for ; Fri, 8 Mar 2013 07:30:10 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3043821F85DA for ; Fri, 8 Mar 2013 07:30:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 983395405FE for ; Fri, 8 Mar 2013 16:30:03 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAQSu88LKE6W for ; Fri, 8 Mar 2013 16:29:48 +0100 (CET) Received: from localhost (89-24-17-160.i4g.tmcz.cz [89.24.17.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 51ABA540042 for ; Fri, 8 Mar 2013 16:29:34 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <20130306.231734.295558367.mbj@tail-f.com> <201303072009.r27K9PDo013901@idle.juniper.net> User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Fri, 08 Mar 2013 16:29:29 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 15:30:11 -0000 Andy Bierman writes: >> >> How about the semi-standard "enable" at least? > > What is the semi-standard "enable"? > You mean a leaf? I prefer a grouping with an enabled leaf > that each module uses (instead of cut-and-paste). > I prefer leafs over XML attributes because YANG must/when > expressions cannot see these flags unless they are leafs > in the config. I agree. Whilst such a meta-flag would be nice, the "collateral damage" would IMO be just too high. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Fri Mar 8 07:49:12 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2CF21F84C8 for ; Fri, 8 Mar 2013 07:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BbrHdDTvHyq for ; Fri, 8 Mar 2013 07:49:11 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id CE82F21F84C1 for ; Fri, 8 Mar 2013 07:49:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id CC85C5405FE; Fri, 8 Mar 2013 16:49:09 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9znQiZrJy7m; Fri, 8 Mar 2013 16:49:00 +0100 (CET) Received: from localhost (89-24-17-160.i4g.tmcz.cz [89.24.17.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 189A9540042; Fri, 8 Mar 2013 16:48:58 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer , Andy Bierman In-Reply-To: <201303072047.r27KlMVE014278@idle.juniper.net> References: <201303072047.r27KlMVE014278@idle.juniper.net> User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Phil Shafer , Andy Bierman , netmod@ietf.org Date: Fri, 08 Mar 2013 16:48:54 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 15:49:12 -0000 Phil Shafer writes: > Andy Bierman writes: >>What is the semi-standard "enable"? > > I thought other drafts use "enable" instead of "use-xxx", but > checking shows both "enable" and "enabled". It defaults to true, > which means it will only be set to "false" (explicitly anyway) so > it's really more of a "disable" knob. ('leaf disable { type empty; }'?) > We had this discussion before, see this thread: http://www.ietf.org/mail-archive/web/netmod/current/msg06032.html I was, and still am, slightly in favour of . If we end up changing all the "enabled" flags into "uses", we should reconsider the pros and cons of leaf enabled { type boolean; default true; } versus leaf disabled { type empty; } because this leaf will be pretty ubiquitous. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From per@tail-f.com Fri Mar 8 07:49:37 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0E821F874B for ; Fri, 8 Mar 2013 07:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cw6K-SbiqtNz for ; Fri, 8 Mar 2013 07:49:36 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 51F8721F8585 for ; Fri, 8 Mar 2013 07:49:36 -0800 (PST) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id B96091200D5B for ; Fri, 8 Mar 2013 16:49:34 +0100 (CET) Message-ID: <513A088E.3020801@tail-f.com> Date: Fri, 08 Mar 2013 16:49:34 +0100 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110120 Thunderbird/3.1.7 MIME-Version: 1.0 To: netmod@ietf.org References: <20130306000539.GG2854@nsn.com> <51374C76.8070902@tail-f.com> In-Reply-To: <51374C76.8070902@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 15:49:37 -0000 Some potentially reasonable answers to my own questions below... On 2013-03-06 15:02, Per Hedeland wrote: > > 1. Is it a problem that there is no "real" specification of the > algorithms used for the hashing? I.e. not MD5/SHA, but how they are > applied. I don't think so, but perhaps the text could make it clear that there is more to the implementation than the choice of MD5/SHA-256/SHA-512: OLD: "The crypt-hash type is used to store passwords using a hash function. This type is implemented in various UNIX systems as the function crypt(3). NEW: "The crypt-hash type is used to store passwords using a hash function. The algorithms for applying the hash function and encoding the result are implemented in various UNIX systems as the function crypt(3). > 2. If "implementation-defined" is the answer to 1, ... It isn't. > 3. The "reference implementations" of type 5 and 6 allow for an > additional 'rounds' parameter with a value in the range > 1000 .. 999999999 (default is 5000), i.e. the "hashed value" can be e.g. > "$5$rounds=10000$saltstringsaltst$3xv.VbSHBb41AL9AvLeujZkZRBAwqFMz2.". > This is not allowed by the pattern in the typedef - should it be? I think it should be allowed - the freely available implementations of the hashing algorithms that are likely to be used in deployment already support this parameter, and even if it is not currently used for initial creation of hashed passwords on the relevant Unices, it is a simple way to increase the computational cost of hashing when needed. I thus suggest that the pattern be modified as follows, which also includes a more precise (and perhaps more readable) specification: OLD: pattern "$0$.*|$(1|5|6)$[a-zA-Z0-9./]{2,16}$.*"; NEW: pattern "$0$.*|" + "$1$[a-zA-Z0-9./]{1,8}$[a-zA-Z0-9./]{22}|" + "$5$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{43}|" + "$6$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{86}"; and OLD: A value of this type matches one of the forms: $0$ $$$ The '$0$' prefix signals that the value is clear text. When such a value is received by the server, a hash value is calculated, and the string '$$$' is prepended to the result, where is a random 2-16 characters long salt used to generate the digest. This value is stored in the configuration data store. If a value starting with '$$$' is received NEW: A value of this type matches one of the forms: $0$ $$$ $$$$ The '$0$' prefix signals that the value is clear text. When such a value is received by the server, a hash value is calculated, and the string '$$$' or $$$$ is prepended to the result. This value is stored in the configuration data store. If a value starting with '$$', where is not '0', is received (I.e. I'm dropping the elaboration on , and not adding anything for - that info has no use anyway if you don't know the exact algorithm.) > 4. Should there be some text about how a server chooses between the > algorithms when hashing a cleartext password (assuming it supports more > than one, of course)? Leaving it out is probably a good enough way of saying "implementation dependant". --Per From andy@yumaworks.com Fri Mar 8 07:54:10 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D85A21F85CC for ; Fri, 8 Mar 2013 07:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOSxqkzvMCJs for ; Fri, 8 Mar 2013 07:54:09 -0800 (PST) Received: from mail-ia0-x231.google.com (mail-ia0-x231.google.com [IPv6:2607:f8b0:4001:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id BDF0521F85AF for ; Fri, 8 Mar 2013 07:54:09 -0800 (PST) Received: by mail-ia0-f177.google.com with SMTP id y25so1628966iay.36 for ; Fri, 08 Mar 2013 07:54:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=8WsUDKlWPipiSPK3YLMQ5OJfzDzZRILcIyTus3veg6o=; b=Nwnoxq9l5Otj79+kJWjB3LcovFEVvSrz336xiEemidGamXaPn5V0+SMvtVlq8LaYtV pAn62+StWpihBD88qMjnHFUqvYjRJNNs0iYsqlybrEJx0b1SCCKDegKIUxvqGMYmN82q bcH9vtVvEb7mGqfH41O+uo3U2xYafmHaTJaSff9Fhdzh3NEu2RY5XdK16/xp0AN/bEGt lYE7ZEiJR0sUX1/XoJJAGvjR8obNWLi4x2olK+y2Fq7GZZQzDUme8nvBJO+Tv4ZIRMqs ainNUEhdiPMxI1mz2iPhVBdztN1bLIjtiuDKvXffot9C6NBGY1Y9WbVmbu+AQogxiI5b U/bg== MIME-Version: 1.0 X-Received: by 10.50.37.239 with SMTP id b15mr2082597igk.69.1362758049200; Fri, 08 Mar 2013 07:54:09 -0800 (PST) Received: by 10.231.93.6 with HTTP; Fri, 8 Mar 2013 07:54:09 -0800 (PST) In-Reply-To: References: <20130306.231734.295558367.mbj@tail-f.com> <201303072009.r27K9PDo013901@idle.juniper.net> Date: Fri, 8 Mar 2013 07:54:09 -0800 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmjiIuZTB6XsIktizIcuzaEu16QgdgSh3cXlyfuyyGHHs0VVqaI3GG8/TLrUqQhZF9t/gaR Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 15:54:10 -0000 On Fri, Mar 8, 2013 at 7:29 AM, Ladislav Lhotka wrote: > Andy Bierman writes: >>> >>> How about the semi-standard "enable" at least? >> >> What is the semi-standard "enable"? >> You mean a leaf? I prefer a grouping with an enabled leaf >> that each module uses (instead of cut-and-paste). >> I prefer leafs over XML attributes because YANG must/when >> expressions cannot see these flags unless they are leafs >> in the config. > > I agree. Whilst such a meta-flag would be nice, the "collateral damage" would IMO be just too high. > IMO, this is a high priority use-case for must/when. Machine-readable dependency mappings help automation tools. Unfortunately, the operator "enabled" property isn't the only use-case. We get a lot of requests to make false conditional subtrees "come back" once the condition is true again (when, choice-stmt). A standard to do that would really help. I2RS seems to want subtrees saved for each client application, and some sort of priority/scheduling algorithm decides which one is active. The YANG when and choice statements cause the false conditional nodes to be deleted and forgotten. The key feature of Kent's draft that we seem to be over-looking is that he attempts to solve this important CM problem. We may differ on the details but whatever we call this feature (operational state?) it is a high-priority problem. > Lada Andy From per@tail-f.com Fri Mar 8 08:51:55 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C83321F84F1 for ; Fri, 8 Mar 2013 08:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sRQmeHQOT+N for ; Fri, 8 Mar 2013 08:51:53 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2377921F87C3 for ; Fri, 8 Mar 2013 08:51:52 -0800 (PST) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3EEEC1200D64 for ; Fri, 8 Mar 2013 17:51:51 +0100 (CET) Message-ID: <513A1726.1060009@tail-f.com> Date: Fri, 08 Mar 2013 17:51:50 +0100 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110120 Thunderbird/3.1.7 MIME-Version: 1.0 To: netmod@ietf.org References: <20130306000539.GG2854@nsn.com> <51374C76.8070902@tail-f.com> <513A088E.3020801@tail-f.com> In-Reply-To: <513A088E.3020801@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 16:51:55 -0000 Prompted by Phil to scrutinize the NTP section in more detail, I'll also propose the text change below - the existing text is not quite correct, and I suspect that users may wonder about the point of configuring a server that the device is not expected to "synchronize with".:-) OLD: enum server { description "Use server association mode. This device is not expected to synchronize with the configured NTP server."; } enum peer { description "Use peer association mode. This device may be expected to synchronize with the configured NTP server."; } enum pool { description "Use pool association mode. This device is not expected to synchronize with the configured NTP server."; } NEW: enum server { description "Use client association mode. This device will not provide synchronization to the configured NTP server."; } enum peer { description "Use symmetric active association mode. This device may provide synchronization to the configured NTP server."; } enum pool { description "Use client association mode with one or more of the NTP servers found by DNS resolution of the domain name given by the 'address' leaf. This device will not provide synchronization to the servers."; } --Per From B.Hedstrom@CableLabs.com Fri Mar 8 10:21:11 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C306E21F874C for ; Fri, 8 Mar 2013 10:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJruXGT2EYhL for ; Fri, 8 Mar 2013 10:21:11 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD7D21F8697 for ; Fri, 8 Mar 2013 10:21:11 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r28ILAxA005497 for ; Fri, 8 Mar 2013 11:21:10 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Fri, 08 Mar 2013 11:21:10 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.02.0328.009; Fri, 8 Mar 2013 11:21:08 -0700 From: Brian Hedstrom To: "netmod@ietf.org" Thread-Topic: draft-ietf-netmod-interfaces-cfg-09.txt Thread-Index: AQHOHCmz49juoIExfE25Dx6zH7AJcg== Date: Fri, 8 Mar 2013 18:21:07 +0000 Message-ID: <686B406F73B0F245AB30195F4E80E2D517F24489@EXCHANGE.cablelabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.5.0.27] Content-Type: multipart/alternative; boundary="_000_686B406F73B0F245AB30195F4E80E2D517F24489EXCHANGEcablela_" MIME-Version: 1.0 X-Approved: ondar Subject: [netmod] draft-ietf-netmod-interfaces-cfg-09.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 18:21:11 -0000 --_000_686B406F73B0F245AB30195F4E80E2D517F24489EXCHANGEcablela_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Question/Comment on this draft. Any consideration on adding a small sectio= n, such as below, that highlights the Relationship to the ENTITY-MIB? 4. Relationship to the IF-MIB . . . . . . . . . . . . . . . . . . 8 I'm looking at a use case where a Power Distribution Unit (PDU) is modeled = in the ENTITY-MIB as 1 or more energy objects in the IANAPhysicalClass. Ho= wever this provides modeling at the physical device level, for power measur= ement/metering in the example. If I wanted to dive deeper and model indivi= dual power/energy interfaces for the PDU which are connected to individual = networked components, Then I have a linkage, or UML Class diagram, or YANG = relationship between the ENTITY-MIB and the IF-MIB (or this draft). Could = this relationship/association be explained in a section? Thanks, Brian Hedstrom Senior Architect, Business & Operational Support Systems CableLabs, Inc. 858 Coal Creek Circle Louisville, CO 80027 Direct: 303.661.3829 eFax: 303.664.8120 Google+: brian.hedstrom Skype IM: brian.hedstrom b.hedstrom@cablelabs.com --_000_686B406F73B0F245AB30195F4E80E2D517F24489EXCHANGEcablela_ Content-Type: text/html; charset="us-ascii" Content-ID: <7059B6A4B59AB241B0B2620E90C8D2DE@cablelabs.com> Content-Transfer-Encoding: quoted-printable
Question/Comment on this draft.  Any consideration on adding a sm= all section, such as below, that highlights the Relationship to the ENTITY-= MIB?
4.  Relations=
hip to the IF-MIB . . . . . . . . . . . . . . . . . .  8
I'm looking a=
t a use case where a Power Distribution Unit (PDU) is modeled in the ENTITY=
-MIB as 1 or more energy objects in the IANAPhysicalClass.  However this pr=
ovides modeling at the physical device level, for power measurement/meterin=
g in the example.  If I wanted to dive deeper and model individual power/en=
ergy interfaces for the PDU which are connected to individual networked com=
ponents, Then I have a linkage, or UML Class diagram, or YANG relationship =
between the ENTITY-MIB and the IF-MIB (or this draft).  Could this relation=
ship/association be explained in a section?

Thanks,

Brian Hedstrom
Senior Architect, Business & Operational Support Systems
CableLabs, Inc.
858 Coal Creek Circle
Louisville, CO 80027
Direct: 303.661.3829
eFax: 303.664.8120
Google+: brian.hedstrom
Skype IM: brian.hedstrom 
b.hedstrom@cablelabs.com=

References: <686B406F73B0F245AB30195F4E80E2D517F24489@EXCHANGE.cablelabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <686B406F73B0F245AB30195F4E80E2D517F24489@EXCHANGE.cablelabs.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 18:37:45 -0000 On Fri, Mar 08, 2013 at 06:21:07PM +0000, Brian Hedstrom wrote: > Question/Comment on this draft. Any consideration on adding a small section, such as below, that highlights the Relationship to the ENTITY-MIB? > > 4. Relationship to the IF-MIB . . . . . . . . . . . . . . . . . . 8 > > I'm looking at a use case where a Power Distribution Unit (PDU) is modeled in the ENTITY-MIB as 1 or more energy objects in the IANAPhysicalClass. However this provides modeling at the physical device level, for power measurement/metering in the example. If I wanted to dive deeper and model individual power/energy interfaces for the PDU which are connected to individual networked components, Then I have a linkage, or UML Class diagram, or YANG relationship between the ENTITY-MIB and the IF-MIB (or this draft). Could this relationship/association be explained in a section? > I fail to understand. Nor do I see anything in the text that clarifies something defined by draft-ietf-netmod-interfaces-cfg-09.txt. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Fri Mar 8 10:55:18 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A2121F8842 for ; Fri, 8 Mar 2013 10:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYFFt4X88k4k for ; Fri, 8 Mar 2013 10:55:18 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id EE5C621F8514 for ; Fri, 8 Mar 2013 10:55:17 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id fs13so1973134lab.8 for ; Fri, 08 Mar 2013 10:55:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=n8bxseKqesiWL3Y4z/Fvc8BzEi0uZ/JgCreR2z3LJ3w=; b=b5AcxRY9G9ZcCKn06PNjxZ8T5x8ZfrXDcsqjnz88SQveKC9ChbIUcJvkMrLkzGZvCz g4BMj2O61BEfvT98PJ/ifUrGpQ2CVqTYTRL/SUqGB9imC1u28OUhgbvX1JJC1TjK2PCs StcKFU+H6PQq1fQnVD4IgOC6tj5WKlzXR1aLSQM26auCAGADwoU/mARYOyvMTFvxs2TU Kz55kncpS33QAK0S1jqTLYBAmGbVxH8Rd2bPkcjQC2pV0lx8n7QirEu7j/8A3csTGlzM hg1Pmk75SUEvpjTCQT038mvQaYvHCElzLDcDQgG5OGsktBsjNkXCmVi+Xdw2bfHR5tlF Sh2w== MIME-Version: 1.0 X-Received: by 10.112.16.137 with SMTP id g9mr1420470lbd.119.1362768916685; Fri, 08 Mar 2013 10:55:16 -0800 (PST) Received: by 10.112.75.233 with HTTP; Fri, 8 Mar 2013 10:55:16 -0800 (PST) In-Reply-To: <513A1726.1060009@tail-f.com> References: <20130306000539.GG2854@nsn.com> <51374C76.8070902@tail-f.com> <513A088E.3020801@tail-f.com> <513A1726.1060009@tail-f.com> Date: Fri, 8 Mar 2013 10:55:16 -0800 Message-ID: From: Andy Bierman To: Per Hedeland Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQm641hi61UQ/lEYizbtzEKTs1F/lnEs7pbSgKLC5TGP1tWuMF86aKV9u4AcvnsEMc3BlGf+ Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 18:55:18 -0000 Hi, Thanks for the review and the clarifications. I don't have any objections to these changes. In order to save time in Orlando, it would be good to know what edit requests are considered contentious and which are not. It would help if people looked over your earlier email and the 1 from Phil, and send comments to the mailing list. Andy On Fri, Mar 8, 2013 at 8:51 AM, Per Hedeland wrote: > > Prompted by Phil to scrutinize the NTP section in more detail, I'll also > propose the text change below - the existing text is not quite correct, > and I suspect that users may wonder about the point of configuring a > server that the device is not expected to "synchronize with".:-) > > OLD: > enum server { > description > "Use server association mode. This device > is not expected to synchronize with the > configured NTP server."; > } > enum peer { > description > "Use peer association mode. This device > may be expected to synchronize with the > configured NTP server."; > } > enum pool { > description > "Use pool association mode. This device > is not expected to synchronize with the > configured NTP server."; > } > > NEW: > enum server { > description > "Use client association mode. This device > will not provide synchronization to the > configured NTP server."; > } > enum peer { > description > "Use symmetric active association mode. > This device may provide synchronization > to the configured NTP server."; > } > enum pool { > description > "Use client association mode with one or > more of the NTP servers found by DNS > resolution of the domain name given by > the 'address' leaf. This device will not > provide synchronization to the servers."; > } > > --Per > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From B.Hedstrom@CableLabs.com Fri Mar 8 13:47:22 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3250B21F8765 for ; Fri, 8 Mar 2013 13:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yeASwdeaymy for ; Fri, 8 Mar 2013 13:47:21 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD4A21F863B for ; Fri, 8 Mar 2013 13:47:21 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r28LlJa8028440; Fri, 8 Mar 2013 14:47:19 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Fri, 08 Mar 2013 14:47:19 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.02.0328.009; Fri, 8 Mar 2013 14:47:18 -0700 From: Brian Hedstrom To: Juergen Schoenwaelder Thread-Topic: [netmod] draft-ietf-netmod-interfaces-cfg-09.txt Thread-Index: AQHOHCmz49juoIExfE25Dx6zH7AJcpiclRaA//+/noA= Date: Fri, 8 Mar 2013 21:47:17 +0000 Message-ID: <686B406F73B0F245AB30195F4E80E2D517F24B5F@EXCHANGE.cablelabs.com> In-Reply-To: <20130308183749.GA51119@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8B74958D62A30449B81147FB35118902@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 21:47:22 -0000 At a higher level, how are we getting the ENTITY-MIB and IF-MIB relationships modeled in YANG? For a specific example, how do we model the entAliasMappingTable relationships of logical entities to physical components, or in my example below, a physical power interface to a physical power device. Then, how can we model the reverse relationship, or at least document it at the other end? (Physical Device to interface and interface to Physical Device). If I want to provision the Serial number and AssetId of the Power Device and then provision the LinkUpDownTrapEnabled and Enabled attributes of the Power interface (or all the power interfaces) on that Power Device=8A Thanks, Brian Hedstrom Senior Architect, Business & Operational Support Systems CableLabs, Inc. 858 Coal Creek Circle Louisville, CO 80027 Direct: 303.661.3829 eFax: 303.664.8120 Google+: brian.hedstrom Skype IM: brian.hedstrom b.hedstrom@cablelabs.com =20 On 3/8/13 11:37 AM, "Juergen Schoenwaelder" wrote: >On Fri, Mar 08, 2013 at 06:21:07PM +0000, Brian Hedstrom wrote: >> Question/Comment on this draft. Any consideration on adding a small >>section, such as below, that highlights the Relationship to the >>ENTITY-MIB? >>=20 >> 4. Relationship to the IF-MIB . . . . . . . . . . . . . . . . . . 8 >>=20 >> I'm looking at a use case where a Power Distribution Unit (PDU) is >>modeled in the ENTITY-MIB as 1 or more energy objects in the >>IANAPhysicalClass. However this provides modeling at the physical >>device level, for power measurement/metering in the example. If I >>wanted to dive deeper and model individual power/energy interfaces for >>the PDU which are connected to individual networked components, Then I >>have a linkage, or UML Class diagram, or YANG relationship between the >>ENTITY-MIB and the IF-MIB (or this draft). Could this >>relationship/association be explained in a section? >>=20 > >I fail to understand. Nor do I see anything in the text that clarifies >something defined by draft-ietf-netmod-interfaces-cfg-09.txt. > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Mar 8 23:25:01 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B278D21F8517 for ; Fri, 8 Mar 2013 23:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.131 X-Spam-Level: X-Spam-Status: No, score=-103.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5jG18CkoVzC for ; Fri, 8 Mar 2013 23:25:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6B06121F8514 for ; Fri, 8 Mar 2013 23:24:59 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 57E3620BE0; Sat, 9 Mar 2013 08:24:58 +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 vt2jQ2BCz7ld; Sat, 9 Mar 2013 08:24:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B57B12078C; Sat, 9 Mar 2013 08:24:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0B00324E2C48; Sat, 9 Mar 2013 08:25:06 +0100 (CET) Date: Sat, 9 Mar 2013 08:25:06 +0100 From: Juergen Schoenwaelder To: Brian Hedstrom Message-ID: <20130309072506.GA53113@elstar.local> Mail-Followup-To: Brian Hedstrom , "netmod@ietf.org" References: <20130308183749.GA51119@elstar.local> <686B406F73B0F245AB30195F4E80E2D517F24B5F@EXCHANGE.cablelabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <686B406F73B0F245AB30195F4E80E2D517F24B5F@EXCHANGE.cablelabs.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 07:25:01 -0000 Brian, as of now, there is no ENTITY-MIB equivalent in YANG (except the automatic translation following RFC 6643). /js On Fri, Mar 08, 2013 at 09:47:17PM +0000, Brian Hedstrom wrote: > At a higher level, how are we getting the ENTITY-MIB and IF-MIB > relationships modeled in YANG? > > For a specific example, how do we model the entAliasMappingTable > relationships of logical entities to physical components, or in my example > below, a physical power interface to a physical power device. Then, how > can we model the reverse relationship, or at least document it at the > other end? (Physical Device to interface and interface to Physical Device). > > If I want to provision the Serial number and AssetId of the Power Device > and then provision the LinkUpDownTrapEnabled and Enabled attributes of the > Power interface (or all the power interfaces) on that Power DeviceÅ  > > Thanks, > > > Brian Hedstrom > Senior Architect, Business & Operational Support Systems > CableLabs, Inc. > 858 Coal Creek Circle > Louisville, CO 80027 > Direct: 303.661.3829 > eFax: 303.664.8120 > Google+: brian.hedstrom > Skype IM: brian.hedstrom > b.hedstrom@cablelabs.com > > > > > > > > On 3/8/13 11:37 AM, "Juergen Schoenwaelder" > wrote: > > >On Fri, Mar 08, 2013 at 06:21:07PM +0000, Brian Hedstrom wrote: > >> Question/Comment on this draft. Any consideration on adding a small > >>section, such as below, that highlights the Relationship to the > >>ENTITY-MIB? > >> > >> 4. Relationship to the IF-MIB . . . . . . . . . . . . . . . . . . 8 > >> > >> I'm looking at a use case where a Power Distribution Unit (PDU) is > >>modeled in the ENTITY-MIB as 1 or more energy objects in the > >>IANAPhysicalClass. However this provides modeling at the physical > >>device level, for power measurement/metering in the example. If I > >>wanted to dive deeper and model individual power/energy interfaces for > >>the PDU which are connected to individual networked components, Then I > >>have a linkage, or UML Class diagram, or YANG relationship between the > >>ENTITY-MIB and the IF-MIB (or this draft). Could this > >>relationship/association be explained in a section? > >> > > > >I fail to understand. Nor do I see anything in the text that clarifies > >something defined by draft-ietf-netmod-interfaces-cfg-09.txt. > > > >/js > > > >-- > >Juergen Schoenwaelder Jacobs University Bremen gGmbH > >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > >Fax: +49 421 200 3103 > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Sat Mar 9 04:19:35 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84F721F84D5 for ; Sat, 9 Mar 2013 04:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.407 X-Spam-Level: X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U87WlhvIJ-wa for ; Sat, 9 Mar 2013 04:19:35 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 48AA121F85E7 for ; Sat, 9 Mar 2013 04:19:35 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUTso1judsefD0dQS1aPTebjsWB5PJUTv@postini.com; Sat, 09 Mar 2013 04:19:35 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 9 Mar 2013 04:06:14 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Sat, 9 Mar 2013 04:06:13 -0800 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.188) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 9 Mar 2013 04:15:37 -0800 Received: from mail160-co1-R.bigfish.com (10.243.78.232) by CO1EHSOBE029.bigfish.com (10.243.66.94) with Microsoft SMTP Server id 14.1.225.23; Sat, 9 Mar 2013 12:06:13 +0000 Received: from mail160-co1 (localhost [127.0.0.1]) by mail160-co1-R.bigfish.com (Postfix) with ESMTP id 0E6C7800319 for ; Sat, 9 Mar 2013 12:06:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.241.149; KIP:(null); UIP:(null); (null); H:BL2PRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -4 X-BigFish: PS-4(zzbb2dI98dI9371I4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275bhz2dh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h) Received: from mail160-co1 (localhost.localdomain [127.0.0.1]) by mail160-co1 (MessageSwitch) id 1362830771105786_24329; Sat, 9 Mar 2013 12:06:11 +0000 (UTC) Received: from CO1EHSMHS023.bigfish.com (unknown [10.243.78.237]) by mail160-co1.bigfish.com (Postfix) with ESMTP id 0D6E0A00063; Sat, 9 Mar 2013 12:06:11 +0000 (UTC) Received: from BL2PRD0511HT002.namprd05.prod.outlook.com (157.56.241.149) by CO1EHSMHS023.bigfish.com (10.243.66.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 9 Mar 2013 12:06:10 +0000 Received: from BL2PRD0511MB397.namprd05.prod.outlook.com ([169.254.9.189]) by BL2PRD0511HT002.namprd05.prod.outlook.com ([10.255.131.37]) with mapi id 14.16.0275.006; Sat, 9 Mar 2013 12:06:09 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: conditional enablement (was: Last Call draft-ietf-netmod-system-mgmt-05) Thread-Index: AQHOHL58ZBF/BynO+0OGsWzH/Ce4Og== Date: Sat, 9 Mar 2013 12:06:09 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.255.131.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%YUMAWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "netmod@ietf.org" Subject: [netmod] conditional enablement (was: Last Call draft-ietf-netmod-system-mgmt-05) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 12:19:36 -0000 On 3/7/13 3:23 PM, "Andy Bierman" wrote: >I prefer leafs over XML attributes because YANG must/when >expressions cannot see these flags unless they are leafs >in the config. Though likely moot, why wouldn't this work? when "/system/foobar[@enabled =3D 'true']" when "not /system/foobar[@disabled]" At least XPath supports selection based on attribute values... Regardless, the reason why it's likely moot is because I think it'd be crazy to use must/when expressions to support conditional enablement, but my perspective assumes what can be disabled is selected by NETCONF-client (not the data-modeler). My view (and that implemented by JUNOS) is that conditional enablement is a cross-cutting feature - it is as if the attribute is implicitly defined on *every* node in the tree. It is presumed that config-validation conceptually occurs after stripping out all the disabled nodes, for instance via a XLST script. If we didn't assume these nodes were conceptually removed from the config before evaluation, then the must/when expressions would need to be literally everywhere, which doesn't fly. The other view would restrict what can be disabled to selections chosen by the original data-modeler - this WG for instance. However, all examples to date of how we have used flags to disable nodes have been at the "feature" level (e.g. use-ntp), but have we considered that maybe the customer doesn't want to disable the NTP service as a whole, but instead they want to disable just a specific ntp-server? To compound things more, my draft attempts to not restrict disabling a node to a static constant (true/false), but to allow disablement based on an expression (e.g. temporal). While it remains to be seen how this is resolved, it's clear that anything more complex than a static/constant value would be out of reach for must/when expressions. Thanks, Kent From kwatsen@juniper.net Sat Mar 9 04:25:58 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB6E21F8460 for ; Sat, 9 Mar 2013 04:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aH8bdhFF4jGd for ; Sat, 9 Mar 2013 04:25:58 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2107B21F8454 for ; Sat, 9 Mar 2013 04:25:58 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUTsqVVuOTnF6Kk0OGT04kv6hbKRM/q/G@postini.com; Sat, 09 Mar 2013 04:25:58 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 9 Mar 2013 04:24:11 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Sat, 9 Mar 2013 04:24:10 -0800 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.185) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 9 Mar 2013 04:33:34 -0800 Received: from mail23-co1-R.bigfish.com (10.243.78.252) by CO1EHSOBE030.bigfish.com (10.243.66.95) with Microsoft SMTP Server id 14.1.225.23; Sat, 9 Mar 2013 12:24:10 +0000 Received: from mail23-co1 (localhost [127.0.0.1]) by mail23-co1-R.bigfish.com (Postfix) with ESMTP id F2BE15C0158 for ; Sat, 9 Mar 2013 12:24:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.241.149; KIP:(null); UIP:(null); (null); H:BL2PRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -28 X-BigFish: PS-28(zzbb2dI98dI9371I103dK1432I4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dh8275bhz2dh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h) Received: from mail23-co1 (localhost.localdomain [127.0.0.1]) by mail23-co1 (MessageSwitch) id 1362831848943128_6032; Sat, 9 Mar 2013 12:24:08 +0000 (UTC) Received: from CO1EHSMHS019.bigfish.com (unknown [10.243.78.243]) by mail23-co1.bigfish.com (Postfix) with ESMTP id E1DCA7C004A for ; Sat, 9 Mar 2013 12:24:08 +0000 (UTC) Received: from BL2PRD0511HT005.namprd05.prod.outlook.com (157.56.241.149) by CO1EHSMHS019.bigfish.com (10.243.66.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 9 Mar 2013 12:24:03 +0000 Received: from BL2PRD0511MB397.namprd05.prod.outlook.com ([169.254.9.189]) by BL2PRD0511HT005.namprd05.prod.outlook.com ([10.255.131.40]) with mapi id 14.16.0275.006; Sat, 9 Mar 2013 12:24:02 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) Thread-Index: AQHOGf52tLtd5nRdKkGaUzU6maqWYpic+iYA Date: Sat, 9 Mar 2013 12:24:02 +0000 Message-ID: In-Reply-To: <20130306000539.GG2854@nsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.255.131.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <2CFFFBBD76520F46B78F7B212D3AFDA9@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 12:25:58 -0000 Under System Identification, should there be some way to identify the system's role or operating mode? Roles might include if the "system" is a logical-system, stack-member, cluster-member, blade-server, or a blade-server-member. Operating mode might include if it's configured to run in FIPS-mode or if it's running a variation of code to meet cryptographic export restrictions. We found a need to have these attributes returned in our proprietary RPC. Admittedly, some of this could've been learned through the advertisement of a capability, but our "when" expressions needed something to act on. For instance, certain config nodes are disabled/enabled based on the device's role and/or operating-mode. Thanks, Kent On 3/5/13 7:05 PM, "David Kessens" wrote: > >Hi, > >I would hereby like to start a Last Call for: > >http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-05 > >Please indicate your support by Wed March 20, 2013. Or alternatively, let >us >know in the same timeframe whether there are still issues that need to be >resolved. > >Thanks! > >David Kessens >co-chair netmod wg >--- =20 >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod > From mbj@tail-f.com Sat Mar 9 04:35:22 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F23E21F8530 for ; Sat, 9 Mar 2013 04:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVmMACwkbyx3 for ; Sat, 9 Mar 2013 04:35:18 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id E23CD21F84A4 for ; Sat, 9 Mar 2013 04:35:17 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 6F8061200D5B; Sat, 9 Mar 2013 13:35:16 +0100 (CET) Date: Sat, 09 Mar 2013 13:35:16 +0100 (CET) Message-Id: <20130309.133516.271491746.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] conditional enablement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 12:35:22 -0000 Kent Watsen wrote: > My view (and that implemented by JUNOS) is that conditional enablement is > a cross-cutting feature - it is as if the attribute is implicitly defined > on *every* node in the tree. It is presumed that config-validation > conceptually occurs after stripping out all the disabled nodes, for > instance via a XLST script. Yes, this is the way it must work (and in our implementation of this it also works this way). It should be explicitly described in your draft. > To compound things more, my draft attempts to not restrict disabling a > node to a static constant (true/false), but to allow disablement based on > an expression (e.g. temporal). I think this is extremely difficult, or maybe impossible, to get to work right. It means that at a certain time the system is supposed to apply some config subtree, but what if the resulting config is invalid at that time? /martin From andy@yumaworks.com Sat Mar 9 06:26:28 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1597221F84A4 for ; Sat, 9 Mar 2013 06:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUQfz7ePvs6b for ; Sat, 9 Mar 2013 06:26:27 -0800 (PST) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4A921F8488 for ; Sat, 9 Mar 2013 06:26:27 -0800 (PST) Received: by mail-ia0-f178.google.com with SMTP id o25so2265143iad.23 for ; Sat, 09 Mar 2013 06:26:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=Cv6iWW8Esg1xL6+XwhGOtIvZngaLuljS0tYhUWkMEBQ=; b=VKcqvmodHvmiedQVgxIKk/CgG3GmTDgfNwGknG91e9zY4LRxVK/lzQqONLesxPH527 zfeWBLN07z9CERgXB8ncZ1/2g4iAGnpPMy5HYmL/L0o+xe9Pyf3F72QPL4/ADFYU78PD lMhIrO2DtuRkXyhKvhiY2DRxSvksw03/yxLsYOdYHsleEI67YprG5w8orqMi7mFbg/HK xxm8VCHckCca5jdQ/n6/3sWaOQV6S/LZ4plb81AAceim9VBSfwRsH0aNqJTXr06DgsrT BY/ulTJPQvkwYsN1oT8Axk60z0VrooCWeE+Rh67KebsLAO6aymwIETOfQAot6ATn1PaR 90hQ== MIME-Version: 1.0 X-Received: by 10.50.37.239 with SMTP id b15mr2456094igk.69.1362839186971; Sat, 09 Mar 2013 06:26:26 -0800 (PST) Received: by 10.231.93.6 with HTTP; Sat, 9 Mar 2013 06:26:26 -0800 (PST) In-Reply-To: References: <20130306000539.GG2854@nsn.com> Date: Sat, 9 Mar 2013 06:26:26 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmJoEpFZNlbWRl9NG9rpKvM4ieRaSeV6m2HHFmnttnyEdjjhgYz3A8AqE6xe4bDXN4naXiq Cc: "netmod@ietf.org" Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 14:26:28 -0000 Hi, I really do not want to start reinventing the Entity MIB as an afterthought -- something to throw into the system module at the last minute. We came up with the tree approach after the Chassis MIB was a total failure because each vendor insisted their model of the system was the correct one. A simple "system role" will not be sufficient, even if you could get agreement on the list of system roles. Andy On Sat, Mar 9, 2013 at 4:24 AM, Kent Watsen wrote: > > Under System Identification, should there be some way to identify the > system's role or operating mode? > > Roles might include if the "system" is a logical-system, stack-member, > cluster-member, blade-server, or a blade-server-member. > > Operating mode might include if it's configured to run in FIPS-mode or if > it's running a variation of code to meet cryptographic export restrictions. > > We found a need to have these attributes returned in our proprietary > RPC. Admittedly, some of this could've been > learned through the advertisement of a capability, but our "when" > expressions needed something to act on. For instance, certain config > nodes are disabled/enabled based on the device's role and/or > operating-mode. > > Thanks, > Kent > > > > > > On 3/5/13 7:05 PM, "David Kessens" wrote: > >> >>Hi, >> >>I would hereby like to start a Last Call for: >> >>http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-05 >> >>Please indicate your support by Wed March 20, 2013. Or alternatively, let >>us >>know in the same timeframe whether there are still issues that need to be >>resolved. >> >>Thanks! >> >>David Kessens >>co-chair netmod wg >>--- >>_______________________________________________ >>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 andy@yumaworks.com Sat Mar 9 06:41:38 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7521721F8629 for ; Sat, 9 Mar 2013 06:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mddaM0cfwgHQ for ; Sat, 9 Mar 2013 06:41:38 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id DC08B21F8622 for ; Sat, 9 Mar 2013 06:41:37 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id k11so3152020iea.24 for ; Sat, 09 Mar 2013 06:41:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=Dc+tT8gAt7/qgr/Ti9ygRL3eDvL3evd5j+KYN2H33uE=; b=hdSqLo27flvyrTWq4zmD3ksHywVFcN3HCWKTKBL2cfxRcDGVkb8e0eYd8iWQsVy72l SaffP2uUpB9DOx/tXwcQsLz3IRxTDWOg3pD1kdt77PcoB4W6cEl+0PBKtkPGMCHQb7VR C/PmM/ohv4AbGgHiIRAWBxmSPwFH4ha2GTllek9Xf55CeARHYcm1psMd0RmpVonRkSJ2 1zlO7oitLpQDaZva25JjghmqRUJ93W8y+YJBQThs5msD7aS4lBDtXDhGQhnLCT2kvu5w PSIO83HMW66JAJygHPiP9AUfG0p2qN5uqRKxCoYPI86Gemm2K9uNX6l22uVHNB4LKLgm 89Pw== MIME-Version: 1.0 X-Received: by 10.50.7.231 with SMTP id m7mr4875468iga.0.1362840096893; Sat, 09 Mar 2013 06:41:36 -0800 (PST) Received: by 10.231.93.6 with HTTP; Sat, 9 Mar 2013 06:41:36 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Mar 2013 06:41:36 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlGvOneaphrZ4jROX5f4JDcEpvTwqRbZXGEnwLjrt+rTuaPcsRd9hMWc5hA+fkLR4+zdsBY Cc: "netmod@ietf.org" Subject: Re: [netmod] conditional enablement (was: Last Call draft-ietf-netmod-system-mgmt-05) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 14:41:38 -0000 Hi, On Sat, Mar 9, 2013 at 4:06 AM, Kent Watsen wrote: > > > On 3/7/13 3:23 PM, "Andy Bierman" wrote: > >>I prefer leafs over XML attributes because YANG must/when >>expressions cannot see these flags unless they are leafs >>in the config. > > > Though likely moot, why wouldn't this work? > > when "/system/foobar[@enabled = 'true']" when "not > /system/foobar[@disabled]" > > At least XPath supports selection based on attribute values... > But YANG does not support XML attributes. Moving them from persistent elements to persistent attributes doesn't seem to help solve anything. > > Regardless, the reason why it's likely moot is because I think it'd be > crazy to use must/when expressions to support conditional enablement, but > my perspective assumes what can be disabled is selected by NETCONF-client > (not the data-modeler). It is a very common use-case that some sub-tree will only be applicable if some other feature is enabled. All the YANG statements are created by the client. Changing the enabled knob is no different than changing the MTU value IMO. I strongly object to inventing a new expression language for XML instead of using the XPath standard. > > My view (and that implemented by JUNOS) is that conditional enablement is > a cross-cutting feature - it is as if the attribute is implicitly defined > on *every* node in the tree. It is presumed that config-validation > conceptually occurs after stripping out all the disabled nodes, for > instance via a XLST script. If we didn't assume these nodes were > conceptually removed from the config before evaluation, then the must/when > expressions would need to be literally everywhere, which doesn't fly. Whether this is done via rules like NACM or whether the rules are cut-and-pasted into every leaf and parsed that way doesn't change the conceptual design. > > The other view would restrict what can be disabled to selections chosen by > the original data-modeler - this WG for instance. However, all examples > to date of how we have used flags to disable nodes have been at the > "feature" level (e.g. use-ntp), but have we considered that maybe the > customer doesn't want to disable the NTP service as a whole, but instead > they want to disable just a specific ntp-server? > > To compound things more, my draft attempts to not restrict disabling a > node to a static constant (true/false), but to allow disablement based on > an expression (e.g. temporal). While it remains to be seen how this is > resolved, it's clear that anything more complex than a static/constant > value would be out of reach for must/when expressions. > I think this needs a lot more work to be feasible. If there is a meta-config on top of the real config, when is is validated, how is it maintained, and how is it applied to the real config exactly the same way on all implementations? How to multiple clients resolve policy (meta-config) editing conflicts? Is there locking and priority ownership in the meta-config? How is that managed? Without a schema, how do client developers know how to construct policies the server will accept? How do validation constraints interact between the meta-config and the real config? That's why I prefer to have just use leafs and stick with 1 config. > Thanks, > Kent Andy From andy@yumaworks.com Sat Mar 9 09:23:45 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB54021F866E for ; Sat, 9 Mar 2013 09:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FloBTr3GORLi for ; Sat, 9 Mar 2013 09:23:44 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA3B21F8644 for ; Sat, 9 Mar 2013 09:23:44 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id bn7so3320886ieb.11 for ; Sat, 09 Mar 2013 09:23:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=38O6MfiZCL5dLFmGrzSWph4GLPG+XLa0ImEdJxymGyw=; b=ZaIpY/Nn9kxXnqYlqyMfRBHSTAcQ3WEC+GZtdNs7S2s7HD7mAYTrcEf6W4fn1/5yV1 G9wzW4PNucErNge4vDB/FcxmVNEyG70TYHKZ1mosCsVfkKtwkBz89gaga6huV5sRT4WK 8TAyPPM+vEhIq92xGwSu5PCgi1aBPCouMQBJ8J0S2i0WfKuZy8ZCiYf5Pk1D6eCrYcTi hFcEXkazObxjrfx0kM3pBUaf6W+xALfBzPyGdgwE+YXeh/gLtrYPw0a4W2nRLezATIuh XqZfzlrt6VA/b6+DWpC4WkfYFCVKEldt7g7ljyv0O5TDv66yALia1lasUzaPtqLl+FHe W7Qg== MIME-Version: 1.0 X-Received: by 10.50.12.137 with SMTP id y9mr2878604igb.57.1362849823671; Sat, 09 Mar 2013 09:23:43 -0800 (PST) Received: by 10.231.93.6 with HTTP; Sat, 9 Mar 2013 09:23:43 -0800 (PST) In-Reply-To: <20130308.111224.1340322135392779942.mbj@tail-f.com> References: <201303072047.r27KlMVE014278@idle.juniper.net> <20130308.111224.1340322135392779942.mbj@tail-f.com> Date: Sat, 9 Mar 2013 09:23:43 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQm4wKx3astmXhu06EMszgyH9tjBV3lnKJz77KHoROihAe+wlnAS4o0u+uk6bd5STo3pz3u8 Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 17:23:45 -0000 On Fri, Mar 8, 2013 at 2:12 AM, Martin Bjorklund wrote: > Phil Shafer wrote: >> Andy Bierman writes: >> >What is the semi-standard "enable"? >> >> I thought other drafts use "enable" instead of "use-xxx", but >> checking shows both "enable" and "enabled". It defaults to true, >> which means it will only be set to "false" (explicitly anyway) so >> it's really more of a "disable" knob. ('leaf disable { type empty; }'?) > > I am all for consistency. > > I cannot find other drafts using "enable", and personally I think it > is a bit weird to have a verb in the config. So I prefer to have "leaf > enabled". > > >> >You mean a leaf? I prefer a grouping with an enabled leaf >> >that each module uses (instead of cut-and-paste). >> >> That would be fine, and that "grouping enable" could be in a standard >> module to everyone could include it, if that's what you're after. > > +1 > > But where do we put it...? In 6021bis? (ietf-yang-types). > Yes to 6021bis, but I prefer a new module called ietf-yang-groupings. > > /martin Andy From andy@yumaworks.com Sat Mar 9 09:27:28 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC9B21F8644 for ; Sat, 9 Mar 2013 09:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.978 X-Spam-Level: X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E92iOl6LjNpO for ; Sat, 9 Mar 2013 09:27:27 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2157D21F8484 for ; Sat, 9 Mar 2013 09:27:27 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id bn7so3322920ieb.11 for ; Sat, 09 Mar 2013 09:27:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=CEugNeuTV1npDc9Ovl4G1eYK0Ve2ClU3ROVfKplv7Tc=; b=gGxbNz9JpKRTAsLNhW6j9Dcw9ysGmVtYerYONJv87Y0GZZ4XnL/klVMyASr4uFTxE3 ZoSaW6aLGeun5kwga+zBT9+9uE7GqcxtmT3CvksV+/oK+zAELltyd+dW4NTLPwRtTESs WxQ/vVn2Hs8WDPbyuw8sUxPbwVIu5CwvuULB243bknfXdd+eOOusa3BUWHpfBU2bQrCd bJrHU1NguR3bu2p7+CGav+vzKznxbFESIcSgdlrKhr0uJXKx5+RYlhq2iLvExzdNyp7S jF5LsGACNL/+LIN5JT0oKoGRcUFl80pb8XpXQ6DRsfXt3dXSFGVM59D5wjaMizZhddsD jAPg== MIME-Version: 1.0 X-Received: by 10.50.219.168 with SMTP id pp8mr2892070igc.57.1362850046680; Sat, 09 Mar 2013 09:27:26 -0800 (PST) Received: by 10.231.93.6 with HTTP; Sat, 9 Mar 2013 09:27:26 -0800 (PST) In-Reply-To: <201303062008.r26K8H5c006746@idle.juniper.net> References: <51374C76.8070902@tail-f.com> <201303062008.r26K8H5c006746@idle.juniper.net> Date: Sat, 9 Mar 2013 09:27:26 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmphxeiRFFAb3APA+Ux0hI1GAYjlDIAZ0XYf4CPiZfCf2yCWw7iJ5bfxRaP1gxzt8AuSGQF Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 17:27:28 -0000 On Wed, Mar 6, 2013 at 12:08 PM, Phil Shafer wrote: > Here are some additional comments on the draft: > > 2.1: having location as an opaque field renders it useless for > automation. In JUNOS, our [system location] contains: > Step 1) I agree with your problem statement. Schema-defined data is obviously better for automation than ad-hoc strings. Step 2) I have no objection to adding additional objects if there is WG consensus and proper references for all the leafs accepted. Andy > attribute country-code { > help "Two-letter country code"; > type string; > } > attribute postal-code { > help "Zip code or postal code"; > type string; > } > attribute npa-nxx { > help "First six digits of phone number (area code plus exchange)"; > type string; > } > attribute latitude { > help "Latitude in degree format"; > type string; > } > attribute longitude { > help "Longitude in degree format"; > type string; > } > attribute altitude { > help "Feet above (or below) sea level"; > type int; > } > attribute lata { > help "Long-distance service area"; > type string; > } > attribute vcoord { > help "Bellcore vertical coordinate"; > type string; > } > attribute hcoord { > help "Bellcore horizontal coordinate"; > type string; > } > attribute building { > help "Building name"; > type string; > } > > attribute floor { > help "Floor of the building"; > type int; > } > > attribute rack { > help "Rack number"; > type uint; > } > > These were the requirements from our customers >10 years ago and seem > to be enough for everyone. (Okay, altitude was my addition.....) > > Fix: add additional fields. > > 2.3 says publickey and password are both required, but this need > not be true. I've been turning off ssh passwords on my public boxes > to keep the script kiddies at bay. > > RADIUS is also mentioned as a "need", but there are many others > (tacplus, skey, etc). > > Fix: don't call out specific technology requirements. > > 3.1: Is "name" the DNS name of the device? Can we say that, either > here or in the description? "administratively assigned system name" > doesn't mean much to the average reader. > > 3.2: Why have use-ntp? Why not have [system ntp] a purpose container? > > You list ntp-server (nuke the leading "ntp-"), but not peers or boot > servers. You are missing authentication keys, source address, > version, polling interval constraints (min and max), broadcast server > and client info, and multicast client info. > > re: enabled: would be good to make a generic means for this, so we > don't need to put this knob on every container. > > 3.3: In JUNOS, we call out the local domain explicitly, distinct from > the domain search path. This is similar to the "domain" and "search" > fields in BSD's resolv.conf. > > 3.4: Should RADIUS config be in a distinct module, augmenting this > one? Using a feature work, but skey, tacplus, etc need config also. > Are we saying that RADIUS is the only modern/needed one? > > 3.5: The user-authentication-order must says: > > must '(. = "sys:radius" and ../../radius/server) or' > + '(. != "sys:radius")' { > > which is '. != "sys:radius" || ../../radius/server', right? > > Passwords without the leading $ are old-school style. Support them? > > In the same vein, JUNOS uses $9$ for obfuscating secret data to avoid > allowing over-the-shoulder password stealing. It's only obfuscation, > but is still useful for secrets that we need in plain text later and > cannot use just the hash. Similar with systems that use a single > "master password" to encrypt secret data. > > What is an ssh key's name? Just a user-defined handle? Why not use > the complete ssh key as the key? > > Why is ssh key data binary? > > Users require both authentication and authorization. In JUNOS, > we put this under a container under "system" named "login" with two > lists, "users" and "classes". The login class can be used to > constrict (or expand) the user's permissions, as well as setting time > of day restrictions, source address restrictions, and cosmetic bits > like displaying alarms or help text at login time on the CLI. > > 3.6: Consider making a leaf under a single > operation, ala the BSD shutdown command. > > Why are the shutdown operations "deny-all"? > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From kwatsen@juniper.net Sat Mar 9 12:06:56 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1959A21F8801 for ; Sat, 9 Mar 2013 12:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMVphWWHcoR8 for ; Sat, 9 Mar 2013 12:06:55 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 84B0321F87D7 for ; Sat, 9 Mar 2013 12:06:55 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUTuWX2dqK3rxD0ZazCBvqNJx/zgnIniu@postini.com; Sat, 09 Mar 2013 12:06:55 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 9 Mar 2013 12:05:17 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Sat, 9 Mar 2013 12:05:17 -0800 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.187) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 9 Mar 2013 12:08:02 -0800 Received: from mail109-co1-R.bigfish.com (10.243.78.231) by CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id 14.1.225.23; Sat, 9 Mar 2013 20:05:16 +0000 Received: from mail109-co1 (localhost [127.0.0.1]) by mail109-co1-R.bigfish.com (Postfix) with ESMTP id 72F446002D0 for ; Sat, 9 Mar 2013 20:05:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.241.149; KIP:(null); UIP:(null); (null); H:BL2PRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -4 X-BigFish: PS-4(zzbb2dI98dI9371I4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275bhz2dh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h) Received: from mail109-co1 (localhost.localdomain [127.0.0.1]) by mail109-co1 (MessageSwitch) id 1362859509700831_28443; Sat, 9 Mar 2013 20:05:09 +0000 (UTC) Received: from CO1EHSMHS011.bigfish.com (unknown [10.243.78.233]) by mail109-co1.bigfish.com (Postfix) with ESMTP id A92761601D4; Sat, 9 Mar 2013 20:05:09 +0000 (UTC) Received: from BL2PRD0511HT002.namprd05.prod.outlook.com (157.56.241.149) by CO1EHSMHS011.bigfish.com (10.243.66.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 9 Mar 2013 20:05:09 +0000 Received: from BL2PRD0511MB397.namprd05.prod.outlook.com ([169.254.9.189]) by BL2PRD0511HT002.namprd05.prod.outlook.com ([10.255.131.37]) with mapi id 14.16.0275.006; Sat, 9 Mar 2013 20:05:08 +0000 From: Kent Watsen To: Andy Bierman , Phil Shafer Thread-Topic: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) Thread-Index: AQHOGf52tLtd5nRdKkGaUzU6maqWYpiYsn4AgABmM4CABIoOAP//2DsA Date: Sat, 9 Mar 2013 20:05:07 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.255.131.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <7E29F2FA469C2D45B9FB769D0B2EF468@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%YUMAWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "netmod@ietf.org" Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 20:06:56 -0000 On 3/9/13 12:27 PM, "Andy Bierman" wrote: >Step 2) I have no objection to adding additional objects if there is > WG consensus and proper references for all the leafs accepted. Is it fair to say the same view applies to my suggestion for system "role" and "mode" fields? ;) Thanks, Kent From kwatsen@juniper.net Sat Mar 9 12:16:02 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE10821F87A4 for ; Sat, 9 Mar 2013 12:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.429 X-Spam-Level: X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6gVapLtf-sh for ; Sat, 9 Mar 2013 12:16:02 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2061621F879D for ; Sat, 9 Mar 2013 12:16:02 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUTuYgagTpez7xSiebkHpDnAxOrRuWbwu@postini.com; Sat, 09 Mar 2013 12:16:02 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 9 Mar 2013 12:14:03 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Sat, 9 Mar 2013 12:14:02 -0800 Received: from DB8EHSOBE018.bigfish.com (213.199.154.185) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 9 Mar 2013 12:16:47 -0800 Received: from mail150-db8-R.bigfish.com (10.174.8.240) by DB8EHSOBE018.bigfish.com (10.174.4.81) with Microsoft SMTP Server id 14.1.225.23; Sat, 9 Mar 2013 20:14:00 +0000 Received: from mail150-db8 (localhost [127.0.0.1]) by mail150-db8-R.bigfish.com (Postfix) with ESMTP id A3DF71800CC for ; Sat, 9 Mar 2013 20:14:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.241.149; KIP:(null); UIP:(null); (null); H:BL2PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -4 X-BigFish: PS-4(zzbb2dI98dI9371I4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275bhz2dh2a8h668h839h946he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h) Received: from mail150-db8 (localhost.localdomain [127.0.0.1]) by mail150-db8 (MessageSwitch) id 1362860037350013_27074; Sat, 9 Mar 2013 20:13:57 +0000 (UTC) Received: from DB8EHSMHS020.bigfish.com (unknown [10.174.8.226]) by mail150-db8.bigfish.com (Postfix) with ESMTP id 53225300045; Sat, 9 Mar 2013 20:13:57 +0000 (UTC) Received: from BL2PRD0511HT004.namprd05.prod.outlook.com (157.56.241.149) by DB8EHSMHS020.bigfish.com (10.174.4.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 9 Mar 2013 20:13:57 +0000 Received: from BL2PRD0511MB397.namprd05.prod.outlook.com ([169.254.9.189]) by BL2PRD0511HT004.namprd05.prod.outlook.com ([10.255.131.39]) with mapi id 14.16.0275.006; Sat, 9 Mar 2013 20:13:49 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) Thread-Index: AQHOGf52tLtd5nRdKkGaUzU6maqWYpic+iYAgAB2BgCAAA07gA== Date: Sat, 9 Mar 2013 20:13:49 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.255.131.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4363C87306BA9E41A8554A3E3A8A7F6A@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%YUMAWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "netmod@ietf.org" Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 20:16:02 -0000 On 3/9/13 9:26 AM, "Andy Bierman" wrote: >I really do not want to start reinventing the Entity MIB as >an afterthought -- something to throw into the system module >at the last minute. We came up with the tree approach after the Chassis >MIB >was a total failure because each vendor insisted their model of the system >was the correct one. A simple "system role" will not be sufficient, >even if you could get agreement on the list of system roles. I'm put off by the "last minute" reference - does it really matter when the ideas come in? - some times these things don't come to people right away and, just because it's "last call" doesn't make them any less relevant. Also, I don't see why Entity MIB should be thought of as constraint. Clearly NETCONF is an attempt to break away from the failed SNMP solution, so why not think to do better? FWIW, we defined the "roles" at the top-level, since they were both universal and dictated the need for the NMS to gather more information, but left the "modes" as a vendor-extensible field, since the values "fips" and "export" were clearly arbitrary=8A Thanks, Kent From andy@yumaworks.com Sat Mar 9 12:30:46 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AB921F85AC for ; Sat, 9 Mar 2013 12:30:46 -0800 (PST) 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.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpDl-vOMPQUN for ; Sat, 9 Mar 2013 12:30:45 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 96FB621F8570 for ; Sat, 9 Mar 2013 12:30:45 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id k11so3340015iea.24 for ; Sat, 09 Mar 2013 12:30:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=wWsZeJH8doW+7AxA7y+eB30qEHYnjuXUEJlG8i2qB9g=; b=gor16pa2hIadicOMKNsQi89gHArUbKDT3z7QTy+U+8PH/h2jm5aKuyQDoUsgkfIaCs cifb3/rXxaMF7zHIyi2/+fqhwpkW87XEd01YIUncK2oHb9umPwFtflXBaIASeN6StqfM /bpKw6HC6BBiN2UDqzt4oyOsNvBJrLNXxcCT27q0Z6Trzddv6Fnd3hV6Qses/YloI3CA WdNRoGtJ3DTDJIQrxMckLmQxER59XMT0NK6VtlF91ividXS+oY8r8BjSuuq0Czmi+ZvJ 0FyIH/Lf1x41A4Gdf7SbBF3wS8vvmrkgD/xGQ5Z+H4Q6xSULN++JFM5Alw3N5/oBArFB TrAw== MIME-Version: 1.0 X-Received: by 10.50.53.143 with SMTP id b15mr3352533igp.69.1362861045163; Sat, 09 Mar 2013 12:30:45 -0800 (PST) Received: by 10.231.93.6 with HTTP; Sat, 9 Mar 2013 12:30:45 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Mar 2013 12:30:45 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmSm6wwt29qDxiDBEbq99UVJEqKoaN8Gtt/fmutam1G7HrIB5Rx9aLrxBJ1zZ8ofbnyMYyS Cc: "netmod@ietf.org" Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 20:30:46 -0000 Hi, So you are asking for an ad-hoc admin string and the operator puts whatever they want there? Certainly not an ENTITY-MIB replacement. I don't think any of the new leafs proposed are that important -- I don't want to restart the clock and spend 4 or 8 more months agreeing on each leaf and what exactly they mean. If none get added that is fine. But if the WG agrees during WGLC on some leafs, and there is an external reference defining each leaf (so we cannot debate that) then that's fine too. Andy On Sat, Mar 9, 2013 at 12:13 PM, Kent Watsen wrote: > > > On 3/9/13 9:26 AM, "Andy Bierman" wrote: > >>I really do not want to start reinventing the Entity MIB as >>an afterthought -- something to throw into the system module >>at the last minute. We came up with the tree approach after the Chassis >>MIB >>was a total failure because each vendor insisted their model of the syste= m >>was the correct one. A simple "system role" will not be sufficient, >>even if you could get agreement on the list of system roles. > > > I'm put off by the "last minute" reference - does it really matter when > the ideas come in? - some times these things don't come to people right > away and, just because it's "last call" doesn't make them any less > relevant. > > Also, I don't see why Entity MIB should be thought of as constraint. > Clearly NETCONF is an attempt to break away from the failed SNMP solution= , > so why not think to do better? > > FWIW, we defined the "roles" at the top-level, since they were both > universal and dictated the need for the NMS to gather more information, > but left the "modes" as a vendor-extensible field, since the values "fips= " > and "export" were clearly arbitrary=C5=A0 > > Thanks, > Kent > > From lhotka@nic.cz Sun Mar 10 04:15:42 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8411621F8782 for ; Sun, 10 Mar 2013 04:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KyLsc4WM+FN for ; Sun, 10 Mar 2013 04:15:41 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7561521F84B1 for ; Sun, 10 Mar 2013 04:15:40 -0700 (PDT) Received: from [130.129.133.225] (unknown [130.129.133.225]) by mail.nic.cz (Postfix) with ESMTPSA id 87B5F13F797; Sun, 10 Mar 2013 12:15:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1362914139; bh=i25qsZWdcuKlJfsHB/CL5hiDO38G0bcz50QrnLK3TQo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Kv02XGkreJjPF7ZPTVMxNkVWSYJfttcA6p9yItQSAYoXhgMdNdLL7MV3eyywB/9rT M6mbMrXxMCnSnldfkxk5Q1wZyCbuMSxx+tdl0VPE0YsuRTxM9ysXp8+/bveKXQ9vhT IGLOnmF7b5ytu+cWEvaD7kB2ENGhc+mcukZXpxNw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Sun, 10 Mar 2013 07:15:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4C9EB86A-73EA-4E10-A41E-444DF15B79EA@nic.cz> References: To: Kent Watsen X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] conditional enablement (was: Last Call draft-ietf-netmod-system-mgmt-05) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 11:15:42 -0000 On Mar 9, 2013, at 7:06 AM, Kent Watsen wrote: >=20 >=20 > On 3/7/13 3:23 PM, "Andy Bierman" wrote: >=20 >> I prefer leafs over XML attributes because YANG must/when >> expressions cannot see these flags unless they are leafs >> in the config. >=20 >=20 > Though likely moot, why wouldn't this work? >=20 > when "/system/foobar[@enabled =3D 'true']" when "not > /system/foobar[@disabled]" "when" is already broken, and it would get worse with this: container system { list foobar { ... leaf baz { when "ancestor::foobar[@enabled =3D 'true']"; ... } } Setting @enabled to "false" on a *single* "foobar" entry would = invalidate "baz" not only for that entry but for all entries! It is = because "when" operates not on the instance document but on the schema. Lada >=20 > At least XPath supports selection based on attribute values... >=20 >=20 > Regardless, the reason why it's likely moot is because I think it'd be > crazy to use must/when expressions to support conditional enablement, = but > my perspective assumes what can be disabled is selected by = NETCONF-client > (not the data-modeler). >=20 > My view (and that implemented by JUNOS) is that conditional enablement = is > a cross-cutting feature - it is as if the attribute is implicitly = defined > on *every* node in the tree. It is presumed that config-validation > conceptually occurs after stripping out all the disabled nodes, for > instance via a XLST script. If we didn't assume these nodes were > conceptually removed from the config before evaluation, then the = must/when > expressions would need to be literally everywhere, which doesn't fly. >=20 > The other view would restrict what can be disabled to selections = chosen by > the original data-modeler - this WG for instance. However, all = examples > to date of how we have used flags to disable nodes have been at the > "feature" level (e.g. use-ntp), but have we considered that maybe the > customer doesn't want to disable the NTP service as a whole, but = instead > they want to disable just a specific ntp-server? >=20 > To compound things more, my draft attempts to not restrict disabling a > node to a static constant (true/false), but to allow disablement based = on > an expression (e.g. temporal). While it remains to be seen how this = is > resolved, it's clear that anything more complex than a static/constant > value would be out of reach for must/when expressions. >=20 > Thanks, > Kent >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Sun Mar 10 04:24:49 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2AB21F86C9 for ; Sun, 10 Mar 2013 04:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2P1rU9oZxYb for ; Sun, 10 Mar 2013 04:24:49 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 20CC421F8678 for ; Sun, 10 Mar 2013 04:24:49 -0700 (PDT) Received: from [130.129.133.225] (unknown [130.129.133.225]) by mail.nic.cz (Postfix) with ESMTPSA id BE79113F797; Sun, 10 Mar 2013 12:24:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1362914688; bh=UVLZqOm5HUR6Nmj+Gz64tvy8UI1fWB3g85IaGzixYvY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wF1LkMzRMfRRTJzMCZqJVrUBgpUySF1Y4oIoq2fZ2FZNoK3OMvhpQX8+iSGBWbEC4 R04sl6WW4LQY6m9N0sdLlYw2/R9sUBbmIAdKNHPXvZ7x1zpPxCRPrJppP84N3oH0KZ P9XWaqnEf7zSL3wPYfpgcvyqt+/wswVtbsDM3U2M= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20130309.133516.271491746.mbj@tail-f.com> Date: Sun, 10 Mar 2013 07:24:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5BCEB862-09FD-4145-A246-B10D4BE3DA7B@nic.cz> References: <20130309.133516.271491746.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] conditional enablement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 11:24:49 -0000 On Mar 9, 2013, at 7:35 AM, Martin Bjorklund wrote: > Kent Watsen wrote: >> My view (and that implemented by JUNOS) is that conditional = enablement is >> a cross-cutting feature - it is as if the attribute is implicitly = defined >> on *every* node in the tree. It is presumed that config-validation >> conceptually occurs after stripping out all the disabled nodes, for >> instance via a XLST script. >=20 > Yes, this is the way it must work (and in our implementation of this > it also works this way). It should be explicitly described in your > draft. >=20 >> To compound things more, my draft attempts to not restrict disabling = a >> node to a static constant (true/false), but to allow disablement = based on >> an expression (e.g. temporal). >=20 > I think this is extremely difficult, or maybe impossible, to get to > work right. It means that at a certain time the system is supposed to > apply some config subtree, but what if the resulting config is invalid > at that time? As I already wrote, this could IMO be implemented via a server-side = cron-like capability, so that a particular *edit* rather than an entire = configuration would be applied at specific time(s), with all due checks. Without further ado I can use cron on the client for the same purpose = now, so it would only move the responsibility to the server - with the = additional benefit that all clients could also see what has been = scheduled by other clients. Lada =20 >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From phil@juniper.net Mon Mar 11 05:22:02 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB8321F8697 for ; Mon, 11 Mar 2013 05:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.739 X-Spam-Level: X-Spam-Status: No, score=-6.739 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxmi+wQLLQFe for ; Mon, 11 Mar 2013 05:22:01 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA4C21F86AF for ; Mon, 11 Mar 2013 05:21:55 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUT3MY+YU0kiCDFiv9tsIqmNar44ITLha@postini.com; Mon, 11 Mar 2013 05:22:01 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 11 Mar 2013 05:21:01 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r2BCKu375059; Mon, 11 Mar 2013 05:20:59 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id r2BCJt9E086585; Mon, 11 Mar 2013 08:20:16 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201303111220.r2BCJt9E086585@idle.juniper.net> To: David Kessens In-Reply-To: <20130307212851.GY2854@nsn.com> Date: Mon, 11 Mar 2013 08:19:55 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 12:22:02 -0000 David Kessens writes: >The intention of the system model was to cover 90% of cases. More specific >data models can be worked on later. If this is the intention, the document should spell it out. It's definitely not obvious. Even 90% is probably too high a number, given the massive diversity of networks. >It's a judgement call what is 90% and what >is the other 10%, but it surely is not needed to support every >option/feature under the sun. Too often this turns out to mean anything I use is in the 90%; anything I don't is in the 10%. ;^) Thanks, Phil From phil@juniper.net Mon Mar 11 05:24:08 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEBC21F8794 for ; Mon, 11 Mar 2013 05:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.716 X-Spam-Level: X-Spam-Status: No, score=-6.716 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OFAbWMJ09CM for ; Mon, 11 Mar 2013 05:24:07 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id B77EB21F88A2 for ; Mon, 11 Mar 2013 05:24:02 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUT3M4vPeab4hkUR7IQH5BGQNtDD40KbH@postini.com; Mon, 11 Mar 2013 05:24:04 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 11 Mar 2013 05:23: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 r2BCNE376705; Mon, 11 Mar 2013 05:23:15 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id r2BCMSki086631; Mon, 11 Mar 2013 08:22:44 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201303111222.r2BCMSki086631@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: Date: Mon, 11 Mar 2013 08:22:28 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 12:24:08 -0000 Ladislav Lhotka writes: >I agree. Whilst such a meta-flag would be nice, the "collateral damage" would IMO be jus >t too high. Please explain what you mean by "collateral damage" in this arena. I'm not following. Thanks, Phil From phil@juniper.net Mon Mar 11 05:30:03 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D1421F859C for ; Mon, 11 Mar 2013 05:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.699 X-Spam-Level: X-Spam-Status: No, score=-6.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxiVsLxRaA+v for ; Mon, 11 Mar 2013 05:30:02 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 28A9A21F85B3 for ; Mon, 11 Mar 2013 05:30:01 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUT3OSD97AdzUfN2dTfMHEwLbDqTcMV0c@postini.com; Mon, 11 Mar 2013 05:30:02 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 11 Mar 2013 05:28:18 -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 r2BCS2379498; Mon, 11 Mar 2013 05:28:02 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id r2BCR0bh086675; Mon, 11 Mar 2013 08:27:21 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201303111227.r2BCR0bh086675@idle.juniper.net> To: Kent Watsen In-Reply-To: Date: Mon, 11 Mar 2013 08:27:00 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] conditional enablement (was: Last Call draft-ietf-netmod-system-mgmt-05) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 12:30:03 -0000 Kent Watsen writes: >Though likely moot, why wouldn't this work? > > when "/system/foobar[@enabled = 'true']" when "not >/system/foobar[@disabled]" The idea should be that since enable/disable is a well-known item, then must/when expressions should not need to sweat explicit references to the attribute. If it's disabled, then it's considered to be deleted for purposes of validation. Thanks, Phil From phil@juniper.net Mon Mar 11 05:32:37 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A54721F87B3 for ; Mon, 11 Mar 2013 05:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.687 X-Spam-Level: X-Spam-Status: No, score=-6.687 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPI7sMfj3mau for ; Mon, 11 Mar 2013 05:32:36 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 679A321F87AD for ; Mon, 11 Mar 2013 05:32:35 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUT3O4/RHniDlmJgMxSt8WG8vpJHl0rH6@postini.com; Mon, 11 Mar 2013 05:32:36 PDT Received: from merlot.juniper.net (172.17.27.10) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 11 Mar 2013 05:31:12 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id r2BCVta25442; Mon, 11 Mar 2013 05:31:56 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id r2BCTWZV086716; Mon, 11 Mar 2013 08:29:52 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201303111229.r2BCTWZV086716@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Mon, 11 Mar 2013 08:29:32 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] conditional enablement (was: Last Call draft-ietf-netmod-system-mgmt-05) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 12:32:37 -0000 Andy Bierman writes: >But YANG does not support XML attributes. YANG models metadata in attributes. enable/disable can be considered metadata. >Moving them from persistent elements to persistent attributes doesn't >seem to help solve anything. No, but making this concept a first-class feature of YANG does help to solve this, since it allows must/when expressions to ignore it. Thanks, Phil From lhotka@nic.cz Mon Mar 11 06:49:29 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCE321F8596 for ; Mon, 11 Mar 2013 06:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+HFhOfSdVMF for ; Mon, 11 Mar 2013 06:49:28 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B235121F84BD for ; Mon, 11 Mar 2013 06:49:28 -0700 (PDT) Received: from [IPv6:2001:df8::16:41df:74bd:363f:1b92] (unknown [IPv6:2001:df8:0:16:41df:74bd:363f:1b92]) by mail.nic.cz (Postfix) with ESMTPSA id 7DC7C13FA87; Mon, 11 Mar 2013 14:49:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1363009766; bh=sqW9Gk+4/sPVFDmHRZXqrwOQ4DkH41VuZ3gCenIebvM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=FLBt+MD1rGMfegPSm5kV6yXJsC+WREbZatzVCf2NKtlyNKS7fIsUkQxrBLepIbjb6 o9VGLLUBxP3Yxxplq9WgMztiPhfqUHqrDGViEqQH8Nuf5v+czEI0vq1NNLP8IkyJly dF7Fu31zT299ZrQmf60qvPly5XYQHyhnm/4zm9u4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <201303111222.r2BCMSki086631@idle.juniper.net> Date: Mon, 11 Mar 2013 09:49:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4240EC45-3F1F-43AF-996E-7F7D0430B649@nic.cz> References: <201303111222.r2BCMSki086631@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 13:49:29 -0000 On Mar 11, 2013, at 8:22 AM, Phil Shafer wrote: > Ladislav Lhotka writes: >> I agree. Whilst such a meta-flag would be nice, the "collateral = damage" would IMO be jus >> t too high. >=20 > Please explain what you mean by "collateral damage" in > this arena. I'm not following. I meant that it would affect existing concepts in YANG, of course = depending on the precise semantics of that attribute. must/when was = already mentioned, and another question I have is about data model = defaults: if a subtree is tagged as disabled, should the server still = assume that all default values in that subtree are operationally active? Lada =20 >=20 > Thanks, > Phil -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From kwatsen@juniper.net Mon Mar 11 09:39:03 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F0E11E8164 for ; Mon, 11 Mar 2013 09:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.434 X-Spam-Level: X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6-TYZawMky1 for ; Mon, 11 Mar 2013 09:39:02 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 96ADA11E814F for ; Mon, 11 Mar 2013 09:39:02 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUT4Ipvizk9+A2U4bUcL3jci3E3mSff9y@postini.com; Mon, 11 Mar 2013 09:39:02 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 11 Mar 2013 09:36:02 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 11 Mar 2013 09:36:02 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.183) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 11 Mar 2013 09:45:24 -0700 Received: from mail66-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Mar 2013 16:36:01 +0000 Received: from mail66-ch1 (localhost [127.0.0.1]) by mail66-ch1-R.bigfish.com (Postfix) with ESMTP id 2D8C7200140 for ; Mon, 11 Mar 2013 16:36:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -3 X-BigFish: PS-3(zzbb2dI98dI9371Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h) Received: from mail66-ch1 (localhost.localdomain [127.0.0.1]) by mail66-ch1 (MessageSwitch) id 136301975917869_7236; Mon, 11 Mar 2013 16:35:59 +0000 (UTC) Received: from CH1EHSMHS004.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.228]) by mail66-ch1.bigfish.com (Postfix) with ESMTP id 00FB24E004B; Mon, 11 Mar 2013 16:35:59 +0000 (UTC) Received: from CH1PRD0511HT004.namprd05.prod.outlook.com (157.56.245.197) by CH1EHSMHS004.bigfish.com (10.43.70.4) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 11 Mar 2013 16:35:54 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.166]) by CH1PRD0511HT004.namprd05.prod.outlook.com ([10.255.159.39]) with mapi id 14.16.0275.006; Mon, 11 Mar 2013 16:35:53 +0000 From: Kent Watsen To: Ladislav Lhotka , Phil Shafer Thread-Topic: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) Thread-Index: AQHOGf52tLtd5nRdKkGaUzU6maqWYpiYsn4AgABmM4CAACQfAIABboeAgAAD84CAAUArgIAEgr4AgAAYS4D//+t3gA== Date: Mon, 11 Mar 2013 16:35:52 +0000 Message-ID: In-Reply-To: <4240EC45-3F1F-43AF-996E-7F7D0430B649@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%NIC.CZ$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "netmod@ietf.org" Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 16:39:03 -0000 On 3/11/13 9:49 AM, "Ladislav Lhotka" wrote: >another question I have is about data model defaults: if a subtree is >tagged as disabled, should the server still assume that all default >values in that subtree are operationally active? No, a disabled subtree (e.g. disabled=3D"true" on a parent node) is conceptually not in the config anymore. For instance, is XSLT script could be written filter these nodes out prior to validation. Is it any different to how we're using explicit "enabled" leaves today? K. From lhotka@nic.cz Mon Mar 11 10:30:47 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AE621F8B96 for ; Mon, 11 Mar 2013 10:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-8X84c-LHFx for ; Mon, 11 Mar 2013 10:30:46 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3DC21F886A for ; Mon, 11 Mar 2013 10:30:46 -0700 (PDT) Received: from [IPv6:2001:df8::16:b17c:b30a:6830:f3a9] (unknown [IPv6:2001:df8:0:16:b17c:b30a:6830:f3a9]) by mail.nic.cz (Postfix) with ESMTPSA id 591DF140509; Mon, 11 Mar 2013 18:30:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1363023045; bh=mgqsncd1ZzjPyEIyHj2rAhls3/9svZxPHVf4EzgIS8k=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hVsdwFMLE0xYsLAxGiZ36dtwhP/fToE2CCIYPsb59vInjA5dYGBq+bpzhLOQqk2z8 hOe9z6mS2I4nThIs966erCTgvC0F61uArHNmn9zhLMOWszkc/F66DubcvE6TIPxOIJ y8DQPG7EF3it2XQh8/g6VKe2RmCLiZG2VA3DcBbo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 11 Mar 2013 13:30:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <16FEE9C9-0215-4083-A6C4-01E01BB43BBB@nic.cz> References: To: Kent Watsen X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 17:30:47 -0000 =09 On Mar 11, 2013, at 12:35 PM, Kent Watsen wrote: >=20 >=20 > On 3/11/13 9:49 AM, "Ladislav Lhotka" wrote: >=20 >> another question I have is about data model defaults: if a subtree is >> tagged as disabled, should the server still assume that all default >> values in that subtree are operationally active? >=20 > No, a disabled subtree (e.g. disabled=3D"true" on a parent node) is > conceptually not in the config anymore. For instance, is XSLT script > could be written filter these nodes out prior to validation. Well, by normal YANG rules, the defaults still apply even if the subtree = of a non-presence container in not in config. So this would require = additional specification for defaults. >=20 > Is it any different to how we're using explicit "enabled" leaves = today? These leaves have no a priori semantics, they do not make anything *in = the configuration* disappear or deactivate. Lada >=20 > K. >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From phil@juniper.net Mon Mar 11 11:24:20 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B405A21F8D09 for ; Mon, 11 Mar 2013 11:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.677 X-Spam-Level: X-Spam-Status: No, score=-6.677 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lu4T5sV6nfNj for ; Mon, 11 Mar 2013 11:24:18 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id B7AB321F8D07 for ; Mon, 11 Mar 2013 11:24:15 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUT4hT0srGlefBjf/lmUlahhLsLyWjCwT@postini.com; Mon, 11 Mar 2013 11:24:18 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 11 Mar 2013 11:21:35 -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 r2BILY378303; Mon, 11 Mar 2013 11:21:34 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id r2BIKmb8089255; Mon, 11 Mar 2013 14:21:03 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201303111821.r2BIKmb8089255@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <4240EC45-3F1F-43AF-996E-7F7D0430B649@nic.cz> Date: Mon, 11 Mar 2013 14:20:48 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:24:20 -0000 Ladislav Lhotka writes: >I meant that it would affect existing concepts in YANG, of course depending on the preci >se semantics of that attribute. must/when was already mentioned, and another question I >have is about data model defaults: if a subtree is tagged as disabled, should the server > still assume that all default values in that subtree are operationally active? The inactive configuration subtrees are conceptually not in the configuration, every validation and implementation (of a config) decision should ignore them. This means that must/when as well as defaults should operate as if the inactive configuration were deleted. Thanks, Phil From lhotka@nic.cz Mon Mar 11 11:36:25 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B8321F8E17 for ; Mon, 11 Mar 2013 11:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6nO6b1nR8bR for ; Mon, 11 Mar 2013 11:36:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFBE21F8DF0 for ; Mon, 11 Mar 2013 11:36:24 -0700 (PDT) Received: from [IPv6:2001:df8::16:b17c:b30a:6830:f3a9] (unknown [IPv6:2001:df8:0:16:b17c:b30a:6830:f3a9]) by mail.nic.cz (Postfix) with ESMTPSA id 49EDF140509; Mon, 11 Mar 2013 19:36:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1363026983; bh=/vRPxETtdLGBKidRRz/lWpLXQ1z82k8K4/0aLXNjsMk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=oUSEiKxEuCQDZ0yd+kaR7n2AlzcRlI+vjHss4hyxRDvqogy5YeIbBPhzCMq8HEJIV Uw58ar2Plr81EdaJ2/VP1322U8qzzxdSANow9vJIqUbJ0bvYaqCmjVB/WSZExMIrYT vztrKBiFXU2BCpBI+KA2LGgZENQV8HKkXso0Q1D0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <201303111821.r2BIKmb8089255@idle.juniper.net> Date: Mon, 11 Mar 2013 14:36:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6CEFF3B6-9955-491B-9458-ED15A21BF8A1@nic.cz> References: <201303111821.r2BIKmb8089255@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:36:25 -0000 On Mar 11, 2013, at 2:20 PM, Phil Shafer wrote: > Ladislav Lhotka writes: >> I meant that it would affect existing concepts in YANG, of course = depending on the preci >> se semantics of that attribute. must/when was already mentioned, and = another question I=20 >> have is about data model defaults: if a subtree is tagged as = disabled, should the server >> still assume that all default values in that subtree are = operationally active? >=20 > The inactive configuration subtrees are conceptually not in the > configuration, every validation and implementation (of a config) > decision should ignore them. This means that must/when as well as > defaults should operate as if the inactive configuration were > deleted. Martin told me about their implementation, so it is like commenting out = part of the configuration. This should be OK, provided that all = validation etc. is done on the resulting config where the tagged parts = are removed. Lada >=20 > Thanks, > Phil -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From xiangli@seguesoft.com Mon Mar 11 11:46:17 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546F121F8EA8 for ; Mon, 11 Mar 2013 11:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+sOds0gakjq for ; Mon, 11 Mar 2013 11:46:16 -0700 (PDT) Received: from p3plsmtpa08-06.prod.phx3.secureserver.net (p3plsmtpa08-06.prod.phx3.secureserver.net [173.201.193.107]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA1A21F8EA5 for ; Mon, 11 Mar 2013 11:46:16 -0700 (PDT) Received: from [192.168.2.16] ([98.212.151.151]) by p3plsmtpa08-06.prod.phx3.secureserver.net with id AJmE1l00H3GEayi01JmFgE; Mon, 11 Mar 2013 11:46:15 -0700 Message-ID: <513E2676.9030607@seguesoft.com> Date: Mon, 11 Mar 2013 13:46:14 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: netmod@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] conditional enablement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:46:17 -0000 >Regardless, the reason why it's likely moot is because I think it'd be crazy to use must/when expressions to support conditional enablement, but my perspective >assumes what can be disabled is selected by NETCONF-client (not the data-modeler) That makes sense to me... For example, when I edit a Linux config file, I often comment or uncomment certain lines to quickly change the config. In these case, I may not want to delete the respective lines from the config file since I may use it in the future. It's my understanding this draft may eventually provide a solution for that. --Xiang From kwatsen@juniper.net Tue Mar 12 05:51:32 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A57921F8A53 for ; Tue, 12 Mar 2013 05:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkXFekBlfkvf for ; Tue, 12 Mar 2013 05:51:31 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id C501421F8A5E for ; Tue, 12 Mar 2013 05:51:31 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUT8k09P/sECy3FtrxQAr1mNVEHJRx2/+@postini.com; Tue, 12 Mar 2013 05:51:31 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 12 Mar 2013 05:50:09 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 12 Mar 2013 05:50:09 -0700 Received: from DB8EHSOBE010.bigfish.com (213.199.154.185) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 12 Mar 2013 05:59:30 -0700 Received: from mail27-db8-R.bigfish.com (10.174.8.248) by DB8EHSOBE010.bigfish.com (10.174.4.73) with Microsoft SMTP Server id 14.1.225.23; Tue, 12 Mar 2013 12:50:06 +0000 Received: from mail27-db8 (localhost [127.0.0.1]) by mail27-db8-R.bigfish.com (Postfix) with ESMTP id CB1041A00088 for ; Tue, 12 Mar 2013 12:50:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -5 X-BigFish: PS-5(zzbb2dI98dI9371I1432I4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275bhz2dh2a8h668h839h946he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h) Received: from mail27-db8 (localhost.localdomain [127.0.0.1]) by mail27-db8 (MessageSwitch) id 1363092597533958_26938; Tue, 12 Mar 2013 12:49:57 +0000 (UTC) Received: from DB8EHSMHS022.bigfish.com (unknown [10.174.8.227]) by mail27-db8.bigfish.com (Postfix) with ESMTP id 7F2F81E00045; Tue, 12 Mar 2013 12:49:57 +0000 (UTC) Received: from CH1PRD0511HT005.namprd05.prod.outlook.com (157.56.245.197) by DB8EHSMHS022.bigfish.com (10.174.4.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 12 Mar 2013 12:49:57 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.166]) by CH1PRD0511HT005.namprd05.prod.outlook.com ([10.255.159.40]) with mapi id 14.16.0275.006; Tue, 12 Mar 2013 12:49:44 +0000 From: Kent Watsen To: Xiang Li , "netmod@ietf.org" Thread-Topic: [netmod] conditional enablement Thread-Index: AQHOHojRzljLG/406EOfWFOjbI/wc5ihwAQA Date: Tue, 12 Mar 2013 12:49:44 +0000 Message-ID: In-Reply-To: <513E2676.9030607@seguesoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: <41E1DFB0984ECA4BA1A91EF70659F4B0@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%SEGUESOFT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [netmod] conditional enablement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 12:51:33 -0000 On 3/11/13 2:46 PM, "Xiang Li" wrote: > >That makes sense to me... > >For example, when I edit a Linux config file, I often comment or >uncomment certain lines to quickly change the config. In these case, I >may not want to >delete the respective lines from the config file since I may use it in >the future. > >It's my understanding this draft may eventually provide a solution for >that. That is correct. Based on yesterday's meeting and comments, we'll likely split the solution - one for commenting-out parts of the config tree and the other for temporal/triggered config=8A Thanks, Kent From mikebianc@aol.com Tue Mar 12 13:49:56 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9C411E80E9 for ; Tue, 12 Mar 2013 13:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdzDfZd+lo1O for ; Tue, 12 Mar 2013 13:49:55 -0700 (PDT) Received: from imr-da03.mx.aol.com (imr-da03.mx.aol.com [205.188.105.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFEF11E80D9 for ; Tue, 12 Mar 2013 13:49:55 -0700 (PDT) Received: from mtaout-mb03.r1000.mx.aol.com (mtaout-mb03.r1000.mx.aol.com [172.29.41.67]) by imr-da03.mx.aol.com (Outbound Mail Relay) with ESMTP id B4FD61C000158 for ; Tue, 12 Mar 2013 16:49:54 -0400 (EDT) Received: from mgs-aad01.mail.aol.com (mgs-aad01.mail.aol.com [205.188.178.60]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mb03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 71CF6E000189 for ; Tue, 12 Mar 2013 16:49:54 -0400 (EDT) Date: Tue, 12 Mar 2013 16:49:54 -0400 From: "mikebianc@aol.com" To: netmod@ietf.org Message-ID: <1676816339.53235.1363121394203.JavaMail.tomcat@mgs-aad01.mail.aol.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_53234_1196567721.1363121394202" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1363121394; bh=lHbKfOvaWUBTN+C6MWy5FFJkEuMNWd/JgGv2kgTs6tw=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=aEbGuR+4pPkieU51l40+SHzwveHLinwUHlyG9gb++cSdZTyu9GBp659JwEE1lRMUn 4SKZHkBIC+N7N3tBigiAcNvC6YVyZocHkcrBEmhHXTPOPlQHxNYbQmowOOCCIgkU45 LQ1hIgVz/eDOWC4ls/XcUkoM48yS2BtSsAijg684= X-AOL-SCOLL-SCORE: 0:2:435891680:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d2943513f94f20046 X-AOL-IP: 205.188.178.60 Subject: [netmod] Hope to start coding to this soon X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 20:49:56 -0000 ------=_Part_53234_1196567721.1363121394202 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable New to the list as of today, but after the call for operators in the meetin= g today, I wanted to say that I hope to start coding to this soon.=C2=A0 We= have already built a tool and associated web service to execute cmds on de= vices that uses a vendor API where it can or ssh (or telnet as a last resor= t) where it has to.=C2=A0 As the next step, I will be adding some tasks tha= t will return a vendor agnostic data structure and plan to leverage the YAN= G model (instead of making up one for myself).=C2=A0 As I start rolling on = this, I hope to be able to provide more operational-centric feedback. The current plan is to be able to be able to write front-end tools and scri= pts that expect a YANG model and have the web service API parse the text ou= tput of non-compliant vendors.=C2=A0 Ideally, as more vendors jump on board= , I can start ripping out this parsing code. Additionally, our current tool already has implemented pretty extensive ven= dor-agnostic acl handling, so I will also be looking at the LOE of converti= ng our structure to be compliant with these drafts. -Mike Biancaniello (see http://trigger.readthedocs.org/en/latest/api/acl.html iyi in the acl p= arsing.=C2=A0 all code is on https://github.com/aol/trigger ) ------=_Part_53234_1196567721.1363121394202 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable New to the list as of today, but after the call for operators in the meetin= g today, I wanted to say that I hope to start coding to this soon.  We= have already built a tool and associated web service to execute cmds on de= vices that uses a vendor API where it can or ssh (or telnet as a last resor= t) where it has to.  As the next step, I will be adding some tasks tha= t will return a vendor agnostic data structure and plan to leverage the YAN= G model (instead of making up one for myself).  As I start rolling on = this, I hope to be able to provide more operational-centric feedback.
The current plan is to be able to be able to write front-end tools and sc= ripts that expect a YANG model and have the web service API parse the text = output of non-compliant vendors.  Ideally, as more vendors jump on boa= rd, I can start ripping out this parsing code.

Additionally, our cur= rent tool already has implemented pretty extensive vendor-agnostic acl hand= ling, so I will also be looking at the LOE of converting our structure to b= e compliant with these drafts.

-Mike Biancaniello

(see http:/= /trigger.readthedocs.org/en/latest/api/acl.html iyi in the acl parsing.&nbs= p; all code is on https://github.com/aol/trigger )

------=_Part_53234_1196567721.1363121394202-- From j.schoenwaelder@jacobs-university.de Wed Mar 13 09:06:39 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B1421F8B20 for ; Wed, 13 Mar 2013 09:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.183 X-Spam-Level: X-Spam-Status: No, score=-103.183 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F83V9IbgZ8Hz for ; Wed, 13 Mar 2013 09:06:38 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3507621F86D9 for ; Wed, 13 Mar 2013 09:06:38 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B6D920BEC; Wed, 13 Mar 2013 17:06:37 +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 XcERHqsYtAuj; Wed, 13 Mar 2013 17:06:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0FCF320BE0; Wed, 13 Mar 2013 17:06:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0EFBB24EC3A8; Wed, 13 Mar 2013 17:06:50 +0100 (CET) Date: Wed, 13 Mar 2013 17:06:50 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org, Benoit Claise Message-ID: <20130313160649.GA74328@elstar.local> Mail-Followup-To: netmod@ietf.org, Benoit Claise MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] NETMOD @ IETF 86 summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 16:06:39 -0000 The NETMOD working group has met for 1.5 hours on Tuesday, March 12th, during the 86th IETF meeting. The meeting was attended by ~40 people. * The following documents draft-ietf-netmod-interfaces-cfg-09, draft-ietf-netmod-ip-cfg-09, draft-ietf-netmod-rfc6021-bis-00, and draft-ietf-netmod-iana-if-type-04 have been sent Benoit for processing them through the IESG. The routing document draft-ietf-netmod-routing-cfg-09 is to follow (waiting for David to finish the writeup). * The system data model draft-ietf-netmod-system-mgmt-05 is in WG last call and a number of issues have been brought up. WG meeting time was used to find out which issues require changes to the document. Once there is a revised I-D, we will need to run a 2nd WG last call. * The SNMP configuration data model draft-ietf-netmod-snmp-cfg-01 is in WG last call. A few minor issues have been identified that Martin and Juergen will work on. This document needs further reviews and likely a 2nd WG last call when a revised I-D is available. * A revised proposal for a set of data models for stateless packet filters was presented. Several people in the room expressed that they find this work is useful. * Lada presented briefly on the JSON mapping of YANG. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Wed Mar 13 14:10:59 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB25A21F8E48 for ; Wed, 13 Mar 2013 14:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdew1tvX+djn for ; Wed, 13 Mar 2013 14:10:58 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1592C21F8E3C for ; Wed, 13 Mar 2013 14:10:52 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id 17so2088291iea.26 for ; Wed, 13 Mar 2013 14:10:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=wwOYguTYa+qUftsMUyhLH/mODcg+vwzFDaTYVM/Uq/g=; b=fN3Kx3PIsxksYmtHwsuy21e+ahhPX2BHuLCUyHpNf9qPz9VT4XE9MrFx8oIMvbr9gZ V0GPduwGrziRI+WOdDH05awI6e+Cn/VRgl3xH4rJ+w0vCOdMTnX4+iUzRdlsaWOpDhsp SvlJoXGDWnJZUYgyb7JMoTuuO2cH8YXzQPj4wHfWa1EKKYKooqdB0q51w2sg+8pO132s BqK0f4FgP1BmQ0ZK3zufnwWCtnhkwj8YnsPjvsOiWII/ImQoIFrJklFraQpL9wH5OHdw r83tz5cGIkDSIRTJtPKrvq0n9KqqzYAsa6EnFbCdDzQSMeEH4VKE10NJNE0zF5CTMdsu U23Q== MIME-Version: 1.0 X-Received: by 10.50.17.131 with SMTP id o3mr18137030igd.112.1363209051512; Wed, 13 Mar 2013 14:10:51 -0700 (PDT) Received: by 10.231.93.6 with HTTP; Wed, 13 Mar 2013 14:10:51 -0700 (PDT) Date: Wed, 13 Mar 2013 14:10:51 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl9F12UhyLYBgCZwuCASxiqxBGmL0cmbKfHflpkcZVgVGC2NLBdhPBfdvSSmD4McLJRUweh Subject: [netmod] geopriv location X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 21:11:00 -0000 Hi, I have been looking at some geopriv RFCs and it appears that RFC 5870 (geo URI scheme) is probably most relevant, which has definitions and parameters for encoding a 2d or 3d location into a URI. If anybody supports adding additional admin strings to the ietf-system module then please send comments to the mailing list. Andy From andy@yumaworks.com Sat Mar 16 08:01:38 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D8821F8901 for ; Sat, 16 Mar 2013 08:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+vtCgY6GODF for ; Sat, 16 Mar 2013 08:01:38 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id AF81B21F8922 for ; Sat, 16 Mar 2013 08:01:29 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id c13so5410427ieb.23 for ; Sat, 16 Mar 2013 08:01:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=XwNvZLRMwJHQ1qqrtXUZ7gkOtZ+5RKSeSQQ4Sm3B3Ts=; b=oNfcfFhyK9aq8KTlkG/ZZ/ixWV/TicsNlM9bgNmw+aAasU4JdkNNVsJN2Ykp1xBiuu Sel273BuhE+hP0Wy6D+GHcAt/8rNGiq7rAdaAM5vch+tzdKkKE048AX7WSst7slfnYL9 Tf3P/qBnHyW+8SP1UV5RCVGl+NJn59HUqPq8nSf4RwPzgqY1exYoNVOwqXGYtNcZu22s HqyPiaU5+DDOhqPf0bQYhH8WBRjKD4mChhvdyobaKNT/+smMIYQHY0su3wpaPOXMwEJ/ XeU5B3LJabzbiyLaGwuZH7koKSlLowKz30fY5Ls9a9B33xBYnUZE/ajef0gZKyTQadTK zbFg== MIME-Version: 1.0 X-Received: by 10.50.7.69 with SMTP id h5mr3613546iga.69.1363446089214; Sat, 16 Mar 2013 08:01:29 -0700 (PDT) Received: by 10.231.93.6 with HTTP; Sat, 16 Mar 2013 08:01:28 -0700 (PDT) Date: Sat, 16 Mar 2013 08:01:28 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkG6jIMROCTwRussjxC/LDQIUwekxs3anaDNq8vkFpRK1MPbXw11fzfMxoYHxbZlQ2zy5WP Subject: [netmod] grouping for disabled leaf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 15:01:38 -0000 Hi, I was hoping the WG would resolve the enabled leaf (now inverted to disabled leaf) issues ASAP so we can update drafts accordingly. Since the WG decided not to add it to 6021bis, my question is which module and which RFC will it be in. This is simple stuff. It should not be difficult to finish a simple task like this because IETF administrivia might get in the way. Andy From j.schoenwaelder@jacobs-university.de Sat Mar 16 09:05:15 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C91121F850E for ; Sat, 16 Mar 2013 09:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv+RjcSEishQ for ; Sat, 16 Mar 2013 09:05:14 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 23FCC21F84E9 for ; Sat, 16 Mar 2013 09:05:14 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D67820C21; Sat, 16 Mar 2013 17:05:13 +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 98DLxrJOQKaN; Sat, 16 Mar 2013 17:05:13 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E05720C22; Sat, 16 Mar 2013 17:05:12 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 76A7524FFACB; Sat, 16 Mar 2013 17:05:26 +0100 (CET) Date: Sat, 16 Mar 2013 17:05:26 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20130316160526.GB26186@elstar.local> Mail-Followup-To: Andy Bierman , netmod@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] grouping for disabled leaf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 16:05:15 -0000 On Sat, Mar 16, 2013 at 08:01:28AM -0700, Andy Bierman wrote: > Hi, > > I was hoping the WG would resolve the enabled leaf > (now inverted to disabled leaf) issues ASAP so we can > update drafts accordingly. > > Since the WG decided not to add it to 6021bis, my question > is which module and which RFC will it be in. > > This is simple stuff. It should not be difficult to finish a simple task > like this because IETF administrivia might get in the way. Someone should write a yang module defining this grouping. Once we reach agreement that this module is the solution everybody wants (even though we have been putting so far enabled leafs everywhere), we will find a place for it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Sun Mar 17 12:40:29 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9AD21F8B74 for ; Sun, 17 Mar 2013 12:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwsnlMXMoJWH for ; Sun, 17 Mar 2013 12:40:29 -0700 (PDT) Received: from mail-ia0-x22d.google.com (mail-ia0-x22d.google.com [IPv6:2607:f8b0:4001:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E4C0021F8BD9 for ; Sun, 17 Mar 2013 12:40:22 -0700 (PDT) Received: by mail-ia0-f173.google.com with SMTP id h37so4680350iak.32 for ; Sun, 17 Mar 2013 12:40:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=WKFi1nxL7mCH0usGBwSJzODbmZcQhn/Y8eFI/cwjYY8=; b=oK/01f2rNZXVwNaX4vgCCS4jzp9tnQrIY4okuByaxaOI4S8ZofjNMZidQFGGVxQDr+ 9Ol5s2yCLoG91wrPnPhXnwEjpuxxy7DaPzvr72ASkWzcRLETcZsASE86ukYJT0vncakt vBHDqpfuO921IpqdBJEQnXS9IZU1pGgO92MzWRyaisc2FHJGIzgP9MK+9BOVSWK2ZZoq jWm57dbS/GFO6yhGhVpeifq+hZAoumslP/6lUHUkWE50XnYq0T3oy3NGOwQVWNE0Vrex 6b44/4ANpicG5A6PAcbGSAoT/KmRsCAADWWJt/1f+zzaky2AqxktEr27+Nnb6sn5a75z 9Mbg== MIME-Version: 1.0 X-Received: by 10.50.7.69 with SMTP id h5mr5140846iga.69.1363549222309; Sun, 17 Mar 2013 12:40:22 -0700 (PDT) Received: by 10.231.93.6 with HTTP; Sun, 17 Mar 2013 12:40:22 -0700 (PDT) Date: Sun, 17 Mar 2013 12:40:22 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: multipart/mixed; boundary=089e0111be2a07aac804d8240b76 X-Gm-Message-State: ALoCoQktgm0t1i1hK0ZdedFgh1ZstC6QPnoahNN/IR5QXDwxrwxx3Wl19IWfFX5UhH7txCy9ejMe Subject: [netmod] ietf-yang-groupings proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 19:40:29 -0000 --089e0111be2a07aac804d8240b76 Content-Type: text/plain; charset=ISO-8859-1 Hi, Here is a first pass at the YANG module that Juergen asked for.... Andy --089e0111be2a07aac804d8240b76 Content-Type: application/octet-stream; name="ietf-yang-groupings.yang" Content-Disposition: attachment; filename="ietf-yang-groupings.yang" Content-Transfer-Encoding: base64 X-Attachment-Id: f_heelzxqa0 bW9kdWxlIGlldGYteWFuZy1ncm91cGluZ3MgewoKICAvLyBOb3RlIHRoYXQgdGhpcyBuYW1lc3Bh Y2Ugc2hvdWxkIG5vdCBiZSBhcHBlYXIgaW4KICAvLyBkYXRhIG5vZGVzIGJlY2F1c2UgdGhpcyBt b2R1bGUgTVVTVCBOT1QgY29udGFpbgogIC8vIGFueSB0b3AtbGV2ZWwgZGF0YWRlZi1zdG10LCBy cGMtc3RtdCwgb3Igbm90aWZpY2F0aW9uLXN0bXQKICBuYW1lc3BhY2UgInVybjppZXRmOnBhcmFt czp4bWw6bnM6eWFuZzppZXRmLXlhbmctZ3JvdXBpbmdzIjsKICBwcmVmaXggInlhbmctZ3JwIjsK CiAgb3JnYW5pemF0aW9uCiAgICJJRVRGIE5FVE1PRCAoTkVUQ09ORiBEYXRhIE1vZGVsaW5nIExh bmd1YWdlKSBXb3JraW5nIEdyb3VwIjsKCiAgY29udGFjdAogICAiV0cgV2ViOiAgIDxodHRwOi8v dG9vbHMuaWV0Zi5vcmcvd2cvbmV0bW9kLz4KICAgIFdHIExpc3Q6ICA8bWFpbHRvOm5ldG1vZEBp ZXRmLm9yZz4KCiAgICBXRyBDaGFpcjogRGF2aWQgS2Vzc2VucwogICAgICAgICAgICAgIDxtYWls dG86ZGF2aWQua2Vzc2Vuc0Buc24uY29tPgoKICAgIFdHIENoYWlyOiBKdWVyZ2VuIFNjaG9lbndh ZWxkZXIKICAgICAgICAgICAgICA8bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVy c2l0eS5kZT4KCiAgICBFZGl0b3I6ICAgQW5keSBCaWVybWFuCiAgICAgICAgICAgICAgPG1haWx0 bzphbmR5QHl1bWF3b3Jrcy5jb20+IjsKCiAgZGVzY3JpcHRpb24KICAgIlRoaXMgbW9kdWxlIGNv bnRhaW5zIGEgY29sbGVjdGlvbiBvZiBnZW5lcmFsbHkgdXNlZnVsCiAgICBZQU5HIGdyb3VwaW5n IHN0YXRlbWVudHMuCgogICAgQ29weXJpZ2h0IChjKSAyMDEzIElFVEYgVHJ1c3QgYW5kIHRoZSBw ZXJzb25zIGlkZW50aWZpZWQgYXMKICAgIGF1dGhvcnMgb2YgdGhlIGNvZGUuICBBbGwgcmlnaHRz IHJlc2VydmVkLgoKICAgIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5h cnkgZm9ybXMsIHdpdGggb3IKICAgIHdpdGhvdXQgbW9kaWZpY2F0aW9uLCBpcyBwZXJtaXR0ZWQg cHVyc3VhbnQgdG8sIGFuZCBzdWJqZWN0CiAgICB0byB0aGUgbGljZW5zZSB0ZXJtcyBjb250YWlu ZWQgaW4sIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlCiAgICBzZXQgZm9ydGggaW4gU2VjdGlv biA0LmMgb2YgdGhlIElFVEYgVHJ1c3QncyBMZWdhbCBQcm92aXNpb25zCiAgICBSZWxhdGluZyB0 byBJRVRGIERvY3VtZW50cwogICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5m bykuCgogICAgVGhpcyB2ZXJzaW9uIG9mIHRoaXMgWUFORyBtb2R1bGUgaXMgcGFydCBvZiBSRkMg WFhYWDsgc2VlCiAgICB0aGUgUkZDIGl0c2VsZiBmb3IgZnVsbCBsZWdhbCBub3RpY2VzLiI7Cgog IHJldmlzaW9uIDIwMTMtMDMtMTcgewogICAgZGVzY3JpcHRpb24KICAgICAiSW5pdGlhbCB2ZXJz aW9uOgogICAgICAtIGRpc2FibGVkIjsKICAgIHJlZmVyZW5jZQogICAgICJSRkMgWFhYWDogQ29t bW9uIFlBTkcgRGF0YSBUeXBlcyI7CiAgfQoKICBncm91cGluZyBkaXNhYmxlZCB7CiAgICBkZXNj cmlwdGlvbgogICAgICAiQ29udGFpbnMgYW4gb2JqZWN0IHRvIGVuYWJsZSBvciBkaXNhYmxlIHNl Y3Rpb25zCiAgICAgICBvbiB0aGUgcnVubmluZyBjb25maWd1cmF0aW9uIGRhdGFzdG9yZS4gVGhl IGRhdGEgbW9kZWwKICAgICAgIGRlc2lnbmVyIE1VU1QgaW5jbHVkZSBhIHJlZmluZS1zdG10IHdp dGggYSBuZXcKICAgICAgIGRlc2NyaXB0aW9uLXN0bXQgKHdpdGhpbiB0aGUgdXNlcy1zdG10KSBm b3IgdGhpcyBncm91cGluZy4KICAgICAgIEl0IE1VU1QgcHJlY2lzZWx5IGRlZmluZXMgdGhlIHNj b3BlIG9mIHRoZSAnZGlzYWJsZWQnIGxlYWYuCgogICAgICAgICAgc2VydmVyIHsKICAgICAgICAg ICAgLi4uCiAgICAgICAgICAgIHVzZXMgeWFuZy1ncnA6ZGlzYWJsZWQgewogICAgICAgICAgICAg IHJlZmluZSBkaXNhYmxlZCB7CiAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAg ICAgICAgICAnSW5kaWNhdGVzIHdoZXRoZXIgdGhlIE5UUCBzZXJ2ZXIgaWRlbnRpZmllZCBieQog ICAgICAgICAgICAgICAgICAgdGhpcyBsaXN0IGVudHJ5IGlzIGRpc2FibGVkIGZvciB1c2Ugb3Ig bm90Lic7CiAgICAgICAgICAgICAgfQogICAgICAgICAgICB9CiAgICAgICAgIH0KICAgICAgIjsK CiAgICBsZWFmIGRpc2FibGVkIHsKICAgICAgdHlwZSBlbXB0eTsKICAgICAgY29uZmlnIHRydWU7 CiAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgIlRoaXMgb2JqZWN0IGFsbG93cyBvcGVyYXRvcnMg dG8gZGlzYWJsZSBhIHNlY3Rpb24gb2YKICAgICAgICAgdGhlIHJ1bm5pbmcgY29uZmlndXJhdGlv biBkYXRhc3RvcmUgd2l0aG91dCBkZWxldGluZwogICAgICAgICB0aGUgYWZmZWN0ZWQgY29uZmln dXJhdGlvbiBkYXRhLiI7CiAgICB9CiAgfQoKfQoK --089e0111be2a07aac804d8240b76-- From j.schoenwaelder@jacobs-university.de Mon Mar 18 02:08:07 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353EE21F8920 for ; Mon, 18 Mar 2013 02:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHtQtJyIx+ZA for ; Mon, 18 Mar 2013 02:08:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E5B5C21F8916 for ; Mon, 18 Mar 2013 02:08:05 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EFCB520BD7; Mon, 18 Mar 2013 10:08:04 +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 hNQjQjQ7QzP2; Mon, 18 Mar 2013 10:08:04 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 743BF20968; Mon, 18 Mar 2013 10:08:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1866925014B6; Mon, 18 Mar 2013 10:08:17 +0100 (CET) Date: Mon, 18 Mar 2013 10:08:16 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20130318090816.GA32360@elstar.local> Mail-Followup-To: Andy Bierman , netmod@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-groupings proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 09:08:07 -0000 On Sun, Mar 17, 2013 at 12:40:22PM -0700, Andy Bierman wrote: > Hi, > > Here is a first pass at the YANG module that Juergen asked for.... > Thanks. Perhaps the example should not be NTP specific, e.g. something like this? ... XYZ { ... uses yang-grp:disabled { refine disabled { description 'Indicates whether the service XYZ is disabled for use or not.'; } } } Anyway, it would be nice if others can comment on the proposal to see whether we have concensus that this is the direction we want to go. Note that we have a number of 'enabled' leafs in the IDs we just shipped to Benoit. My understanding is that the enabled leafs are kind of explicit since they are visible while the disabled leafs are kind of invisible; they require to read the data model to know where they can be placed. Is this is a fair statement? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From per@tail-f.com Mon Mar 18 05:15:50 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C41C21F8D26 for ; Mon, 18 Mar 2013 05:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nG+cTa04rE8T for ; Mon, 18 Mar 2013 05:15:50 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBC921F8717 for ; Mon, 18 Mar 2013 05:15:50 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8CC201200174; Mon, 18 Mar 2013 13:15:48 +0100 (CET) Message-ID: <51470574.3000800@tail-f.com> Date: Mon, 18 Mar 2013 13:15:48 +0100 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110120 Thunderbird/3.1.7 MIME-Version: 1.0 To: Andy Bierman , netmod@ietf.org References: <20130318090816.GA32360@elstar.local> In-Reply-To: <20130318090816.GA32360@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] ietf-yang-groupings proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 12:15:50 -0000 On 2013-03-18 10:08, Juergen Schoenwaelder wrote: > > Anyway, it would be nice if others can comment on the proposal to see > whether we have concensus that this is the direction we want to go. > Note that we have a number of 'enabled' leafs in the IDs we just > shipped to Benoit. > > My understanding is that the enabled leafs are kind of explicit since > they are visible while the disabled leafs are kind of invisible; they > require to read the data model to know where they can be placed. Is > this is a fair statement? Well (assuming that with "enabled leafs" you mean leafs named "enabled" of type boolean), if the enabled leaf has a default, it depends on the default-handling mode - with "explicit" or "trim", they are as semi- invisible as type-empty leafs, although unlike type-empty, they can of course always be "found" with default-handling mode "report-all". I'm not sure how important this aspect is though, I would say that knowledge of the data model is required in any case. IMO the big difference between boolean "enabled" and type-empty "disabled" is that the latter *enforces* a "default" of enabled, since a type-empty leaf can't "exist by default". That might be a desirable property, but I don't think so - I believe we will see cases where a default of disabled is more "natural"/useful. With a boolean, the default can be 'refine'd in the 'uses', whether there is an existing default or not. Another thing to consider is the "operational" aspect, i.e. 1. How do you disable XYZ when it is enabled? a) Set the 'enabled' leaf to "false". b) Create the 'disabled' leaf. 2. How do you enable XYZ when it is disabled? a) Set the 'enabled' leaf to "true". b) Delete the 'disabled' leaf. Personally I have a strong preference for the 'a's here, in particular 2b) is rather "weird" I think. That said, I think this whole idea of having a "standard" grouping just to standardize the name and type of a single leaf is pretty... - well, silly. Can't we just decide on one alternative and stick to it? I guess it's good if it's written down somewhere - maybe it should go into an update of RFC 6087? --Per Hedeland From lhotka@nic.cz Mon Mar 18 06:05:54 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0724521F8D9C for ; Mon, 18 Mar 2013 06:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdWeE8WoCvGm for ; Mon, 18 Mar 2013 06:05:52 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6D59821F8D9A for ; Mon, 18 Mar 2013 06:05:52 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C27AF13F7BB; Mon, 18 Mar 2013 14:05:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1363611950; bh=6PX1Eib5zyY1QKdhDGB+NZXFfZYkHXJpsXB1lCU4vy8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QhxfsxYyOJatXAb4lcqTXlCl5z6uRx1TOTC46J5WmSzLKiKNqJ7E+DVMZpohqdH0p HuwC1KyN4Vsaz56yGgpDyvRKX7OfSbPOjhrA/W5Gu2e0xQS7VkX1LPuj7Gbqv0x7pX ieud6o8Kc8bs1a8G1rgxY/mtxFp887NeR1jgBjJ0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: <51470574.3000800@tail-f.com> Date: Mon, 18 Mar 2013 14:05:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130318090816.GA32360@elstar.local> <51470574.3000800@tail-f.com> To: Per Hedeland X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-groupings proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 13:05:54 -0000 On Mar 18, 2013, at 1:15 PM, Per Hedeland wrote: > On 2013-03-18 10:08, Juergen Schoenwaelder wrote: >>=20 >> Anyway, it would be nice if others can comment on the proposal to see >> whether we have concensus that this is the direction we want to go. >> Note that we have a number of 'enabled' leafs in the IDs we just >> shipped to Benoit. >>=20 >> My understanding is that the enabled leafs are kind of explicit since >> they are visible while the disabled leafs are kind of invisible; they >> require to read the data model to know where they can be placed. Is >> this is a fair statement? >=20 > Well (assuming that with "enabled leafs" you mean leafs named = "enabled" > of type boolean), if the enabled leaf has a default, it depends on the > default-handling mode - with "explicit" or "trim", they are as semi- > invisible as type-empty leafs, although unlike type-empty, they can of > course always be "found" with default-handling mode "report-all". I'm > not sure how important this aspect is though, I would say that = knowledge > of the data model is required in any case. I agree. The advantage of the empty "disabled" leaf is that it works = always the same, no matter what the default-handling mode is. >=20 > IMO the big difference between boolean "enabled" and type-empty > "disabled" is that the latter *enforces* a "default" of enabled, since = a > type-empty leaf can't "exist by default". That might be a desirable > property, but I don't think so - I believe we will see cases where a > default of disabled is more "natural"/useful. With a boolean, the > default can be 'refine'd in the 'uses', whether there is an existing > default or not. This is a valid point, although the modeller can do one of the following = things to overcome this limitation: 1. Define the parent container as "presence". The client can then enable = the subtree/service by including the container element, but also disable = it secondarily by using while still keeping the subtree in = the configuration. 2. One can simply forget about the existence of the grouping and define = an "enabled" leaf from scratch. Refining a grouping that contains only = one leaf makes little sense to me.=20 >=20 > Another thing to consider is the "operational" aspect, i.e. >=20 > 1. How do you disable XYZ when it is enabled? >=20 > a) Set the 'enabled' leaf to "false". >=20 > b) Create the 'disabled' leaf. >=20 > 2. How do you enable XYZ when it is disabled? >=20 > a) Set the 'enabled' leaf to "true". Or delete it. In fact, the "trim" defaults-handling mode will delete it = anyway. >=20 > b) Delete the 'disabled' leaf. >=20 > Personally I have a strong preference for the 'a's here, in particular > 2b) is rather "weird" I think. Weirdness is subjective, one could also argue that "a" is weird - Phil = has already pointed out that the "enabled" element will mostly be seen = in the config in the form false, i.e. to *disable* = the parent subtree. >=20 > That said, I think this whole idea of having a "standard" grouping = just > to standardize the name and type of a single leaf is pretty... - well, > silly. Can't we just decide on one alternative and stick to it? I = guess > it's good if it's written down somewhere - maybe it should go into an > update of RFC 6087? Given the ubiquity of this leaf, the grouping would IMO help readability = of modules. I have actually a proposal, namely to provide two groupings: one with = the empty "disabled" leaf, and another with boolean "enabled" leaf but = with the default of "false". This way, the modeller can choose the = semantics (also in combination with presence containers) that is more = apropriate for a given situation. Lada >=20 > --Per Hedeland > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From per@tail-f.com Mon Mar 18 07:21:34 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD62D21F8F0D for ; Mon, 18 Mar 2013 07:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKxmWohPmh-l for ; Mon, 18 Mar 2013 07:21:33 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5B83B21F8F0A for ; Mon, 18 Mar 2013 07:21:32 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 668AB1200174; Mon, 18 Mar 2013 15:21:31 +0100 (CET) Message-ID: <514722EB.3080002@tail-f.com> Date: Mon, 18 Mar 2013 15:21:31 +0100 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110120 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ladislav Lhotka References: <20130318090816.GA32360@elstar.local> <51470574.3000800@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-groupings proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 14:21:34 -0000 On 2013-03-18 14:05, Ladislav Lhotka wrote: > > On Mar 18, 2013, at 1:15 PM, Per Hedeland wrote: >> >> IMO the big difference between boolean "enabled" and type-empty >> "disabled" is that the latter *enforces* a "default" of enabled, since a >> type-empty leaf can't "exist by default". That might be a desirable >> property, but I don't think so - I believe we will see cases where a >> default of disabled is more "natural"/useful. With a boolean, the >> default can be 'refine'd in the 'uses', whether there is an existing >> default or not. > > This is a valid point, although the modeller can do one of the following things to overcome this limitation: > > 1. Define the parent container as "presence". The client can then enable the subtree/service by including the container element, but also disable it secondarily by using while still keeping the subtree in the configuration. > > 2. One can simply forget about the existence of the grouping and define an "enabled" leaf from scratch. Refining a grouping that contains only one leaf makes little sense to me. We are already required to refine it to provide a description. And now we have 3 completely different "standard" ways of modeling "enablement", just to be able to choose the default. >> 2. How do you enable XYZ when it is disabled? >> >> a) Set the 'enabled' leaf to "true". > > Or delete it. In fact, the "trim" defaults-handling mode will delete it anyway. Assuming the default is (known to be) "true", yes. Setting it to "true" always works (though of course there is a distinction between that and deleting in "explicit" mode). >> b) Delete the 'disabled' leaf. >> >> Personally I have a strong preference for the 'a's here, in particular >> 2b) is rather "weird" I think. > > Weirdness is subjective, Yes, that is what wording like "personally" and "I think" was intended to convey. > one could also argue that "a" is weird - Phil has already pointed out that the "enabled" element will mostly be seen in the config in the form false, i.e. to *disable* the parent subtree. Again assuming that the default is (known to be) "true" - and your version of enable for "weird".:-) (I do subjectively agree about the weirdness of that perfectly valid operation.) >> That said, I think this whole idea of having a "standard" grouping just >> to standardize the name and type of a single leaf is pretty... - well, >> silly. Can't we just decide on one alternative and stick to it? I guess >> it's good if it's written down somewhere - maybe it should go into an >> update of RFC 6087? > > Given the ubiquity of this leaf, the grouping would IMO help readability of modules. Hm, so let's say we have consensus for type-empty "disabled". Without grouping: ... XYZ { leaf disabled { type empty; description 'Indicates whether the service XYZ is disabled for use or not.'; } } With grouping: ... XYZ { uses yang-grp:disabled { refine disabled { description 'Indicates whether the service XYZ is disabled for use or not.'; } } } Looks like more text with less information to me, I really can't see how that helps readability. The only value (if any) *I* can see with a grouping is standardization, and as we both have pointed out, you don't get a standard that covers all use cases with type-empty "disabled". > I have actually a proposal, namely to provide two groupings: one with the empty "disabled" leaf, and another with boolean "enabled" leaf but with the default of "false". This way, the modeller can choose the semantics (also in combination with presence containers) that is more apropriate for a given situation. So, from my point of view, I'm afraid I can't see any value at all with such a proposal. --Per From lhotka@nic.cz Mon Mar 18 07:53:07 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D1521F8F25 for ; Mon, 18 Mar 2013 07:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id db9bWDxNjlng for ; Mon, 18 Mar 2013 07:53:07 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id AF2BD21F8F3E for ; Mon, 18 Mar 2013 07:53:06 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id F23B113F7BB; Mon, 18 Mar 2013 15:53:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1363618386; bh=SNnkvGYkEdxqeMVAxKH8jdeT4Gg2yE5yPKeXfObV/X8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=O82tP8QshnZ9D7/8J2i3K9ye1gtiH1hnChxLRRJuLI/ot7TIaEWNWNjDn75iJvf+O YWiR25x+HO1CjI5Iw+9lwxlpAeaqxbnX5TFk5Ualo7hDKNj7WWVkYAnvuThR3jnV96 I4lgXAcmG0Q0zWus+Yc8KUpRvWIkUaIQstgiLDHU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: <514722EB.3080002@tail-f.com> Date: Mon, 18 Mar 2013 15:53:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5BF42BD6-C864-4624-AFE9-2A1180F5C770@nic.cz> References: <20130318090816.GA32360@elstar.local> <51470574.3000800@tail-f.com> <514722EB.3080002@tail-f.com> To: Per Hedeland X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-groupings proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 14:53:07 -0000 On Mar 18, 2013, at 3:21 PM, Per Hedeland wrote: > On 2013-03-18 14:05, Ladislav Lhotka wrote: >>=20 >> On Mar 18, 2013, at 1:15 PM, Per Hedeland wrote: >>>=20 >>> IMO the big difference between boolean "enabled" and type-empty >>> "disabled" is that the latter *enforces* a "default" of enabled, = since a >>> type-empty leaf can't "exist by default". That might be a desirable >>> property, but I don't think so - I believe we will see cases where a >>> default of disabled is more "natural"/useful. With a boolean, the >>> default can be 'refine'd in the 'uses', whether there is an existing >>> default or not. >>=20 >> This is a valid point, although the modeller can do one of the = following things to overcome this limitation: >>=20 >> 1. Define the parent container as "presence". The client can then = enable the subtree/service by including the container element, but also = disable it secondarily by using while still keeping the = subtree in the configuration. >>=20 >> 2. One can simply forget about the existence of the grouping and = define an "enabled" leaf from scratch. Refining a grouping that contains = only one leaf makes little sense to me.=20 >=20 > We are already required to refine it to provide a description. And now > we have 3 completely different "standard" ways of modeling = "enablement", > just to be able to choose the default. Oh yes, at first I didn't notice the specific description is a MUST. = With it, the grouping is IMO pretty much useless. I guess the following = generic description (to be included in the grouping) could suffice for = 90 % of cases: "Indicates whether the subsystem/service represented by the parent node = is disabled for use or not." =85 >>=20 >> Given the ubiquity of this leaf, the grouping would IMO help = readability of modules. >=20 > Hm, so let's say we have consensus for type-empty "disabled". Without > grouping: >=20 > ... XYZ { > leaf disabled { > type empty; > description > 'Indicates whether the service XYZ is disabled > for use or not.'; > } > } >=20 > With grouping: >=20 > ... XYZ { > uses yang-grp:disabled { > refine disabled { > description > 'Indicates whether the service XYZ is disabled > for use or not.'; > } > } > } Sure, the second version is really clumsy and would certainly mean a = serious confusion for non-expert readers. I assumed the standard use = would be just uses yang-grp:disabled; If not, I agree with you that the grouping is silly, and doubly so = because it is the only content of that module. Lada >=20 > Looks like more text with less information to me, I really can't see = how > that helps readability. The only value (if any) *I* can see with a > grouping is standardization, and as we both have pointed out, you = don't > get a standard that covers all use cases with type-empty "disabled". >=20 >> I have actually a proposal, namely to provide two groupings: one with = the empty "disabled" leaf, and another with boolean "enabled" leaf but = with the default of "false". This way, the modeller can choose the = semantics (also in combination with presence containers) that is more = apropriate for a given situation. >=20 > So, from my point of view, I'm afraid I can't see any value at all = with > such a proposal. >=20 > --Per -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Mar 18 08:57:54 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CD621F8CCE for ; Mon, 18 Mar 2013 08:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDTVXHJMi4JH for ; Mon, 18 Mar 2013 08:57:53 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7D621F8CE5 for ; Mon, 18 Mar 2013 08:57:53 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id 10so7227253ied.30 for ; Mon, 18 Mar 2013 08:57:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=D9yAEPk+UHrKBQbDJ85TZTA/lCgNHyXaVKAlg50ZOBY=; b=Kdynr9es9y7ltTEdd6CaMeV2OhPjygPyoyjoRuz6sQnggMXa866/8z51yfY8hdC5Yp Xzjqtmw4tefgTsijevIq1afhsfXKRNv5CwTKDm8IS88WBaN1VYD2pVU9SovyQkLi35Kh 0w7pe7yv2Icl/7R44+ytYJk2O//kelzMLvp/OI+nGsBieXhS1cF7r4NpQOMg19reYSrp vsCSjNtGv7AlWfoWytUUZOg5vixFqqzbg0Zh/4x1N388lwumNczI+fOHKvVVhqmtz3vm 5pgVYlr4dO6VtmKmV8DVNT7OoAMh4wU3uCkbh4zFAbk0dZfP1QFLxO4oQ2dfNtAegS8k ExXQ== MIME-Version: 1.0 X-Received: by 10.50.12.137 with SMTP id y9mr6346897igb.57.1363622272833; Mon, 18 Mar 2013 08:57:52 -0700 (PDT) Received: by 10.231.93.6 with HTTP; Mon, 18 Mar 2013 08:57:52 -0700 (PDT) In-Reply-To: <5BF42BD6-C864-4624-AFE9-2A1180F5C770@nic.cz> References: <20130318090816.GA32360@elstar.local> <51470574.3000800@tail-f.com> <514722EB.3080002@tail-f.com> <5BF42BD6-C864-4624-AFE9-2A1180F5C770@nic.cz> Date: Mon, 18 Mar 2013 08:57:52 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlGInK4i9HvEXSqydIwMozEqkm5MuAzkMeRxhvuyH7+zF4TFnzxMI/GvnonLQzdqBYiE2Aq Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-groupings proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 15:57:54 -0000 Hi, I was wondering if it would be better to mandate: * disabled MUST NOT appear as a top-level leaf * disabled just affects its parent container or list But since the name 'disabled' is going to be in the XML namespace of the modules using the grouping, there is really no way to identify this leaf as special other than reserving the name 'disabled'. So any vendor leaf that happens to match the name we pick will be incorrectly assumed to be this special leaf. Maybe a YANG extension to identify such a leaf would be better: leaf disabled { yang:disable-leaf; type empty; ..... } Or maybe we punt and say there is nothing machine-readable. Just a bunch of unrelated ad-hoc leafs and not have any grouping. Andy On Mon, Mar 18, 2013 at 7:53 AM, Ladislav Lhotka wrote: > > On Mar 18, 2013, at 3:21 PM, Per Hedeland wrote: > >> On 2013-03-18 14:05, Ladislav Lhotka wrote: >>> >>> On Mar 18, 2013, at 1:15 PM, Per Hedeland wrote: >>>> >>>> IMO the big difference between boolean "enabled" and type-empty >>>> "disabled" is that the latter *enforces* a "default" of enabled, since= a >>>> type-empty leaf can't "exist by default". That might be a desirable >>>> property, but I don't think so - I believe we will see cases where a >>>> default of disabled is more "natural"/useful. With a boolean, the >>>> default can be 'refine'd in the 'uses', whether there is an existing >>>> default or not. >>> >>> This is a valid point, although the modeller can do one of the followin= g things to overcome this limitation: >>> >>> 1. Define the parent container as "presence". The client can then enabl= e the subtree/service by including the container element, but also disable = it secondarily by using while still keeping the subtree in the = configuration. >>> >>> 2. One can simply forget about the existence of the grouping and define= an "enabled" leaf from scratch. Refining a grouping that contains only one= leaf makes little sense to me. >> >> We are already required to refine it to provide a description. And now >> we have 3 completely different "standard" ways of modeling "enablement", >> just to be able to choose the default. > > Oh yes, at first I didn't notice the specific description is a MUST. With= it, the grouping is IMO pretty much useless. I guess the following generic= description (to be included in the grouping) could suffice for 90 % of cas= es: > > "Indicates whether the subsystem/service represented by the parent node i= s disabled for use or not." > > =85 > >>> >>> Given the ubiquity of this leaf, the grouping would IMO help readabilit= y of modules. >> >> Hm, so let's say we have consensus for type-empty "disabled". Without >> grouping: >> >> ... XYZ { >> leaf disabled { >> type empty; >> description >> 'Indicates whether the service XYZ is disabled >> for use or not.'; >> } >> } >> >> With grouping: >> >> ... XYZ { >> uses yang-grp:disabled { >> refine disabled { >> description >> 'Indicates whether the service XYZ is disabled >> for use or not.'; >> } >> } >> } > > Sure, the second version is really clumsy and would certainly mean a seri= ous confusion for non-expert readers. I assumed the standard use would be j= ust > > uses yang-grp:disabled; > > If not, I agree with you that the grouping is silly, and doubly so becaus= e it is the only content of that module. > > Lada > > >> >> Looks like more text with less information to me, I really can't see how >> that helps readability. The only value (if any) *I* can see with a >> grouping is standardization, and as we both have pointed out, you don't >> get a standard that covers all use cases with type-empty "disabled". >> >>> I have actually a proposal, namely to provide two groupings: one with t= he empty "disabled" leaf, and another with boolean "enabled" leaf but with = the default of "false". This way, the modeller can choose the semantics (al= so in combination with presence containers) that is more apropriate for a g= iven situation. >> >> So, from my point of view, I'm afraid I can't see any value at all with >> such a proposal. >> >> --Per > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From lhotka@nic.cz Mon Mar 18 09:26:22 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC5021F8DAB for ; Mon, 18 Mar 2013 09:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAiTd+DDtHp5 for ; Mon, 18 Mar 2013 09:26:12 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3C221F8DB7 for ; Mon, 18 Mar 2013 09:24:21 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D821E13F7BB; Mon, 18 Mar 2013 17:24:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1363623860; bh=Lu8ANQqaZArHBW1kk05s8a4KOagoxVUNU5tCk7cla8c=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=kRf94RPjns98g4yuvvBV5E7W1r5ZmLQXBLt7Rxb5IYKeSzPpCNDNdbIOlvgiLjrjE SLZyHb2igATjeD9zeGw3tWI8jNeWy+VSBsB2Ln/H3d5xPd9kyQtxDMJFtIUOQfIRUl Sg30/A+pYDj5bg5mQSyMRpaMeCBJcxAagUegUpAM= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 18 Mar 2013 17:24:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7A0FD098-AAFC-4113-B1A2-F771AC46521F@nic.cz> References: <20130318090816.GA32360@elstar.local> <51470574.3000800@tail-f.com> <514722EB.3080002@tail-f.com> <5BF42BD6-C864-4624-AFE9-2A1180F5C770@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-groupings proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:26:22 -0000 On Mar 18, 2013, at 4:57 PM, Andy Bierman wrote: > Hi, >=20 > I was wondering if it would be better to mandate: > * disabled MUST NOT appear as a top-level leaf > * disabled just affects its parent container or list Yes to both, and one more would be needed: * If the parent node is a container with presence, then the = "disabled" element overrides its presence. (A funny sentence indeed.:-) >=20 > But since the name 'disabled' is going to be in the XML > namespace of the modules using the grouping, > there is really no way to identify this leaf as special > other than reserving the name 'disabled'. > So any vendor leaf that happens to match the name > we pick will be incorrectly assumed to be this special leaf. Right. In a standard XML context, a global namespaced attribute would be = a perfect fit. >=20 > Maybe a YANG extension to identify such a leaf would > be better: >=20 > leaf disabled { > yang:disable-leaf; > type empty; > ..... > } Hmm, how could this extension help?=20 >=20 > Or maybe we punt and say there is nothing machine-readable. > Just a bunch of unrelated ad-hoc leafs and not have any > grouping. Yes, maybe we should just make it a matter of good style, as Per = suggested. Lada >=20 >=20 > Andy >=20 >=20 > On Mon, Mar 18, 2013 at 7:53 AM, Ladislav Lhotka = wrote: >>=20 >> On Mar 18, 2013, at 3:21 PM, Per Hedeland wrote: >>=20 >>> On 2013-03-18 14:05, Ladislav Lhotka wrote: >>>>=20 >>>> On Mar 18, 2013, at 1:15 PM, Per Hedeland wrote: >>>>>=20 >>>>> IMO the big difference between boolean "enabled" and type-empty >>>>> "disabled" is that the latter *enforces* a "default" of enabled, = since a >>>>> type-empty leaf can't "exist by default". That might be a = desirable >>>>> property, but I don't think so - I believe we will see cases where = a >>>>> default of disabled is more "natural"/useful. With a boolean, the >>>>> default can be 'refine'd in the 'uses', whether there is an = existing >>>>> default or not. >>>>=20 >>>> This is a valid point, although the modeller can do one of the = following things to overcome this limitation: >>>>=20 >>>> 1. Define the parent container as "presence". The client can then = enable the subtree/service by including the container element, but also = disable it secondarily by using while still keeping the = subtree in the configuration. >>>>=20 >>>> 2. One can simply forget about the existence of the grouping and = define an "enabled" leaf from scratch. Refining a grouping that contains = only one leaf makes little sense to me. >>>=20 >>> We are already required to refine it to provide a description. And = now >>> we have 3 completely different "standard" ways of modeling = "enablement", >>> just to be able to choose the default. >>=20 >> Oh yes, at first I didn't notice the specific description is a MUST. = With it, the grouping is IMO pretty much useless. I guess the following = generic description (to be included in the grouping) could suffice for = 90 % of cases: >>=20 >> "Indicates whether the subsystem/service represented by the parent = node is disabled for use or not." >>=20 >> =85 >>=20 >>>>=20 >>>> Given the ubiquity of this leaf, the grouping would IMO help = readability of modules. >>>=20 >>> Hm, so let's say we have consensus for type-empty "disabled". = Without >>> grouping: >>>=20 >>> ... XYZ { >>> leaf disabled { >>> type empty; >>> description >>> 'Indicates whether the service XYZ is disabled >>> for use or not.'; >>> } >>> } >>>=20 >>> With grouping: >>>=20 >>> ... XYZ { >>> uses yang-grp:disabled { >>> refine disabled { >>> description >>> 'Indicates whether the service XYZ is disabled >>> for use or not.'; >>> } >>> } >>> } >>=20 >> Sure, the second version is really clumsy and would certainly mean a = serious confusion for non-expert readers. I assumed the standard use = would be just >>=20 >> uses yang-grp:disabled; >>=20 >> If not, I agree with you that the grouping is silly, and doubly so = because it is the only content of that module. >>=20 >> Lada >>=20 >>=20 >>>=20 >>> Looks like more text with less information to me, I really can't see = how >>> that helps readability. The only value (if any) *I* can see with a >>> grouping is standardization, and as we both have pointed out, you = don't >>> get a standard that covers all use cases with type-empty "disabled". >>>=20 >>>> I have actually a proposal, namely to provide two groupings: one = with the empty "disabled" leaf, and another with boolean "enabled" leaf = but with the default of "false". This way, the modeller can choose the = semantics (also in combination with presence containers) that is more = apropriate for a given situation. >>>=20 >>> So, from my point of view, I'm afraid I can't see any value at all = with >>> such a proposal. >>>=20 >>> --Per >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From per@tail-f.com Mon Mar 18 09:34:32 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAF821F8C4F for ; Mon, 18 Mar 2013 09:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9rPB5PXIASx for ; Mon, 18 Mar 2013 09:34:24 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id F2DF821F8999 for ; Mon, 18 Mar 2013 09:31:32 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 0B2F41200174; Mon, 18 Mar 2013 17:31:32 +0100 (CET) Message-ID: <51474163.4090801@tail-f.com> Date: Mon, 18 Mar 2013 17:31:31 +0100 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110120 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ladislav Lhotka References: <20130318090816.GA32360@elstar.local> <51470574.3000800@tail-f.com> <514722EB.3080002@tail-f.com> <5BF42BD6-C864-4624-AFE9-2A1180F5C770@nic.cz> <7A0FD098-AAFC-4113-B1A2-F771AC46521F@nic.cz> In-Reply-To: <7A0FD098-AAFC-4113-B1A2-F771AC46521F@nic.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-groupings proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:34:32 -0000 On 2013-03-18 17:24, Ladislav Lhotka wrote: > > On Mar 18, 2013, at 4:57 PM, Andy Bierman wrote: > >> Hi, >> >> I was wondering if it would be better to mandate: >> * disabled MUST NOT appear as a top-level leaf >> * disabled just affects its parent container or list > > Yes to both, and one more would be needed: > > * If the parent node is a container with presence, then the "disabled" element overrides its presence. > > (A funny sentence indeed.:-) > >> >> But since the name 'disabled' is going to be in the XML >> namespace of the modules using the grouping, >> there is really no way to identify this leaf as special >> other than reserving the name 'disabled'. >> So any vendor leaf that happens to match the name >> we pick will be incorrectly assumed to be this special leaf. > > Right. In a standard XML context, a global namespaced attribute would be a perfect fit. > >> >> Maybe a YANG extension to identify such a leaf would >> be better: >> >> leaf disabled { >> yang:disable-leaf; >> type empty; >> ..... >> } > > Hmm, how could this extension help? > >> >> Or maybe we punt and say there is nothing machine-readable. >> Just a bunch of unrelated ad-hoc leafs and not have any >> grouping. > > Yes, maybe we should just make it a matter of good style, as Per suggested. Although I must admit that I missed the point about machine-readableness - but if it isn't fulfilled anyway... --Per > Lada > >> >> >> Andy >> >> >> On Mon, Mar 18, 2013 at 7:53 AM, Ladislav Lhotka wrote: >>> >>> On Mar 18, 2013, at 3:21 PM, Per Hedeland wrote: >>> >>>> On 2013-03-18 14:05, Ladislav Lhotka wrote: >>>>> >>>>> On Mar 18, 2013, at 1:15 PM, Per Hedeland wrote: >>>>>> >>>>>> IMO the big difference between boolean "enabled" and type-empty >>>>>> "disabled" is that the latter *enforces* a "default" of enabled, since a >>>>>> type-empty leaf can't "exist by default". That might be a desirable >>>>>> property, but I don't think so - I believe we will see cases where a >>>>>> default of disabled is more "natural"/useful. With a boolean, the >>>>>> default can be 'refine'd in the 'uses', whether there is an existing >>>>>> default or not. >>>>> >>>>> This is a valid point, although the modeller can do one of the following things to overcome this limitation: >>>>> >>>>> 1. Define the parent container as "presence". The client can then enable the subtree/service by including the container element, but also disable it secondarily by using while still keeping the subtree in the configuration. >>>>> >>>>> 2. One can simply forget about the existence of the grouping and define an "enabled" leaf from scratch. Refining a grouping that contains only one leaf makes little sense to me. >>>> >>>> We are already required to refine it to provide a description. And now >>>> we have 3 completely different "standard" ways of modeling "enablement", >>>> just to be able to choose the default. >>> >>> Oh yes, at first I didn't notice the specific description is a MUST. With it, the grouping is IMO pretty much useless. I guess the following generic description (to be included in the grouping) could suffice for 90 % of cases: >>> >>> "Indicates whether the subsystem/service represented by the parent node is disabled for use or not." >>> >>> & >>> >>>>> >>>>> Given the ubiquity of this leaf, the grouping would IMO help readability of modules. >>>> >>>> Hm, so let's say we have consensus for type-empty "disabled". Without >>>> grouping: >>>> >>>> ... XYZ { >>>> leaf disabled { >>>> type empty; >>>> description >>>> 'Indicates whether the service XYZ is disabled >>>> for use or not.'; >>>> } >>>> } >>>> >>>> With grouping: >>>> >>>> ... XYZ { >>>> uses yang-grp:disabled { >>>> refine disabled { >>>> description >>>> 'Indicates whether the service XYZ is disabled >>>> for use or not.'; >>>> } >>>> } >>>> } >>> >>> Sure, the second version is really clumsy and would certainly mean a serious confusion for non-expert readers. I assumed the standard use would be just >>> >>> uses yang-grp:disabled; >>> >>> If not, I agree with you that the grouping is silly, and doubly so because it is the only content of that module. >>> >>> Lada >>> >>> >>>> >>>> Looks like more text with less information to me, I really can't see how >>>> that helps readability. The only value (if any) *I* can see with a >>>> grouping is standardization, and as we both have pointed out, you don't >>>> get a standard that covers all use cases with type-empty "disabled". >>>> >>>>> I have actually a proposal, namely to provide two groupings: one with the empty "disabled" leaf, and another with boolean "enabled" leaf but with the default of "false". This way, the modeller can choose the semantics (also in combination with presence containers) that is more apropriate for a given situation. >>>> >>>> So, from my point of view, I'm afraid I can't see any value at all with >>>> such a proposal. >>>> >>>> --Per >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From andy@yumaworks.com Mon Mar 18 09:38:25 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3D921F8FAA for ; Mon, 18 Mar 2013 09:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA45oH96xsIU for ; Mon, 18 Mar 2013 09:38:17 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB7F21F89DA for ; Mon, 18 Mar 2013 09:36:58 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id 17so7073998iea.40 for ; Mon, 18 Mar 2013 09:36:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=UNv87yk6uMImTzx5V+q0h+pCH992Gaa/EXVwP9n04Ng=; b=mPlDs5LDSUxgszA8k6BFKZytFK1F1AsNYaEDM2mZQT3HzKsiB9QXnTuiNC9kMQ9VNo 18zWMlNksy82U97CLHKSjizLVA0Ql4Kg+hN5BqOE+lt7/MuZVpoB7EQxTKWwfGxKQObX XusHLJugj69dl6GfjheMi0YHDikcH6vR7sa8kBEOiL8ffWG7IYn8winArl5PiqUsqW27 SwttZ0vH260R6nAevUe9j8sAT5GSdHzjKtZmCBZ2P1BGmlGAoxluqMKTFt+J7a+VQASt M2Qa/SS7rXcy9E5V3vFMzlxx5c68KnVQqhJ+0bK02lp358MNJYVhkLnCLB+XOL8dbeaA rSHg== MIME-Version: 1.0 X-Received: by 10.50.219.168 with SMTP id pp8mr6348315igc.57.1363624618140; Mon, 18 Mar 2013 09:36:58 -0700 (PDT) Received: by 10.231.93.6 with HTTP; Mon, 18 Mar 2013 09:36:57 -0700 (PDT) In-Reply-To: <7A0FD098-AAFC-4113-B1A2-F771AC46521F@nic.cz> References: <20130318090816.GA32360@elstar.local> <51470574.3000800@tail-f.com> <514722EB.3080002@tail-f.com> <5BF42BD6-C864-4624-AFE9-2A1180F5C770@nic.cz> <7A0FD098-AAFC-4113-B1A2-F771AC46521F@nic.cz> Date: Mon, 18 Mar 2013 09:36:57 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkhCA1HxHrirXtW5X1OcaXBDkZTw/hBGQjD1n3sb4D82JnzNWGza53jA1m7dDQplP3KHLWM Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-groupings proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:38:25 -0000 On Mon, Mar 18, 2013 at 9:24 AM, Ladislav Lhotka wrote: > > On Mar 18, 2013, at 4:57 PM, Andy Bierman wrote: > >> Hi, >> >> I was wondering if it would be better to mandate: >> * disabled MUST NOT appear as a top-level leaf >> * disabled just affects its parent container or list > > Yes to both, and one more would be needed: > > * If the parent node is a container with presence, then the "disabled= " element overrides its presence. This will not affect any client looking for a P-container and does not know about special leafs. This breaks old managers. I am liking this solution less and less by the minute. > > (A funny sentence indeed.:-) > >> >> But since the name 'disabled' is going to be in the XML >> namespace of the modules using the grouping, >> there is really no way to identify this leaf as special >> other than reserving the name 'disabled'. >> So any vendor leaf that happens to match the name >> we pick will be incorrectly assumed to be this special leaf. > > Right. In a standard XML context, a global namespaced attribute would be = a perfect fit. > So it would be better to punt on this and wait for conditional config features adding in the future if the solution is to invent new XML attributes. >> >> Maybe a YANG extension to identify such a leaf would >> be better: >> >> leaf disabled { >> yang:disable-leaf; >> type empty; >> ..... >> } > > Hmm, how could this extension help? > There are no special XML attributes that can be used. There is only the leaf itself. The extended-name is useless since it is a leaf from a grouping. Only the local-name or some other tag (YANG extension) can identify this as a special leaf. >> >> Or maybe we punt and say there is nothing machine-readable. >> Just a bunch of unrelated ad-hoc leafs and not have any >> grouping. > > Yes, maybe we should just make it a matter of good style, as Per suggeste= d. > Maybe it isn't good style at all. We dumped SMIv2 because of lame design limitations like peppering the data with action buttons. This is starting to look like RowStatus reinvented. Kent's draft is a much better design approach. > Lada Andy > >> >> >> Andy >> >> >> On Mon, Mar 18, 2013 at 7:53 AM, Ladislav Lhotka wrote: >>> >>> On Mar 18, 2013, at 3:21 PM, Per Hedeland wrote: >>> >>>> On 2013-03-18 14:05, Ladislav Lhotka wrote: >>>>> >>>>> On Mar 18, 2013, at 1:15 PM, Per Hedeland wrote: >>>>>> >>>>>> IMO the big difference between boolean "enabled" and type-empty >>>>>> "disabled" is that the latter *enforces* a "default" of enabled, sin= ce a >>>>>> type-empty leaf can't "exist by default". That might be a desirable >>>>>> property, but I don't think so - I believe we will see cases where a >>>>>> default of disabled is more "natural"/useful. With a boolean, the >>>>>> default can be 'refine'd in the 'uses', whether there is an existing >>>>>> default or not. >>>>> >>>>> This is a valid point, although the modeller can do one of the follow= ing things to overcome this limitation: >>>>> >>>>> 1. Define the parent container as "presence". The client can then ena= ble the subtree/service by including the container element, but also disabl= e it secondarily by using while still keeping the subtree in th= e configuration. >>>>> >>>>> 2. One can simply forget about the existence of the grouping and defi= ne an "enabled" leaf from scratch. Refining a grouping that contains only o= ne leaf makes little sense to me. >>>> >>>> We are already required to refine it to provide a description. And now >>>> we have 3 completely different "standard" ways of modeling "enablement= ", >>>> just to be able to choose the default. >>> >>> Oh yes, at first I didn't notice the specific description is a MUST. Wi= th it, the grouping is IMO pretty much useless. I guess the following gener= ic description (to be included in the grouping) could suffice for 90 % of c= ases: >>> >>> "Indicates whether the subsystem/service represented by the parent node= is disabled for use or not." >>> >>> =85 >>> >>>>> >>>>> Given the ubiquity of this leaf, the grouping would IMO help readabil= ity of modules. >>>> >>>> Hm, so let's say we have consensus for type-empty "disabled". Without >>>> grouping: >>>> >>>> ... XYZ { >>>> leaf disabled { >>>> type empty; >>>> description >>>> 'Indicates whether the service XYZ is disabled >>>> for use or not.'; >>>> } >>>> } >>>> >>>> With grouping: >>>> >>>> ... XYZ { >>>> uses yang-grp:disabled { >>>> refine disabled { >>>> description >>>> 'Indicates whether the service XYZ is disabled >>>> for use or not.'; >>>> } >>>> } >>>> } >>> >>> Sure, the second version is really clumsy and would certainly mean a se= rious confusion for non-expert readers. I assumed the standard use would be= just >>> >>> uses yang-grp:disabled; >>> >>> If not, I agree with you that the grouping is silly, and doubly so beca= use it is the only content of that module. >>> >>> Lada >>> >>> >>>> >>>> Looks like more text with less information to me, I really can't see h= ow >>>> that helps readability. The only value (if any) *I* can see with a >>>> grouping is standardization, and as we both have pointed out, you don'= t >>>> get a standard that covers all use cases with type-empty "disabled". >>>> >>>>> I have actually a proposal, namely to provide two groupings: one with= the empty "disabled" leaf, and another with boolean "enabled" leaf but wit= h the default of "false". This way, the modeller can choose the semantics (= also in combination with presence containers) that is more apropriate for a= given situation. >>>> >>>> So, from my point of view, I'm afraid I can't see any value at all wit= h >>>> such a proposal. >>>> >>>> --Per >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From lhotka@nic.cz Mon Mar 18 09:56:45 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B97A21F8FF1 for ; Mon, 18 Mar 2013 09:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-UQh3VypGEQ for ; Mon, 18 Mar 2013 09:56:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3675F21F8FD1 for ; Mon, 18 Mar 2013 09:55:39 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 2EE8A13F7BB; Mon, 18 Mar 2013 17:55:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1363625738; bh=g4xOyc090YfFdLsBW8f8wM9+Tx3qtFweCm6v3ZdsJFU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=W14mnzl00rzE8e8Qk0kxmIOoCW96krhNeplkQXvoOVXtaECTH2MK2n/NOmBuhPUN9 EnqSvlF9xMpsfFJwlnzjoM529oKXjMz/ZEN8PHX6St7emG0Zn5LlxuzEDz+UvCdRkH WL1CegOt2ED/HEcFS4aSFzKMiwTSxYSxMKRSmkt8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 18 Mar 2013 17:55:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1757A6FB-AD48-4003-A92A-6BF099388867@nic.cz> References: <20130318090816.GA32360@elstar.local> <51470574.3000800@tail-f.com> <514722EB.3080002@tail-f.com> <5BF42BD6-C864-4624-AFE9-2A1180F5C770@nic.cz> <7A0FD098-AAFC-4113-B1A2-F771AC46521F@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-groupings proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:56:45 -0000 On Mar 18, 2013, at 5:36 PM, Andy Bierman wrote: > Maybe it isn't good style at all. OK, but we have a number of such leaves spread across the core modules, = so at least we should use the same definition where possible. It seems = the boolean "enabled" leaf with the default of "true" is used in most = cases, so perhaps we should just stick to this.=20 Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Mar 18 10:18:55 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D829B21F8C04 for ; Mon, 18 Mar 2013 10:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.558 X-Spam-Level: X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+j2gDQ5bZFs for ; Mon, 18 Mar 2013 10:18:47 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 890DD21F8A7E for ; Mon, 18 Mar 2013 10:18:47 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id qd14so1454095ieb.11 for ; Mon, 18 Mar 2013 10:18:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=VFVA2asss3f6Zocwq7yTW4rRcC9A9hplR8/fRxNRkc8=; b=Wsi8neNBxbHm+85FPKqfrzKF4qqHo9vTLowcwOxEbcUhV8B5dUWlNtyBUk52NEO8AA 8DtCqGKlgZM0oaZfTLSW5f0175ENGzTN6Yu8Yq6dBFIo/n0FZhv+il9j6FrsqcvD2VMO rrQGgHfkuZsMxiYIdMTLusalCahrJ2bZKVgRdb6H5wjKbGGED8R1x/d8ITav/mRX4ikd E1f4u/SDIJUIbb4MDInyXlA/D0hcsiTHEhAaslLNBBNAzwBtW9dkBkD4rUOY2pWwMEGN KXqLbl0OLaMNtRXgeGUR766J1wHNYTF2jBcYNLNdAzKawQopLcSbmKY8H4vtQlV8d5Yo ly4A== MIME-Version: 1.0 X-Received: by 10.50.153.198 with SMTP id vi6mr29107471igb.112.1363627127142; Mon, 18 Mar 2013 10:18:47 -0700 (PDT) Received: by 10.231.93.6 with HTTP; Mon, 18 Mar 2013 10:18:47 -0700 (PDT) In-Reply-To: <1757A6FB-AD48-4003-A92A-6BF099388867@nic.cz> References: <20130318090816.GA32360@elstar.local> <51470574.3000800@tail-f.com> <514722EB.3080002@tail-f.com> <5BF42BD6-C864-4624-AFE9-2A1180F5C770@nic.cz> <7A0FD098-AAFC-4113-B1A2-F771AC46521F@nic.cz> <1757A6FB-AD48-4003-A92A-6BF099388867@nic.cz> Date: Mon, 18 Mar 2013 10:18:47 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk4LowCceLLa45VgOeINa4KskcMC0vLC0Fwx8Vf3nDR+kqBsgWoEZ+GJ2ThKfjtD9PrVSw4 Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-groupings proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 17:18:56 -0000 Hi, We could use the xpath1.0 typedef hack. Not sure why I didn't think of this fist. (Blaming it on the flu...) typedef parent-enabled { type boolean; default true; description "Indicates whether the parent container is enabled or not."; } Andy On Mon, Mar 18, 2013 at 9:55 AM, Ladislav Lhotka wrote: > > On Mar 18, 2013, at 5:36 PM, Andy Bierman wrote: > >> Maybe it isn't good style at all. > > OK, but we have a number of such leaves spread across the core modules, s= o at least we should use the same definition where possible. It seems the b= oolean "enabled" leaf with the default of "true" is used in most cases, so = perhaps we should just stick to this. > > Lada > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From randy_presuhn@mindspring.com Mon Mar 18 10:41:34 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8AB21F8F1E for ; Mon, 18 Mar 2013 10:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88afQNIXITQv for ; Mon, 18 Mar 2013 10:41:19 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id AD6BF21F8D20 for ; Mon, 18 Mar 2013 10:41:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=WpEk/2lCogMVwwjSQQVQmzo0Wn976+gGIa+p39zN5NXqDb984WSUWut2fA8IBcK0; 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 [99.30.227.151] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1UHe3i-0006vu-RX for netmod@ietf.org; Mon, 18 Mar 2013 13:41:19 -0400 Message-ID: <002f01ce23ff$e97f74c0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20130318090816.GA32360@elstar.local> <51470574.3000800@tail-f.com><514722EB.3080002@tail-f.com><5BF42BD6-C864-4624-AFE9-2A1180F5C770@nic.cz><7A0FD098-AAFC-4113-B1A2-F771AC46521F@nic.cz><1757A6FB-AD48-4003-A92A-6BF099388867@nic.cz> Date: Mon, 18 Mar 2013 10:42:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88880ff2f3e23ebe946c1d09fad866c0e34246d2b07a2744792350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.30.227.151 Subject: Re: [netmod] ietf-yang-groupings proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 17:41:34 -0000 Hi - > From: "Andy Bierman" ... > Sent: Monday, March 18, 2013 10:18 AM > Subject: Re: [netmod] ietf-yang-groupings proposal ... > "Indicates whether the parent container is enabled or not."; s/ or not// Otherwise the only possible value would be "true". :-) Randy From andy@yumaworks.com Mon Mar 18 14:37:26 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B247B21F8C93 for ; Mon, 18 Mar 2013 14:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.228 X-Spam-Level: X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pu6+tCY9O8Zq for ; Mon, 18 Mar 2013 14:37:26 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3018121F8C8F for ; Mon, 18 Mar 2013 14:37:26 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id c13so7531991ieb.23 for ; Mon, 18 Mar 2013 14:37:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=Y8mSHIHppEWOeDQmDcAadWmR8s5/ypE94sB/1oCENOU=; b=I5tOio9FfGRsAcueFcwZuB2HAr2aZFc7kyEQoycFrvIOyr1tNdbGZ/DOfv1LCUDXBe UUZLnmna8r+bRfmaNa/G81IyNqqUnAdaU2e3gDHYLEdAiFQKa1IgETbQ/8J6ujKrj/1e 7erYk0MXmLJkAiNqKrjXw20V2Rstb/pdVFc4Ak5dzNm8dk1auKEKXNW4pxU/8YOf3un5 z+Xf8w25GGN/qdqg2GLqR4HQe5yuzThoGJ1VKBcFJQDnakPzhqG2+lwFEIh0h+WuoDxZ Y9A6gvNdG6HwaL5bjQwZrw8u12s/ywq2QiI6pTHud8lxtHzX8zcfaK2JGeh650u2RBvJ sk8Q== MIME-Version: 1.0 X-Received: by 10.50.7.69 with SMTP id h5mr267959iga.69.1363642645704; Mon, 18 Mar 2013 14:37:25 -0700 (PDT) Received: by 10.231.93.6 with HTTP; Mon, 18 Mar 2013 14:37:25 -0700 (PDT) In-Reply-To: <002f01ce23ff$e97f74c0$6b01a8c0@oemcomputer> References: <20130318090816.GA32360@elstar.local> <51470574.3000800@tail-f.com> <514722EB.3080002@tail-f.com> <5BF42BD6-C864-4624-AFE9-2A1180F5C770@nic.cz> <7A0FD098-AAFC-4113-B1A2-F771AC46521F@nic.cz> <1757A6FB-AD48-4003-A92A-6BF099388867@nic.cz> <002f01ce23ff$e97f74c0$6b01a8c0@oemcomputer> Date: Mon, 18 Mar 2013 14:37:25 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmhAIbHyBCVJ1gssSM3E72O9xEK7H6t/ohsxsVITzB826yJztdiRnXQnSwqPC7NKunDbUss Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-groupings proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 21:37:26 -0000 Hi, 4th try: typedef parent-enabled { type boolean; default true; description "Indicates whether the parent container or list is enabled."; } Issues: 1) Is definition of 'enabled' needed? 2) Is it clear that top-level leafs using this type do not affect anything? Cannot disable the entire config with a top-level enabled leaf. 3) Special text needed for P-containers? 4) Cannot constrain to config=true leafs using typedef. OK to use in config=false for reporting? 5) Add to ietf-yang-types module ASAP? Andy On Mon, Mar 18, 2013 at 10:42 AM, Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" > ... >> Sent: Monday, March 18, 2013 10:18 AM >> Subject: Re: [netmod] ietf-yang-groupings proposal > ... >> "Indicates whether the parent container is enabled or not."; > > s/ or not// > > Otherwise the only possible value would be "true". :-) > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From j.schoenwaelder@jacobs-university.de Mon Mar 18 15:06:24 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB7821F8AA8 for ; Mon, 18 Mar 2013 15:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.649 X-Spam-Level: X-Spam-Status: No, score=-102.649 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJ7l0ke1gknR for ; Mon, 18 Mar 2013 15:06:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 51BEA21F8A94 for ; Mon, 18 Mar 2013 15:06:19 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 628F720BE6; Mon, 18 Mar 2013 23:06:18 +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 qb51ACoqSrO1; Mon, 18 Mar 2013 23:06:18 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC8FC20BE4; Mon, 18 Mar 2013 23:06:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 839B22506DB2; Mon, 18 Mar 2013 23:06:31 +0100 (CET) Date: Mon, 18 Mar 2013 23:06:30 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20130318220630.GA36485@elstar.local> Mail-Followup-To: Andy Bierman , Randy Presuhn , netmod@ietf.org References: <514722EB.3080002@tail-f.com> <5BF42BD6-C864-4624-AFE9-2A1180F5C770@nic.cz> <7A0FD098-AAFC-4113-B1A2-F771AC46521F@nic.cz> <1757A6FB-AD48-4003-A92A-6BF099388867@nic.cz> <002f01ce23ff$e97f74c0$6b01a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-groupings proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 22:06:24 -0000 On Mon, Mar 18, 2013 at 02:37:25PM -0700, Andy Bierman wrote: > Hi, > > 4th try: > > > typedef parent-enabled { > type boolean; > default true; > description > "Indicates whether the parent container or list is enabled."; > } > > > Issues: > 1) Is definition of 'enabled' needed? > 2) Is it clear that top-level leafs using this type > do not affect anything? Cannot disable the entire > config with a top-level enabled leaf. > 3) Special text needed for P-containers? > 4) Cannot constrain to config=true leafs using typedef. > OK to use in config=false for reporting? > 5) Add to ietf-yang-types module ASAP? > If you make this a typedef, why not simply call it 'enabled'? The usage would be like this anyway: leaf enabled { type yang:enabled; description "bla bla bla"; } There is going to be a description statement and it will state what is enabled/disabled. Now, how much added value does this new typedef provide? What is the automation this type achieves compared to simply a boolean given that is enabled (in all cases I have seen so far) is kind of subject to a description clause (and thus to arbitrary creativity). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Mon Mar 18 15:26:51 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8732F21F8AE2 for ; Mon, 18 Mar 2013 15:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.864 X-Spam-Level: X-Spam-Status: No, score=-0.864 tagged_above=-999 required=5 tests=[AWL=-0.686, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_47=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmMFTfU9m8XF for ; Mon, 18 Mar 2013 15:26:51 -0700 (PDT) Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE1C21F8ADC for ; Mon, 18 Mar 2013 15:26:50 -0700 (PDT) Received: by mail-ia0-f171.google.com with SMTP id z13so5774658iaz.16 for ; Mon, 18 Mar 2013 15:26:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=Syal5y8CD7/ItLMhGrH35MN7DZTjGiQaNClFc+/uMjw=; b=Xh7Ty3RqIz1XL1DXkt8fG1U8zumuPXPPAhEAKs/azFIyIJ++bxtP1Bk1TQozNA/v07 XEdkAsi9nCVswsKVaz15QU4B4uEemByugjQB2LqK1q6J8uKP3OcvdMbVlqT8IOCeph35 f9NMKQb6AG3Q0XpjIDvSwyQSUw9DUgwbCfMzNdN8kFWYVbiA89SHmHmwobhl3WDaZzF5 Klu0MhQcZLnZWlCuDNRBT+DqWER6w5SfkS7Kf9qX7Ax22simtMKo9PO0rWscte9ijjv3 7bCmqCoNfxQWDaeqMsSwIjX+gLUbJR3l8jUO5Zafh7U2MX3lNzdPcGWCEGJgFpNm6a9i KohQ== MIME-Version: 1.0 X-Received: by 10.50.219.168 with SMTP id pp8mr325174igc.57.1363645610281; Mon, 18 Mar 2013 15:26:50 -0700 (PDT) Received: by 10.231.93.6 with HTTP; Mon, 18 Mar 2013 15:26:50 -0700 (PDT) In-Reply-To: <20130318220630.GA36485@elstar.local> References: <514722EB.3080002@tail-f.com> <5BF42BD6-C864-4624-AFE9-2A1180F5C770@nic.cz> <7A0FD098-AAFC-4113-B1A2-F771AC46521F@nic.cz> <1757A6FB-AD48-4003-A92A-6BF099388867@nic.cz> <002f01ce23ff$e97f74c0$6b01a8c0@oemcomputer> <20130318220630.GA36485@elstar.local> Date: Mon, 18 Mar 2013 15:26:50 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Randy Presuhn , netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkELFY87XD4uUH42KC2S8tCWuuzG/r9vhLGVOUIRiWDtTZvGMacc5SYyfrRKUPHM36fD/5n Subject: Re: [netmod] ietf-yang-groupings proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 22:26:51 -0000 On Mon, Mar 18, 2013 at 3:06 PM, Juergen Schoenwaelder wrote: > On Mon, Mar 18, 2013 at 02:37:25PM -0700, Andy Bierman wrote: >> Hi, >> >> 4th try: >> >> >> typedef parent-enabled { >> type boolean; >> default true; >> description >> "Indicates whether the parent container or list is enabled."; >> } >> >> >> Issues: >> 1) Is definition of 'enabled' needed? >> 2) Is it clear that top-level leafs using this type >> do not affect anything? Cannot disable the entire >> config with a top-level enabled leaf. >> 3) Special text needed for P-containers? >> 4) Cannot constrain to config=true leafs using typedef. >> OK to use in config=false for reporting? >> 5) Add to ietf-yang-types module ASAP? >> > > If you make this a typedef, why not simply call it 'enabled'? The usage > would be like this anyway: > > leaf enabled { > type yang:enabled; > description > "bla bla bla"; > } > > There is going to be a description statement and it will state what is > enabled/disabled. > > Now, how much added value does this new typedef provide? What is the > automation this type achieves compared to simply a boolean given that > is enabled (in all cases I have seen so far) is kind of subject to a > description clause (and thus to arbitrary creativity). > Automation tools could use it because it is a QName and there can only be 1 yang:enabled type. (* see below) The description-stmt is irrelevant because it enables the parent container or list. Automation tools can ignore the description-stmt. What if there are 2+ of these in the same subtree? That may be a broken design but automation tools would need to check for it. This is a little problem -- not worth spending time on. The ad-hoc enabled leafs can be deprecated if and when conditional config mechanisms are adopted later. I posted these things to move the discussion forward. It does not appear that solving this short-term problem is such a good idea after all. Next. Even little IETF hacks take too long and last forever (RFC 2856 taught me that :-). > /js > Andy From lhotka@nic.cz Tue Mar 19 06:58:34 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5C121F8BBD for ; Tue, 19 Mar 2013 06:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.924 X-Spam-Level: X-Spam-Status: No, score=-0.924 tagged_above=-999 required=5 tests=[AWL=-1.076, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHD2w4B-uE2V for ; Tue, 19 Mar 2013 06:58:31 -0700 (PDT) Received: from trail.lhotka.name (unknown [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 889A421F8B63 for ; Tue, 19 Mar 2013 06:58:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 5559B54064F for ; Tue, 19 Mar 2013 14:56:59 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kH3pUFSr28Bl for ; Tue, 19 Mar 2013 14:56:50 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id D08EB540261 for ; Tue, 19 Mar 2013 14:56:44 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20130306000539.GG2854@nsn.com> References: <20130306000539.GG2854@nsn.com> User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Tue, 19 Mar 2013 14:56:44 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 13:58:34 -0000 Hi, I have several comments to the draft: 1. /system/dns/search has the type inet:host - I think this is not correct, it should be inet:domain-name instead. 2. The document should also refer to 6021bis rather than 6021, but maybe this is already planned. 3. The description of /system/platform/nodename says it is "The host name of this system." Wouldn't it be better then to call this leaf "hostname" or "host-name"? Also, is it necessary to have two leaves with names, i.e. this one and also "name"? In general, I think the document is in a good shape and ready for publication, after resolving the pending issues. Lada David Kessens writes: > Hi, > > I would hereby like to start a Last Call for: > > http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-05 > > Please indicate your support by Wed March 20, 2013. Or alternatively, let us > know in the same timeframe whether there are still issues that need to be > resolved. > > Thanks! > > David Kessens > co-chair netmod wg > --- > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Mar 19 08:41:52 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C8E21F8DBB for ; Tue, 19 Mar 2013 08:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.917, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_29=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcIJ-nQyoNvJ for ; Tue, 19 Mar 2013 08:41:52 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id DCD9421F8DB9 for ; Tue, 19 Mar 2013 08:41:51 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id c13so748808ieb.23 for ; Tue, 19 Mar 2013 08:41:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=zbmi9YITIfqELmAMb2wdyb176yvsOZRpYdt9YqwGz8g=; b=Hr7TMgUuHfEaU4NhN7fUBQ/J8x/yYPERhaKq22NkhIFxZYi1YEYY5xDu/S4WPL5qjM T9BZIr6LSlZj8Gt4TXkyrSLqzsY8bbegM3X7y+fUcqq2+qEQWFU6ImUBp2kljrpCxIAd uWYSR+11wbXz4mASaziVuufKmZSfP++5pYyIzz5vgMN/+zBgOajcz14SXc/t1DFiLXj5 4KIIDWfIOQ5/q3qnT91puOFV2HMpuZnwLlRPNPqbr51XrIcJtQckq+d/dbbxFrPw2WsB /RSuYL2KKIQY3AB37rg4ieBRteROr+Ug4jRNhxh5iLdov2vpJCVCEbhYTas1fgcqb0+8 eEFA== MIME-Version: 1.0 X-Received: by 10.42.148.71 with SMTP id q7mr11258666icv.53.1363707711442; Tue, 19 Mar 2013 08:41:51 -0700 (PDT) Received: by 10.231.93.6 with HTTP; Tue, 19 Mar 2013 08:41:51 -0700 (PDT) In-Reply-To: <20130318220630.GA36485@elstar.local> References: <514722EB.3080002@tail-f.com> <5BF42BD6-C864-4624-AFE9-2A1180F5C770@nic.cz> <7A0FD098-AAFC-4113-B1A2-F771AC46521F@nic.cz> <1757A6FB-AD48-4003-A92A-6BF099388867@nic.cz> <002f01ce23ff$e97f74c0$6b01a8c0@oemcomputer> <20130318220630.GA36485@elstar.local> Date: Tue, 19 Mar 2013 08:41:51 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Randy Presuhn , netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnxwjX5pXpkrmQaZwmYSx+fHCKY3R54AIHuyLOEJX+6hfHHFJIBLokSbislcETYHiGI12I/ Subject: Re: [netmod] ietf-yang-groupings proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 15:41:52 -0000 On Mon, Mar 18, 2013 at 3:06 PM, Juergen Schoenwaelder wrote: > On Mon, Mar 18, 2013 at 02:37:25PM -0700, Andy Bierman wrote: >> Hi, >> >> 4th try: >> >> >> typedef parent-enabled { >> type boolean; >> default true; >> description >> "Indicates whether the parent container or list is enabled."; >> } >> >> >> Issues: >> 1) Is definition of 'enabled' needed? >> 2) Is it clear that top-level leafs using this type >> do not affect anything? Cannot disable the entire >> config with a top-level enabled leaf. >> 3) Special text needed for P-containers? >> 4) Cannot constrain to config=true leafs using typedef. >> OK to use in config=false for reporting? >> 5) Add to ietf-yang-types module ASAP? >> > > If you make this a typedef, why not simply call it 'enabled'? The usage > would be like this anyway: > > leaf enabled { > type yang:enabled; > description > "bla bla bla"; > } > > There is going to be a description statement and it will state what is > enabled/disabled. > > Now, how much added value does this new typedef provide? What is the > automation this type achieves compared to simply a boolean given that > is enabled (in all cases I have seen so far) is kind of subject to a > description clause (and thus to arbitrary creativity). > The more I think about this, the more it looks like we are repeating the mistakes of SNMP. I would like to get rid of the enabled leafs in the new NETMOD YANG modules and use Kent's simple-expr proposal instead. We can do conditional enablement in phases, starting with the simple nc:enabled= attribute. That will not take that long because we will agree in advance there will be no feature-creep, just the 'enabled' attribute. The enabled leaf is not a true config leaf. It is an on/off button for its parent subtree. We should try to keep N/Y clean, and keep actions on the config in XML attributes, and the config contents in XML elements, like we do with the nc:operation, yang:insert, key, value attributes. > /js > Andy From lhotka@nic.cz Tue Mar 19 09:00:28 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F4D21F8F44 for ; Tue, 19 Mar 2013 09:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.28 X-Spam-Level: X-Spam-Status: No, score=-1.28 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_29=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bf9gJaFMWZT1 for ; Tue, 19 Mar 2013 09:00:27 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 555F721F8F3A for ; Tue, 19 Mar 2013 09:00:27 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7837213FB60; Tue, 19 Mar 2013 17:00:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1363708826; bh=ngPLDAh6YODJLz8b3fuVVaW/sdV5/yFSQucuR18HpHw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=eiM64h4I652z8hG8g3SGzRT87gVaianltaXUmmnYFNL18HnHz7eG8ER5lr8aC7QTn lTW6wLnCtUZhNKHq7j+5ZR7Peez9zz/3ERMG3p9IHYWUsVWnkKoIM8/RW5oelTH6tS RYGiNEVNDal8czu7PxtcM1/QQlihXG/UUjOmrJQs= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 19 Mar 2013 16:59:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <05214B32-4A7D-4886-A263-6D9659A1AC44@nic.cz> References: <514722EB.3080002@tail-f.com> <5BF42BD6-C864-4624-AFE9-2A1180F5C770@nic.cz> <7A0FD098-AAFC-4113-B1A2-F771AC46521F@nic.cz> <1757A6FB-AD48-4003-A92A-6BF099388867@nic.cz> <002f01ce23ff$e97f74c0$6b01a8c0@oemcomputer> <20130318220630.GA36485@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-groupings proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:00:28 -0000 On Mar 19, 2013, at 4:41 PM, Andy Bierman wrote: >=20 > The more I think about this, the more it looks like we > are repeating the mistakes of SNMP. >=20 > I would like to get rid of the enabled leafs in > the new NETMOD YANG modules and use Kent's > simple-expr proposal instead. But Kent's proposal will need some work and time, and I am afraid we = cannot couple the core models with it. =20 >=20 > We can do conditional enablement in phases, starting > with the simple nc:enabled=3D attribute. > That will not take that long because we will agree in advance > there will be no feature-creep, just the 'enabled' attribute. Some discussion will be needed wrt its precise semantics and other = details, so I am not that optimistic.=20 >=20 > The enabled leaf is not a true config leaf. It is an on/off > button for its parent subtree. We should try to keep N/Y > clean, and keep actions on the config in XML attributes, > and the config contents in XML elements, > like we do with the nc:operation, yang:insert, key, value > attributes. I don't think this is always true - sometimes there are also side = effects that differ from case to case. For example, setting "enabled" to = "false" for a routing protocol instance means that, e.g., peer sessions = have to be terminated, routes removed from routing tables etc.=20 Lada >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Mar 19 09:26:17 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF9D21F89EE for ; Tue, 19 Mar 2013 09:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.003 X-Spam-Level: X-Spam-Status: No, score=-1.003 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_29=0.6, J_CHICKENPOX_46=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lK308wsK5E7 for ; Tue, 19 Mar 2013 09:26:16 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0192721F86E3 for ; Tue, 19 Mar 2013 09:26:15 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id 16so845268iea.36 for ; Tue, 19 Mar 2013 09:26:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=vqmhOTNqk+ysZkEsbNg3r92B6sCdU8/uj8s4cOBP9B0=; b=ZtQaUIvK4iRFcLgZ+UpBMgO7IBdOOpcWLip1Q0ix6bPNyONcse+jIG1IDA/Tahk/8l NpmOKusZ99RWG15SdcGMIc2gsnY6NrcbgX9eaYO6xQkY8Mp9AB0bnaToIBRQpi6oNfK/ dNopz6CQbcKCCdUPeejx9x/kutNGrI/Mt/yGMNomwCRSJapkwnK6N+h7ae0jOUPXInzI BDokhdCDL83lZd3SwdcDL5LIJNu1MWiDqxx67KzQF1YUpTspNHBijSguCMozGKm0rOb5 15sqK/Tk2WDdo+aVdjlTS/kzmC2Jxjmy7qnbGaEiJZ//YA3CLFbyKzPkakuXuR9DNZ5u wFOg== MIME-Version: 1.0 X-Received: by 10.42.64.135 with SMTP id g7mr11242453ici.37.1363710375443; Tue, 19 Mar 2013 09:26:15 -0700 (PDT) Received: by 10.231.93.6 with HTTP; Tue, 19 Mar 2013 09:26:15 -0700 (PDT) In-Reply-To: <05214B32-4A7D-4886-A263-6D9659A1AC44@nic.cz> References: <514722EB.3080002@tail-f.com> <5BF42BD6-C864-4624-AFE9-2A1180F5C770@nic.cz> <7A0FD098-AAFC-4113-B1A2-F771AC46521F@nic.cz> <1757A6FB-AD48-4003-A92A-6BF099388867@nic.cz> <002f01ce23ff$e97f74c0$6b01a8c0@oemcomputer> <20130318220630.GA36485@elstar.local> <05214B32-4A7D-4886-A263-6D9659A1AC44@nic.cz> Date: Tue, 19 Mar 2013 09:26:15 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlY/olQYvDzEtRsBl//6eP1j00JevJra1R+Gg9zFtVYFzQCfHUpqC7+ZgnbnFif2GBTjIEQ Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-groupings proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:26:17 -0000 On Tue, Mar 19, 2013 at 8:59 AM, Ladislav Lhotka wrote: > > On Mar 19, 2013, at 4:41 PM, Andy Bierman wrote: > >> >> The more I think about this, the more it looks like we >> are repeating the mistakes of SNMP. >> >> I would like to get rid of the enabled leafs in >> the new NETMOD YANG modules and use Kent's >> simple-expr proposal instead. > > But Kent's proposal will need some work and time, and I am afraid we cann= ot couple the core models with it. > Then we should not encourage this design and we should deprecate those leafs in the future. >> >> We can do conditional enablement in phases, starting >> with the simple nc:enabled=3D attribute. >> That will not take that long because we will agree in advance >> there will be no feature-creep, just the 'enabled' attribute. > > Some discussion will be needed wrt its precise semantics and other detail= s, so I am not that optimistic. > >> >> The enabled leaf is not a true config leaf. It is an on/off >> button for its parent subtree. We should try to keep N/Y >> clean, and keep actions on the config in XML attributes, >> and the config contents in XML elements, >> like we do with the nc:operation, yang:insert, key, value >> attributes. > > I don't think this is always true - sometimes there are also side effects= that differ from case to case. For example, setting "enabled" to "false" f= or a routing protocol instance means that, e.g., peer sessions have to be t= erminated, routes removed from routing tables etc. > XPath must/when exprs have to check this enabled flag before using the affected siblings. I still think database operations belong in the meta-data, and these leafs will get in the way in the near future. > Lada > Andy From alex@cisco.com Tue Mar 19 16:19:25 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C9D21F8E1A for ; Tue, 19 Mar 2013 16:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXO8XWTrB-Xi for ; Tue, 19 Mar 2013 16:19:24 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 40B9C21F8E16 for ; Tue, 19 Mar 2013 16:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2440; q=dns/txt; s=iport; t=1363735164; x=1364944764; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=k4JwLSoMjiPuOA2UdZNur/97mM0KXBpxhI8nLk23Tx4=; b=bk0ZKDzvLNc0nnf1plp7wzPOjJpr0R2GEAgOOjNAbIXgOtVD0OPp3a70 Ufv5Cgr5xt2ui1hL62HuIn7O2qThjKW0/jjH1AuJOqwOVsRu5yOdm74OH joO5GbmkBCpdMwjtEHr92YGDjS8L/D7Zgj1HRUgL77hP43gcJar12hmnB Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIPxSFGtJV2b/2dsb2JhbABDxQuBRRZ0giQBAQEEAQEBGgoTNBcEAgEIEQQBAQsUCQcnCxQJCAIEARIIiAwMsXaQBY5dJhIGgllhA5d+j2ODCoIo X-IronPort-AV: E=Sophos;i="4.84,874,1355097600"; d="scan'208";a="186294097" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 19 Mar 2013 23:19:23 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2JNJNk0026879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 23:19:23 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.147]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 18:19:23 -0500 From: "Alexander Clemm (alex)" To: David Kessens , "netmod@ietf.org" Thread-Topic: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) Thread-Index: AQHOGf5hhTgy2S1ti0+/uGKuY6Ge1pituNBA Date: Tue, 19 Mar 2013 23:19:23 +0000 Message-ID: References: <20130306000539.GG2854@nsn.com> In-Reply-To: <20130306000539.GG2854@nsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.200.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 23:19:25 -0000 Hi, Here are my comments - very minor in nature. IMHO the document is in good = shape and should move forward to publication. =20 Section 1: "This document defines a YANG data model for the configuration = and identification of the management system of a device." Is this stateme= nt really accurate? I wonder if this can be slightly rephrased. It is not= _the_ management system that is configured, but a bunch of system manageme= nt related aspects. Perhaps rephrase as something like "... for the config= uration and identification of general system-management related aspects of = a device, such as system time-of-day configuration and monitoring, basic sy= stem identification, and user authentication configuration.". =20 Section 2.1 "These objects are defined as operational data and intended to = be specific to the device vendor". Consider rephrasing - the objects are n= ot specific to vendors or else they wouldn't be specified here but augmente= d instead; what is meant are that the values/how the objects are populated = is vendor specific. Consider stating e.g. "... and intended to be populate= d by the device vendor with values that may be specific to the device vendo= r." =20 Next sentence "... provided such as ..." --> "... provided, such as ..." General comment on the data model, not sure where to put (e.g. Section 2.2 = or 3): Should it be mentioned somewhere that some of the configurable infor= mation might also be auto-populated in certain implementations? For exampl= e, an NTP server could also be discovered and the information be automatica= lly populated by the system rather than the user. =20 Regards --- Alex =20 -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= David Kessens Sent: Tuesday, March 05, 2013 4:06 PM To: netmod@ietf.org Subject: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) Hi, I would hereby like to start a Last Call for: http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-05 Please indicate your support by Wed March 20, 2013. Or alternatively, let u= s know in the same timeframe whether there are still issues that need to be= resolved. Thanks! David Kessens co-chair netmod wg --- _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From alex@cisco.com Tue Mar 19 16:51:34 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1AA921F8D7F for ; Tue, 19 Mar 2013 16:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXVpb3FMGjt2 for ; Tue, 19 Mar 2013 16:51:34 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C57D021F8B04 for ; Tue, 19 Mar 2013 16:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2060; q=dns/txt; s=iport; t=1363737093; x=1364946693; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=MD0Ajd96/fpRw1eEQvIU1nJd+O7PzwTGtKG/vzgAyso=; b=aZ98AJhn7gmMAamMVPw/BgRbRFT0iulTuFnFXGxiDdgxMzbmQmQbhwly ApfezAuHnij+tyHcygnuI3A8YRsx1z79rbzVypcQ6sJWORAE+Gm+OHUoG E67GWYoSn68JHeiD7W/PGMRfqFEEkS4R5G3FFevrsc2ReOooSnETih6EB I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALH5SFGtJXG8/2dsb2JhbABDxQ+BRRZ0giQBAQEEAQEBGh00FwQCAQgRBAEBCxQJBycLFAkIAgQBEgiIDAyxeJAJjl0mEgaCWWEDl36PY4MKgig X-IronPort-AV: E=Sophos;i="4.84,874,1355097600"; d="scan'208";a="189336386" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 19 Mar 2013 23:51:33 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2JNpXVa019201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 23:51:33 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.147]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 18:51:33 -0500 From: "Alexander Clemm (alex)" To: David Kessens , "netmod@ietf.org" Thread-Topic: [netmod] Last Call draft-ietf-netmod-snmp-cfg-01 (20130320) Thread-Index: AQHOGf49PGqzEhLhaUSFGtVQJQOb8ZitwWuA Date: Tue, 19 Mar 2013 23:51:32 +0000 Message-ID: References: <20130306000448.GF2854@nsn.com> In-Reply-To: <20130306000448.GF2854@nsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.200.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] Last Call draft-ietf-netmod-snmp-cfg-01 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 23:51:34 -0000 Hi, I have looked at the draft and have the following comments: - Because it is heavily dependent on very specific background in the corres= ponding SNMP MIBs, I think a definitions & acronyms section would be helpfu= l. There are many terms whose meaning is not immediately obvious and which= require constant referencing other standards, making this spec less self-c= ontained than it could be. Examples are terms such as ""notification filt= er profile" or "proxy target" - It would be useful to explain in the introduction why the YANG module is = specifically defined, and not simply a MIB-to-YANG conversion should be use= d. Because so close to the corresponding SNMP MIBs, the module is not very= "self-explanatory" by itself - you really need to know the MIB module to u= nderstand what is going on, and this really feels like a "generated" module= in a way. For the same reason, some brief additional explanation/overview= in sections 2.x would be useful. =20 - Add the boilerplate statement explaining the syntax of the "shorthand not= ation" for the module structure where it is first used (e.g. before section= 2.3) - The security considerations (section 5) contain a couple of "tbd's" that = need to be completed ("= ") --- Alex -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= David Kessens Sent: Tuesday, March 05, 2013 4:05 PM To: netmod@ietf.org Subject: [netmod] Last Call draft-ietf-netmod-snmp-cfg-01 (20130320) I would hereby like to start a Last Call for: http://tools.ietf.org/html/draft-ietf-netmod-snmp-cfg-01 Please indicate your support by Wed March 20, 2013. Or alternatively, let u= s know in the same timeframe whether there are still issues that need to be= resolved. Thanks! David Kessens co-chair netmod wg --- _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From yihuan@cisco.com Tue Mar 19 18:03:03 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B0721F8CB4 for ; Tue, 19 Mar 2013 18:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyoqWM2ollYD for ; Tue, 19 Mar 2013 18:03:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3B76B21F8B9F for ; Tue, 19 Mar 2013 18:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1844; q=dns/txt; s=iport; t=1363741383; x=1364950983; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=X8Rvbe155kl5wC1yDYHDUSaqdFtITXPAyRrZOXO9uj0=; b=GnD/f59tiKwIBFjMcEtJmlj5DCgq8UC3FHlXByIhOKqKL8VqlAdUrlBV v351kkCerOlXrcQZs2srRg3RMcBPc97QGDb5+5JWNAqpu/1mbRgpBzyOO qBrx1xgdEfAi9fVJUm6N3NGThUMtuvLFgpi22YHhnn95vRrSSlYHu4xAh A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAQJSVGtJXG+/2dsb2JhbABDxRCBRRZ0giQBAQEEAQEBGk0EFwYBCBEEAQELDg8uCxQJCAIEARIIiAwMtACNdY5dOAYSgkdhA5d+j2OCfQ2BbCQY X-IronPort-AV: E=Sophos;i="4.84,876,1355097600"; d="scan'208";a="189092525" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 20 Mar 2013 01:03:02 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2K132hw021096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Mar 2013 01:03:02 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 20:03:02 -0500 From: "Lisa Huang (yihuan)" To: David Kessens , "netmod@ietf.org" Thread-Topic: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) Thread-Index: AQHOGf5hddaDf7G5Ak6TzvhHD85G15iuEDaA//+nmYA= Date: Wed, 20 Mar 2013 01:03:01 +0000 Message-ID: <559E176269AD64429F1582D4EB94F86FCD2518@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.166.198] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1D567AA91013EB4DBDBFEF0BA1CA942B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 01:03:04 -0000 Hi, Here is my comment for typedef crypt-hash. The draft has the following definition: typedef crypt-hash { type string { pattern "$0$.*|$(1|5|6)$[a-zA-Z0-9./]{2,16}$.*"; } Description=20 " =8A. A value of this type matches one of the forms: $0$ $$$ } "$" is usually used as anchor (or positioning) in regular expression. The $ (dollar) means look only at the end of the target string, for example, fox$ will find a match in 'silver fox' since it appears at the end of the string but not in 'the fox jumped over the moon'. In the I-D, the pattern is trying to match "$0$" or "$$$", where "$" is a character in the string. I run some on line regular expression tool, none of them can validate the pattern but found adding escape characters before '$' solves the match. Thanks, Lisa > > =20 >-----Original Message----- >From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf >Of David Kessens >Sent: Tuesday, March 05, 2013 4:06 PM >To: netmod@ietf.org >Subject: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) > > >Hi, > >I would hereby like to start a Last Call for: > >http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-05 > >Please indicate your support by Wed March 20, 2013. Or alternatively, let >us know in the same timeframe whether there are still issues that need to >be resolved. > >Thanks! > >David Kessens >co-chair netmod wg >--- >_______________________________________________ >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 xiangli@seguesoft.com Tue Mar 19 19:13:01 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D8F21F8DE3 for ; Tue, 19 Mar 2013 19:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.99 X-Spam-Level: *** X-Spam-Status: No, score=3.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVV1lDaIoSSK for ; Tue, 19 Mar 2013 19:13:00 -0700 (PDT) Received: from p3plsmtpa07-05.prod.phx3.secureserver.net (p3plsmtpa07-05.prod.phx3.secureserver.net [173.201.192.234]) by ietfa.amsl.com (Postfix) with ESMTP id AB5E721F8D3C for ; Tue, 19 Mar 2013 19:13:00 -0700 (PDT) Received: from [192.168.2.16] ([98.212.151.151]) by p3plsmtpa07-05.prod.phx3.secureserver.net with id DeCz1l0043GEayi01eCzRK; Tue, 19 Mar 2013 19:13:00 -0700 Message-ID: <51491B2C.2040806@seguesoft.com> Date: Tue, 19 Mar 2013 21:13:00 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: netmod@ietf.org References: <559E176269AD64429F1582D4EB94F86FCD2518@xmb-aln-x03.cisco.com> In-Reply-To: <559E176269AD64429F1582D4EB94F86FCD2518@xmb-aln-x03.cisco.com> Content-Type: multipart/alternative; boundary="------------050100070308030703090007" Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 02:13:01 -0000 This is a multi-part message in MIME format. --------------050100070308030703090007 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 3/19/2013 8:03 PM, Lisa Huang (yihuan) wrote: > Hi, > > Here is my comment for typedef crypt-hash. The draft has the following > definition: > > typedef crypt-hash { > type string { > pattern "$0$.*|$(1|5|6)$[a-zA-Z0-9./]{2,16}$.*"; > } > Description > " > Š. > > A value of this type matches one of the forms: > > $0$ > $$$ > > } > > "$" is usually used as anchor (or positioning) in regular expression. The > $ (dollar) means look only at the end of the target string, for example, > fox$ will find a match in 'silver fox' since it appears at the end of the > string but not in 'the fox jumped over the moon'. > > > > In the I-D, the pattern is trying to match "$0$" or > "$$$", where "$" is a character in the string. I > run some on line regular expression tool, none of them can validate the > pattern but found adding escape characters before '$' solves the match. I had the same question a while back. I then found out that the "regular string" used by YANG "pattern" is defined in: RFC6020 Normative References [XSD-TYPES] http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#regexs The regular expression language defined in above doc implicitly anchors all regular expressions at the head and tail. Further it does not define "$" as a special character. It's a bit different than other regular strings such as Perl in this case. ** --Xiang > > Thanks, > > Lisa > >> >> -----Original Message----- >> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf >> Of David Kessens >> Sent: Tuesday, March 05, 2013 4:06 PM >> To: netmod@ietf.org >> Subject: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) >> >> >> Hi, >> >> I would hereby like to start a Last Call for: >> >> http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-05 >> >> Please indicate your support by Wed March 20, 2013. Or alternatively, let >> us know in the same timeframe whether there are still issues that need to >> be resolved. >> >> Thanks! >> >> David Kessens >> co-chair netmod wg >> --- >> _______________________________________________ >> 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 -- -- Xiang Li Web: www.seguesoft.com Voice: 1 (217) 472-4108 Cell 1 (217) 819-0942 --------------050100070308030703090007 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 3/19/2013 8:03 PM, Lisa Huang (yihuan) wrote:
Hi,

Here is my comment for typedef crypt-hash. The draft has the following
definition:

typedef crypt-hash {
  type string {
     pattern "$0$.*|$(1|5|6)$[a-zA-Z0-9./]{2,16}$.*";
  }
  Description 
  "
  Š.

  A value of this type matches one of the forms:

  $0$<clear text password>
  $<id>$<salt>$<password hash>

}

"$" is usually used as anchor (or positioning) in regular expression. The
$ (dollar) means look only at the end of the target string, for example,
fox$ will find a match in 'silver fox' since it appears at the end of the
string but not in 'the fox jumped over the moon'.



In the I-D, the pattern is trying to match "$0$<clear text password>" or
"$<id>$<salt>$<password hash>", where "$" is a character in the string. I
run some on line regular expression tool, none of them can validate the
pattern but found adding escape characters before '$' solves the match.

I had the same question a while back. I then found out that the "regular string" used
by YANG "pattern"  is defined in:

RFC6020  Normative References 
[XSD-TYPES]  http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#regexs
The regular expression language defined in above doc implicitly anchors all regular
expressions at the head and tail.

Further it does not define "$" as a special character. It's a bit different than
other regular strings such as Perl in this case.

--Xiang



Thanks,

Lisa


 
-----Original Message-----
From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf
Of David Kessens
Sent: Tuesday, March 05, 2013 4:06 PM
To: netmod@ietf.org
Subject: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320)


Hi,

I would hereby like to start a Last Call for:

http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-05

Please indicate your support by Wed March 20, 2013. Or alternatively, let
us know in the same timeframe whether there are still issues that need to
be resolved.

Thanks!

David Kessens
co-chair netmod wg
---
_______________________________________________
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


-- 
--
Xiang Li
Web: www.seguesoft.com
Voice:   1 (217) 472-4108 Cell 1 (217) 819-0942
--------------050100070308030703090007-- From yihuan@cisco.com Tue Mar 19 19:51:27 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724A721F87A4 for ; Tue, 19 Mar 2013 19:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.01 X-Spam-Level: X-Spam-Status: No, score=-4.01 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy7Ta8lFa0SU for ; Tue, 19 Mar 2013 19:51:26 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 53AFB21F86B7 for ; Tue, 19 Mar 2013 19:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9267; q=dns/txt; s=iport; t=1363747886; x=1364957486; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=bBp/NlBDd4dejE0AjkVROYwfqZLXB7LEfLHzffmlGg4=; b=Hkf1WPOv/O99xgOcv5FRPiJvi7lII6GOsjZUwvBGU8SIumVrdfLVaz7h DfU1rgUuUjIwP/qSmsp3XDXN8lp43fmqnf/fxpMVNYISwo0IOdl4VXxua 713qp+S3/7+E4LehHTcsUmkXy4yVZyh701NaynV8KRac7sA4T5s4n5bgk 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAJwjSVGtJXG8/2dsb2JhbABAA4N/wROBQhZ0giQBAQEEAQEBGiwhBBcGAQgRAwEBAQsODy4LFAkIAgQBEggBiAsMs3yNZheMPIIiAR8BBQgCBwEGCweCR2EDl3+PY4J9DYFsJBg X-IronPort-AV: E=Sophos;i="4.84,876,1355097600"; d="scan'208,217";a="189358650" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 20 Mar 2013 02:51:25 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2K2pPrY028766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Mar 2013 02:51:25 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 21:51:25 -0500 From: "Lisa Huang (yihuan)" To: Xiang Li , "netmod@ietf.org" Thread-Topic: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) Thread-Index: AQHOGf5hddaDf7G5Ak6TzvhHD85G15iuEDaA//+nmYCAAIjpAP//lWGA Date: Wed, 20 Mar 2013 02:51:24 +0000 Message-ID: <559E176269AD64429F1582D4EB94F86FCD2659@xmb-aln-x03.cisco.com> In-Reply-To: <51491B2C.2040806@seguesoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.166.198] Content-Type: multipart/alternative; boundary="_000_559E176269AD64429F1582D4EB94F86FCD2659xmbalnx03ciscocom_" MIME-Version: 1.0 Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 02:51:27 -0000 --_000_559E176269AD64429F1582D4EB94F86FCD2659xmbalnx03ciscocom_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Thanks for the clarification. From: Xiang Li > Date: Tuesday, March 19, 2013 7:13 PM To: "netmod@ietf.org" > Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) On 3/19/2013 8:03 PM, Lisa Huang (yihuan) wrote: Hi, Here is my comment for typedef crypt-hash. The draft has the following definition: typedef crypt-hash { type string { pattern "$0$.*|$(1|5|6)$[a-zA-Z0-9./]{2,16}$.*"; } Description " =A9. A value of this type matches one of the forms: $0$ $$$ } "$" is usually used as anchor (or positioning) in regular expression. The $ (dollar) means look only at the end of the target string, for example, fox$ will find a match in 'silver fox' since it appears at the end of the string but not in 'the fox jumped over the moon'. In the I-D, the pattern is trying to match "$0$" or "$$$", where "$" is a character in the string. I run some on line regular expression tool, none of them can validate the pattern but found adding escape characters before '$' solves the match. I had the same question a while back. I then found out that the "regular st= ring" used by YANG "pattern" is defined in: RFC6020 Normative References [XSD-TYPES] http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#regexs The regular expression language defined in above doc implicitly anchors all= regular expressions at the head and tail. Further it does not define "$" as a special character. It's a bit different= than other regular strings such as Perl in this case. --Xiang Thanks, Lisa -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmo= d-bounces@ietf.org] On Behalf Of David Kessens Sent: Tuesday, March 05, 2013 4:06 PM To: netmod@ietf.org Subject: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) Hi, I would hereby like to start a Last Call for: http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-05 Please indicate your support by Wed March 20, 2013. Or alternatively, let us know in the same timeframe whether there are still issues that need to be resolved. Thanks! David Kessens co-chair netmod wg --- _______________________________________________ netmod mailing list netmod@ietf.orghttps://www.ietf.org/mailman/listinf= o/netmod _______________________________________________ netmod mailing list netmod@ietf.orghttps://www.ietf.org/mailman/listinf= o/netmod _______________________________________________ netmod mailing list netmod@ietf.orghttps://www.ietf.org/mailman/listinf= o/netmod -- -- Xiang Li Web: www.seguesoft.com Voice: 1 (217) 472-4108 Cell 1 (217) 819-0942 --_000_559E176269AD64429F1582D4EB94F86FCD2659xmbalnx03ciscocom_ Content-Type: text/html; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable
Thanks for the clarification.

From: Xiang Li <xiangli@seguesoft.com>
Date: Tuesday, March 19, 2013 7:13 = PM
To: "netmod@ietf.org" <= netmod@ietf.org>
Subject: Re: [netmod] Last Call dra= ft-ietf-netmod-system-mgmt-05 (20130320)


On 3/19/2013 8:03 PM, Lisa Huang (yihuan) wr= ote:
Hi,

Here is my comment for typedef crypt-hash. The draft has the following
definition:

typedef crypt-hash {
  type string {
     pattern "$0$.*|$(1|5|6)$[a-zA-Z0-9./]{2,16}$.*";
  }
  Description=20
  "
  =A9.

  A value of this type matches one of the forms:

  $0$<clear text password>
  $<id>$<salt>$<password hash>

}

"$" is usually used as anchor (or positioning) in regular express=
ion. The
$ (dollar) means look only at the end of the target string, for example,
fox$ will find a match in 'silver fox' since it appears at the end of the
string but not in 'the fox jumped over the moon'.



In the I-D, the pattern is trying to match "$0$<clear text password=
>" or
"$<id>$<salt>$<password hash>", where "$&q=
uot; is a character in the string. I
run some on line regular expression tool, none of them can validate the
pattern but found adding escape characters before '$' solves the match.

I had the same question a while back. I then found out that the "regul= ar string" used
by YANG "pattern"  is defined in:

RFC6020  Normative References 
[XSD-TYPES]  http://www.=
w3.org/TR/2004/REC-xmlschema-2-20041028/#regexs
The regular expression language defined in above doc implicitly anchors all= regular
expressions at the head and tail.

Further it does not define "$" as a special character. It's a bit= different than
other regular strings such as Perl in this case.

--Xiang


Thanks,

Lisa


=20
-----Original Message-----
From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] O=
n Behalf
Of David Kessens
Sent: Tuesday, March 05, 2013 4:06 PM
To: n=
etmod@ietf.org
Subject: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320)


Hi,

I would hereby like to start a Last Call for:

http://tools.ietf.org/html/draft-ietf-netmod-s=
ystem-mgmt-05

Please indicate your support by Wed March 20, 2013. Or alternatively, let
us know in the same timeframe whether there are still issues that need to
be resolved.

Thanks!

David Kessens
co-chair netmod wg
---
_______________________________________________
netmod mailing list
netmo=
d@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmo=
d@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmo=
d@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod

--=20
--
Xiang Li
Web: www.seguesoft.com
Voice:   1 (217) 472-4108 Cell 1 (217) 819-0942
 --_000_559E176269AD64429F1582D4EB94F86FCD2659xmbalnx03ciscocom_-- From lhotka@nic.cz Tue Mar 19 23:02:31 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B7E21F8455 for ; Tue, 19 Mar 2013 23:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.462 X-Spam-Level: * X-Spam-Status: No, score=1.462 tagged_above=-999 required=5 tests=[AWL=-3.127, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwbgG63Ijw+e for ; Tue, 19 Mar 2013 23:02:29 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA0121F8433 for ; Tue, 19 Mar 2013 23:02:29 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 74A0013FAA1; Wed, 20 Mar 2013 07:02:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1363759348; bh=+qCzQO0lS3+5Z80WlS7I5R8hQDIRZ6mKrICIhONgQyg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=deVcKOaEPA1YlS45ac9jbv5PzxCPC3Q5akIY8NR4HoD3CMikXJemTesjN7CKbmxxL BkrTYHZ+4R0ZuUAV81zg1fWHHqWBo581VOaGNbK4UT2sa7aT0UK9dJt9qc8fWj/iYD 6PkULAxtmOQcEc2uQ+GKTEkera2NHr3fxvE72+DM= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: <559E176269AD64429F1582D4EB94F86FCD2518@xmb-aln-x03.cisco.com> Date: Wed, 20 Mar 2013 07:01:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <92E620A7-040C-4624-840C-75182E13EE0B@nic.cz> References: <559E176269AD64429F1582D4EB94F86FCD2518@xmb-aln-x03.cisco.com> To: "Lisa Huang (yihuan)" X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 06:02:31 -0000 Hi Lisa, YANG specifically uses the regular expression syntax defined in "XML = Schema: Datatypes", see section 9.4.6 in RFC 6020. In this case, the = string value is always matched in its entirety, as if the regular = expression was always enclosed in ^=85$. Consequently, the special = sentinel characters are not needed and so ^ and $ can be used as = literals without escaping (except in [^=85]). Lada =20 On Mar 20, 2013, at 2:03 AM, "Lisa Huang (yihuan)" = wrote: > Hi, >=20 > Here is my comment for typedef crypt-hash. The draft has the following > definition: >=20 > typedef crypt-hash { > type string { > pattern "$0$.*|$(1|5|6)$[a-zA-Z0-9./]{2,16}$.*"; > } > Description=20 > " > =8A. >=20 > A value of this type matches one of the forms: >=20 > $0$ > $$$ >=20 > } >=20 > "$" is usually used as anchor (or positioning) in regular expression. = The > $ (dollar) means look only at the end of the target string, for = example, > fox$ will find a match in 'silver fox' since it appears at the end of = the > string but not in 'the fox jumped over the moon'. >=20 >=20 >=20 > In the I-D, the pattern is trying to match "$0$" = or > "$$$", where "$" is a character in the = string. I > run some on line regular expression tool, none of them can validate = the > pattern but found adding escape characters before '$' solves the = match. >=20 >=20 > Thanks, >=20 > Lisa >=20 >>=20 >>=20 >> -----Original Message----- >> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On = Behalf >> Of David Kessens >> Sent: Tuesday, March 05, 2013 4:06 PM >> To: netmod@ietf.org >> Subject: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 = (20130320) >>=20 >>=20 >> Hi, >>=20 >> I would hereby like to start a Last Call for: >>=20 >> http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-05 >>=20 >> Please indicate your support by Wed March 20, 2013. Or alternatively, = let >> us know in the same timeframe whether there are still issues that = need to >> be resolved. >>=20 >> Thanks! >>=20 >> David Kessens >> co-chair netmod wg >> --- >> _______________________________________________ >> 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 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From yihuan@cisco.com Wed Mar 20 10:16:37 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECD521F8F7D for ; Wed, 20 Mar 2013 10:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.71 X-Spam-Level: X-Spam-Status: No, score=-3.71 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2d8xe6y0AL7h for ; Wed, 20 Mar 2013 10:16:36 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 388DD21F8CDF for ; Wed, 20 Mar 2013 10:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3078; q=dns/txt; s=iport; t=1363799796; x=1365009396; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=uss3TS0UPqA1ldAW0rcZUhVuwZ/kYVhpawIvb0Ug7RA=; b=lkFB0qcQ0rljX03pLARWkM/1iPVnleBuLy4mTikROozQG/PRy9NeswRz uScqDTEH/30g7Bn+dAg7z3wxppdE9X+luImt5Lbi9jAmTF1ncyyJDb7c/ UH+5h5eVhb6D4a1GZBfj9Iu/t40BJPdn/X4ym7/9guAYx9KPKpnFz/k9+ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOrrSVGtJV2d/2dsb2JhbABExRqBTxZ0giQBAQEEAQEBGk0ECwwGAQgRBAEBCw4PLgsUCQgCBA4FCIgMDMJbjlwCJgsHBhKCR2EDl3+PY4MKgWwkGA X-IronPort-AV: E=Sophos;i="4.84,880,1355097600"; d="scan'208";a="189643907" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 20 Mar 2013 17:16:35 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2KHGZW0017915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Mar 2013 17:16:35 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Wed, 20 Mar 2013 12:16:34 -0500 From: "Lisa Huang (yihuan)" To: Ladislav Lhotka Thread-Topic: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) Thread-Index: AQHOGf5hddaDf7G5Ak6TzvhHD85G15iuEDaA//+nmYCAAMjXgIAARy+A Date: Wed, 20 Mar 2013 17:16:33 +0000 Message-ID: <559E176269AD64429F1582D4EB94F86FCD31E9@xmb-aln-x03.cisco.com> In-Reply-To: <92E620A7-040C-4624-840C-75182E13EE0B@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.203.136] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <9D633D2923C55345971E00EFCE864ED9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 17:16:37 -0000 Right. The second half " the special sentinel characters are not needed and so ^ and $ can be used as literals without escaping (except in [^...])" is implicit.=20 On 3/19/13 11:01 PM, "Ladislav Lhotka" wrote: >Hi Lisa, > >YANG specifically uses the regular expression syntax defined in "XML >Schema: Datatypes", see section 9.4.6 in RFC 6020. In this case, the >string value is always matched in its entirety, as if the regular >expression was always enclosed in ^...$. Consequently, the special sentine= l >characters are not needed and so ^ and $ can be used as literals without >escaping (except in [^...]). > >Lada > =20 >On Mar 20, 2013, at 2:03 AM, "Lisa Huang (yihuan)" >wrote: > >> Hi, >>=20 >> Here is my comment for typedef crypt-hash. The draft has the following >> definition: >>=20 >> typedef crypt-hash { >> type string { >> pattern "$0$.*|$(1|5|6)$[a-zA-Z0-9./]{2,16}$.*"; >> } >> Description=20 >> " >> =A9. >>=20 >> A value of this type matches one of the forms: >>=20 >> $0$ >> $$$ >>=20 >> } >>=20 >> "$" is usually used as anchor (or positioning) in regular expression. >>The >> $ (dollar) means look only at the end of the target string, for example, >> fox$ will find a match in 'silver fox' since it appears at the end of >>the >> string but not in 'the fox jumped over the moon'. >>=20 >>=20 >>=20 >> In the I-D, the pattern is trying to match "$0$" or >> "$$$", where "$" is a character in the string. >>I >> run some on line regular expression tool, none of them can validate the >> pattern but found adding escape characters before '$' solves the match. >>=20 >>=20 >> Thanks, >>=20 >> Lisa >>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On >>>Behalf >>> Of David Kessens >>> Sent: Tuesday, March 05, 2013 4:06 PM >>> To: netmod@ietf.org >>> Subject: [netmod] Last Call draft-ietf-netmod-system-mgmt-05 (20130320) >>>=20 >>>=20 >>> Hi, >>>=20 >>> I would hereby like to start a Last Call for: >>>=20 >>> http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-05 >>>=20 >>> Please indicate your support by Wed March 20, 2013. Or alternatively, >>>let >>> us know in the same timeframe whether there are still issues that need >>>to >>> be resolved. >>>=20 >>> Thanks! >>>=20 >>> David Kessens >>> co-chair netmod wg >>> --- >>> _______________________________________________ >>> 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 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > >-- >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C > > > > From phil@juniper.net Wed Mar 20 11:30:16 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D047A1F0C36 for ; Wed, 20 Mar 2013 11:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vth80kvH7niD for ; Wed, 20 Mar 2013 11:30:16 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3D921F8936 for ; Wed, 20 Mar 2013 11:30:12 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUUoAM7c8EEfm0yjRmvlwI0TJKOpL3vrF@postini.com; Wed, 20 Mar 2013 11:30:16 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 20 Mar 2013 11:27:43 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r2KIRg377134; Wed, 20 Mar 2013 11:27:42 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id r2KIQesW066753; Wed, 20 Mar 2013 14:27:01 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201303201827.r2KIQesW066753@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Wed, 20 Mar 2013 14:26:40 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-groupings proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 18:30:17 -0000 Andy Bierman writes: > typedef parent-enabled { > type boolean; > default true; > description > "Indicates whether the parent container or list is enabled."; > } Why did this move from "disabled" back to "enabled"? Why isn't "parent-" implicit? Disable itself would be pointless. Thanks, Phil From alex@cisco.com Fri Mar 22 08:00:18 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DF521F8D27 for ; Fri, 22 Mar 2013 08:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usXdAV4HXo5e for ; Fri, 22 Mar 2013 08:00:16 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8776F21F8C66 for ; Fri, 22 Mar 2013 08:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5863; q=dns/txt; s=iport; t=1363964416; x=1365174016; h=from:to:cc:subject:date:message-id:mime-version; bh=S9VSAowxRGJvep0AjpAv61xFmcO2JgqKPfpBABEIpZs=; b=LGvxdv56rHVeuzQowWw5Icr+uJgbVFN+svtkc7DKiU8/cBsmfgeD0m3A 2EdOjoDRmXCbHoCxvjGO1JK4wBNbFORDlk9EEMNoOLubZzh7xCM4+zi3x l95bEcLI7/0e+5P5TwSYhPV0A8wxB4/KEjQhXDi1eUVHEN3WHLbmTImz8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAAVxTFGtJV2Z/2dsb2JhbABDhBu5DAGIKYFlFm0HgiYBBC1MEgEqViYBBA4NiAwMwjGJBIVdMYJmYQOYA4hdhwiDCoIo X-IronPort-AV: E=Sophos;i="4.84,892,1355097600"; d="scan'208,217";a="190462433" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 22 Mar 2013 15:00:15 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2MF0FVX000566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Mar 2013 15:00:15 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.147]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 10:00:15 -0500 From: "Alexander Clemm (alex)" To: "netmod@ietf.org" Thread-Topic: Mounting YANG-Defined Information from Remote Datastores Thread-Index: Ac4nDbVuUnWlik2KRgGCoCl67WLA8Q== Date: Fri, 22 Mar 2013 15:00:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.167.89] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B57183F37BDxmbrcdx05ciscoc_" MIME-Version: 1.0 Cc: "Eric Voit \(evoit\)" , "Jan Medved \(jmedved\)" Subject: [netmod] Mounting YANG-Defined Information from Remote Datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 15:00:18 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B57183F37BDxmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We just posted last night a new Internet Draft "Mounting YANG-Defined Infor= mation from Remote Datastores", see http://tools.ietf.org/html/draft-clemm= -netmod-mount-00. The draft addresses the problem of how to reference information from remote= datastores, without needing to actually replicate that information (in its= own model and datastore). This helps address multiple problems, for examp= le the issue of maintaining an authorative set of global configuration sett= ings that are shared and exposed by multiple devices, and the issue of allo= wing one device to expose information about the network and other devices w= ithout need for replication, but in a federated way. The abstract reads as follows: This document introduces a new capability that allows YANG datastores to reference and incorporate information from remote datastores. This is accomplished using a new YANG data model that allows to define and manage datastore mount points that reference data nodes in remote datastores. The data model includes a set of YANG extensions for the purposes of declaring such mount points. We are looking forward to discussing this with the working group and welcom= e your feedback. Regards --- Alex --_000_DBC595ED2346914F9F81D17DD5C32B57183F37BDxmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We just posted last night a new Internet Draft &#= 8220;Mounting YANG-Defined Information from Remote Datastores”, see&n= bsp; http://t= ools.ietf.org/html/draft-clemm-netmod-mount-00. 

 

The draft addresses the problem of how to referen= ce information from remote datastores, without needing to actually replicat= e that information (in its own model and datastore).  This helps addre= ss multiple problems, for example the issue of maintaining an authorative set of global configuration settings that ar= e shared and exposed by multiple devices, and the issue of allowing one dev= ice to expose information about the network and other devices without need = for replication, but in a federated way. 

 

The abstract reads as follows:

   This document introduces a new = capability that allows YANG datastores

   to reference and incorporate informa= tion from remote datastores.

   This is accomplished using a new YAN= G data model that allows to

   define and manage datastore mount po= ints that reference data nodes in

   remote datastores.  The data mo= del includes a set of YANG extensions

   for the purposes of declaring such m= ount points.

 

We are looking forward to discussing this with the w= orking group and welcome your feedback. 

 

Regards

--- Alex

--_000_DBC595ED2346914F9F81D17DD5C32B57183F37BDxmbrcdx05ciscoc_-- From andy@yumaworks.com Fri Mar 22 09:05:18 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C219B21F8E72 for ; Fri, 22 Mar 2013 09:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.583 X-Spam-Level: X-Spam-Status: No, score=-1.583 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0YJ+pyMRoJY for ; Fri, 22 Mar 2013 09:05:18 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id ABD6D21F8DE5 for ; Fri, 22 Mar 2013 09:05:17 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id tp5so659536ieb.36 for ; Fri, 22 Mar 2013 09:05:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=LDWHVmnAoNQWNgTWC44tRCH4XkQz61QJJTCdrYPZsQk=; b=i63Ga+aDMBiza7BLmQfn7UtQiAUmBYRDhEpaRE8dc9iqGj5FE/xzczKoIMyxXSzvIY cB/B/g/9l9q4+xrRTpJuWUqk+88YVwBzukpdYG+9acUE+B0AMcSa1fVmaO2YeAAX/0NH EjFkW87e0InyZiqamoXPLPPFOe+THwafNPHAdtcS7cBtCVqRIFlxxCD9WdiAGCXE4CHH 2HuC4R5vPVouiuA3KFdDYNcOdD7cNXmr2VqQz0QdsQE3rjRDjaq5DNPSiRNNIqNMMbnN m6wEQUwAPmvFUdUY3JwzMQ1wzpbk7ax58JkHEuxGL3Cc1g8BZKitNxgJBJEoQfGvaXlr gtPA== MIME-Version: 1.0 X-Received: by 10.50.17.131 with SMTP id o3mr1529945igd.112.1363968316628; Fri, 22 Mar 2013 09:05:16 -0700 (PDT) Received: by 10.231.34.68 with HTTP; Fri, 22 Mar 2013 09:05:16 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Mar 2013 09:05:16 -0700 Message-ID: From: Andy Bierman To: "Alexander Clemm (alex)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkD5xqjECXCCsjMMyk/JZFaTwhxva8AUkdfSea9i950JZ8eXhjKKXWKqKwupFmsabbBX4/l Cc: "Jan Medved \(jmedved\)" , "Eric Voit \(evoit\)" , "netmod@ietf.org" Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 16:05:18 -0000 Hi, I'm not sure I understand the use-cases here. This is certainly a different approach to network-wide config. This would seem to require that all the NETCONF servers sharing the same config subtree need to be highly coordinated, since operations on each server affect all the others. For example, if a client takes out a partial-lock on a shared node from server-1, it has to check all the other servers and the lock is shared across all servers. Access control would also be shared I guess. Do the contexts of shared nodes in candidate configs magically change or do they stay out-of-date if modified in another server? Does the entire running config in every server have to validate before any 1 server can commit a change to a shared node? The complexities this adds to the NETCONF transaction model and confirmed commit procedure are dramatic. The possibilities for must/when expressions to evaluate differently in each server just adds to the fun ;-) In previous discussions on network-wide configuration it was assumed a YANG model representing the network wide feature would be provided by a single server, and it is an implementation detail how that server interacts with other network devices. I do not see the advantages of treating the config like an NFS file system. Andy On Fri, Mar 22, 2013 at 8:00 AM, Alexander Clemm (alex) wr= ote: > Hi, > > > > We just posted last night a new Internet Draft =93Mounting YANG-Defined > Information from Remote Datastores=94, see > http://tools.ietf.org/html/draft-clemm-netmod-mount-00. > > > > The draft addresses the problem of how to reference information from remo= te > datastores, without needing to actually replicate that information (in it= s > own model and datastore). This helps address multiple problems, for exam= ple > the issue of maintaining an authorative set of global configuration setti= ngs > that are shared and exposed by multiple devices, and the issue of allowin= g > one device to expose information about the network and other devices with= out > need for replication, but in a federated way. > > > > The abstract reads as follows: > > This document introduces a new capability that allows YANG datastores > > to reference and incorporate information from remote datastores. > > This is accomplished using a new YANG data model that allows to > > define and manage datastore mount points that reference data nodes in > > remote datastores. The data model includes a set of YANG extensions > > for the purposes of declaring such mount points. > > > > We are looking forward to discussing this with the working group and welc= ome > your feedback. > > > > Regards > > --- Alex > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From bclaise@cisco.com Fri Mar 22 10:10:02 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0036621F8E7E for ; Fri, 22 Mar 2013 10:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YV4zoADtV3XX for ; Fri, 22 Mar 2013 10:10:01 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 376B721F8DF0 for ; Fri, 22 Mar 2013 10:09:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2MGsLH1025755; Fri, 22 Mar 2013 17:54:21 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2MGrfgx002951; Fri, 22 Mar 2013 17:53:56 +0100 (CET) Message-ID: <514C8C6F.60704@cisco.com> Date: Fri, 22 Mar 2013 17:53:03 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Martin Bjorklund Content-Type: multipart/alternative; boundary="------------090502010704090507040402" Cc: NETMOD Working Group Subject: [netmod] AD review of draft-ietf-netmod-iana-if-type-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 17:10:02 -0000 This is a multi-part message in MIME format. --------------090502010704090507040402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Martin, netmod participants, - IANAifType-MIB http://www.iana.org/assignments/smi-numbers/smi-numbers.xml There is a new value 273, which should be added to the draft, at first glance. Note: this entry 273 is called "Reserved". This is a weird name, because there is RFC6825 next to it. Am I correct that, if a second entry is called "Reserved", the enum would break? - Actually, in SAFI, we have the issue of multiple "Reserved" And I see that you have not modeled those "Reserved" entries. Surely because the enum would actually break. Clarifying question: Is this the right thing to do? Coming back to this entry 273 called "Reserved" in ifType, maybe the issue comes from the fact that IANA should have given a more meaningful name than "reserved". Maybe 'reserved-for-RFC6825", but that's a different story. - I don't see anything in the IANA considerations section regarding what to do for "reserved". Let's assume that this value 273 is added now in IANAifType-MIB, it's not clear from the text below what should IANA do with this YANG module: When an interface type is added to this registry, a new "enum" statement must be added to the "iana-if-type" typedef, with the same name and value as the corresponding enumeration in IANAifType-MIB. If the new interface type has a reference, a new "reference" statement should be added to the new "enum" statement. If an interface type is deprecated in the "ifType definitions" registry, the corresponding "enum" statement must be updated with a "status" statement with the value "deprecated". Maybe the solution is that we don't want to register the "reserved" value ... when pointing to the initial RFC that created the registry. - Same remark about "reserved" for SAFI If those issues have been discussed on the mailing list in the past, let me know. Regards, Benoit (OPS AD) --------------090502010704090507040402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Martin, netmod participants,

- IANAifType-MIB http://www.iana.org/assignments/smi-numbers/smi-numbers.xml
There is a new value 273, which should be added to the draft, at first glance.
Note: this entry 273 is called "Reserved". This is a weird name, because there is RFC6825 next to it.
Am I correct that, if a second entry is called "Reserved", the enum would break?

- Actually, in SAFI, we have the issue of multiple "Reserved"
And I see that you have not modeled those "Reserved" entries.
Surely because the enum would actually break.
Clarifying question: Is this the right thing to do?

Coming back to this entry 273 called "Reserved" in ifType, maybe the issue comes from the fact that IANA should have given a more meaningful name than "reserved". Maybe 'reserved-for-RFC6825", but that's a different story.

- I don't see anything in the IANA considerations section regarding what to do for "reserved".
Let's assume that this value 273 is added now in IANAifType-MIB, it's not clear from the text below what should IANA do with this YANG module:
When an interface type is added to this registry, a new "enum" statement must be added to the "iana-if-type" typedef, with the same name and value as the corresponding enumeration in IANAifType-MIB. If the new interface type has a reference, a new "reference" statement should be added to the new "enum" statement. If an interface type is deprecated in the "ifType definitions" registry, the corresponding "enum" statement must be updated with a "status" statement with the value "deprecated".
Maybe the solution is that we don't want to register the "reserved" value ... when pointing to the initial RFC that created the registry.

- Same remark about "reserved" for SAFI

If those issues have been discussed on the mailing list in the past, let me know.

Regards, Benoit (OPS AD)
--------------090502010704090507040402-- From bclaise@cisco.com Fri Mar 22 10:26:14 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1117221F8FD3 for ; Fri, 22 Mar 2013 10:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.384 X-Spam-Level: X-Spam-Status: No, score=-10.384 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0wcChmCe+T6 for ; Fri, 22 Mar 2013 10:26:13 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 35DDB21F8FBE for ; Fri, 22 Mar 2013 10:26:13 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2MHQBMG028507; Fri, 22 Mar 2013 18:26:11 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2MHPShG028618; Fri, 22 Mar 2013 18:25:44 +0100 (CET) Message-ID: <514C93E9.8@cisco.com> Date: Fri, 22 Mar 2013 18:24:57 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Juergen Schoenwaelder , NETMOD Working Group Content-Type: multipart/alternative; boundary="------------040907040009070006030702" Subject: [netmod] AD review of draft-ietf-netmod-rfc6021-bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 17:26:14 -0000 This is a multi-part message in MIME format. --------------040907040009070006030702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Juergen, NETMOD participants, Two comments 1. For the ip-address-no-zone, ipv4-address-no-zone, and ipv6-address-no-zone, don't you need a reference to the zone information in the description? description "The ip-address-no-zone type represents an IP address without zone information in an IP version neutral way. The format of the textual representations implies the IP version."; Doesn't give me a pointer to what a zone information is. So I don't know what ip-address-no-zone is. Note: I faced the zone issue only a year ago. Before that, I had no clue what it was. 2. The section "Appendix A. Changes from RFC 6021" is pretty light: This version adds new type definitions to the YANG modules. For the further details, see the revision statement of the YANG modules. Take it or leave it. However, I can tell that its resolution will please some IESG members, specifically because the rfcdiff tool doesn't do a good job of comparing RFC6021 with draft-ietf-netmod-rfc6021-bis-00.txt Proposal This version adds new type definitions to the YANG modules. The first YANG module, ietf-yang-types adds the following new data types: yang-identifier, hex-string, uuid, and dotted-quad. The second YANG module, ietf-inet-types, adds the following new data types: ip-address-no-zone, ipv4-address-no-zone, and ipv6-address-no-zone. Regards, Benoit (OPS AD) --------------040907040009070006030702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Juergen, NETMOD participants,

Two comments

1.
For the ip-address-no-zone, ipv4-address-no-zone, and ipv6-address-no-zone, don't you need a reference to the zone information in the description?
     description
        "The ip-address-no-zone type represents an IP address without
         zone information in an IP version neutral way.  The format
         of the textual representations implies the IP version.";
Doesn't give me a pointer to what a zone information is. So I don't know what ip-address-no-zone is.
Note: I faced the zone issue only a year ago. Before that, I had no clue what it was.


2.
The section "Appendix A. Changes from RFC 6021" is pretty light:
 This version adds new type definitions to the YANG modules. For the further details, see the revision statement of the YANG modules.
Take it or leave it. However, I can tell that its resolution will please some IESG members, specifically because the rfcdiff tool doesn't do a good job of comparing RFC6021 with draft-ietf-netmod-rfc6021-bis-00.txt

Proposal
 This version adds new type definitions to the YANG modules. The first YANG module, ietf-yang-types adds the following new data types: yang-identifier, hex-string, uuid, and dotted-quad. The second YANG module, ietf-inet-types, adds the following new data types: ip-address-no-zone, ipv4-address-no-zone, and ipv6-address-no-zone.
Regards, Benoit (OPS AD)
--------------040907040009070006030702-- From lhotka@nic.cz Fri Mar 22 10:49:46 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFA121F8F67 for ; Fri, 22 Mar 2013 10:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfKN4N9ZFVGn for ; Fri, 22 Mar 2013 10:49:46 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFC621F8E7C for ; Fri, 22 Mar 2013 10:49:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A5961540472; Fri, 22 Mar 2013 18:49:30 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ufHi4tFNdV1; Fri, 22 Mar 2013 18:49:21 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 5E65254032E; Fri, 22 Mar 2013 18:49:16 +0100 (CET) From: Ladislav Lhotka To: Benoit Claise , Martin Bjorklund In-Reply-To: <514C8C6F.60704@cisco.com> References: <514C8C6F.60704@cisco.com> User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Benoit Claise , Martin Bjorklund , NETMOD Working Group Date: Fri, 22 Mar 2013 18:49:15 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: NETMOD Working Group Subject: Re: [netmod] AD review of draft-ietf-netmod-iana-if-type-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 17:49:46 -0000 Benoit Claise writes: > Hi Martin, netmod participants, > > - IANAifType-MIB http://www.iana.org/assignments/smi-numbers/smi-numbers.xml > There is a new value 273, which should be added to the draft, at first > glance. > Note: this entry 273 is called "Reserved". This is a weird name, because > there is RFC6825 next to it. > Am I correct that, if a second entry is called "Reserved", the enum > would break? Yes. > > - Actually, in SAFI, we have the issue of multiple "Reserved" > And I see that you have not modeled those "Reserved" entries. > Surely because the enum would actually break. > Clarifying question: Is this the right thing to do? I think it is, as long as "reserved" means that it cannot be used in a configuration. > > Coming back to this entry 273 called "Reserved" in ifType, maybe the > issue comes from the fact that IANA should have given a more meaningful > name than "reserved". Maybe 'reserved-for-RFC6825", but that's a > different story. Perhaps even IANA couldn't figure out a more descriptive name. :-) > > - I don't see anything in the IANA considerations section regarding what > to do for "reserved". > Let's assume that this value 273 is added now in IANAifType-MIB, it's > not clear from the text below what should IANA do with this YANG module: > > When an interface type is added to this registry, a new "enum" > statement must be added to the "iana-if-type" typedef, with the same > name and value as the corresponding enumeration in IANAifType-MIB. > If the new interface type has a reference, a new "reference" > statement should be added to the new "enum" statement. If an > interface type is deprecated in the "ifType definitions" registry, > the corresponding "enum" statement must be updated with a "status" > statement with the value "deprecated". > > Maybe the solution is that we don't want to register the "reserved" > value ... when pointing to the initial RFC that created the registry. Yes, my understanding is that "reserved" doesn't mean a type registration, but of course the case you mentioned looks a bit special. > > - Same remark about "reserved" for SAFI > > If those issues have been discussed on the mailing list in the past, let > me know. No, I don't think so. Lada > > Regards, Benoit (OPS AD) > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Fri Mar 22 11:07:38 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DA121F852B for ; Fri, 22 Mar 2013 11:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFnb6KePW5jL for ; Fri, 22 Mar 2013 11:07:37 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4D67621F8431 for ; Fri, 22 Mar 2013 11:07:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id EA943540472; Fri, 22 Mar 2013 19:07:35 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFcq5fIicoe9; Fri, 22 Mar 2013 19:07:28 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 3DA7354032E; Fri, 22 Mar 2013 19:07:28 +0100 (CET) From: Ladislav Lhotka To: Benoit Claise , Juergen Schoenwaelder , NETMOD Working Group In-Reply-To: <514C93E9.8@cisco.com> References: <514C93E9.8@cisco.com> User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Benoit Claise , Juergen Schoenwaelder , NETMOD Working Group Date: Fri, 22 Mar 2013 19:07:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6021-bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 18:07:38 -0000 Benoit Claise writes: > Juergen, NETMOD participants, > > Two comments > > 1. > For the ip-address-no-zone, ipv4-address-no-zone, and > ipv6-address-no-zone, don't you need a reference to the zone information > in the description? > > description > "The ip-address-no-zone type represents an IP address without > zone information in an IP version neutral way. The format > of the textual representations implies the IP version."; > > Doesn't give me a pointer to what a zone information is. So I don't know > what ip-address-no-zone is. > Note: I faced the zone issue only a year ago. Before that, I had no clue > what it was. > Actually, I think it would be MUCH better to have "ipv4-address" with no mention of zone whatsoever, and then perhaps "ipv4-address-with-zone". The problem with this is that it is not backwards compatible with the old revision of the module. But maybe it should be done anyway. My main concern is that an implementor will see the "ipv4-address" type and will not bother to look up the definition to realize that the client may append the zone id without breaking type validity. This could lead to nasty security holes. And the problem is further amplified by the fact that this type is used in unions - "ip-address" and "host". > > 2. > The section "Appendix A. Changes from RFC 6021" is pretty light: > > This version adds new type definitions to the YANG modules. For > the further details, see the revision statement of the YANG modules. > > Take it or leave it. However, I can tell that its resolution will please > some IESG members, specifically because the rfcdiff tool doesn't do a > good job of comparing RFC6021 with draft-ietf-netmod-rfc6021-bis-00.txt > > Proposal > > This version adds new type definitions to the YANG modules. The > first YANG module, ietf-yang-types adds the following new data > types: yang-identifier, hex-string, uuid, and dotted-quad. The > second YANG module, ietf-inet-types, adds the following new data > types: ip-address-no-zone, ipv4-address-no-zone, and > ipv6-address-no-zone. +1. Lada > > Regards, Benoit (OPS AD) > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Fri Mar 22 14:03:53 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB7221F9198 for ; Fri, 22 Mar 2013 14:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.163 X-Spam-Level: X-Spam-Status: No, score=-103.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDIvQhFX5IYu for ; Fri, 22 Mar 2013 14:03:53 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A73DA21F9164 for ; Fri, 22 Mar 2013 14:03:52 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AEC9220C27; Fri, 22 Mar 2013 22:03:51 +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 zup2E_XN2bFt; Fri, 22 Mar 2013 22:03:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4181720C26; Fri, 22 Mar 2013 22:03:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E6391252C387; Fri, 22 Mar 2013 22:03:54 +0100 (CET) Date: Fri, 22 Mar 2013 22:03:54 +0100 From: Juergen Schoenwaelder To: Benoit Claise , NETMOD Working Group Message-ID: <20130322210354.GA16103@elstar.local> Mail-Followup-To: Benoit Claise , NETMOD Working Group References: <514C93E9.8@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6021-bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 21:03:53 -0000 On Fri, Mar 22, 2013 at 07:07:27PM +0100, Ladislav Lhotka wrote: > Benoit Claise writes: > > > Juergen, NETMOD participants, > > > > Two comments > > > > 1. > > For the ip-address-no-zone, ipv4-address-no-zone, and > > ipv6-address-no-zone, don't you need a reference to the zone information > > in the description? > > > > description > > "The ip-address-no-zone type represents an IP address without > > zone information in an IP version neutral way. The format > > of the textual representations implies the IP version."; > > > > Doesn't give me a pointer to what a zone information is. So I don't know > > what ip-address-no-zone is. > > Note: I faced the zone issue only a year ago. Before that, I had no clue > > what it was. > > > > Actually, I think it would be MUCH better to have "ipv4-address" with no mention of zone whatsoever, and then perhaps "ipv4-address-with-zone". > > The problem with this is that it is not backwards compatible with the old revision of the module. But maybe it should be done anyway. My main concern is that an implementor will see the "ipv4-address" type and will not bother to look up the definition to realize that the client may append the zone id without breaking type validity. This could lead to nasty security holes. > > And the problem is further amplified by the fact that this type is used in unions - "ip-address" and "host". Lada, we have been there, I believe there is no problem. And breaking interoperability is IMHO a no go. > > > > 2. > > The section "Appendix A. Changes from RFC 6021" is pretty light: > > > > This version adds new type definitions to the YANG modules. For > > the further details, see the revision statement of the YANG modules. > > > > Take it or leave it. However, I can tell that its resolution will please > > some IESG members, specifically because the rfcdiff tool doesn't do a > > good job of comparing RFC6021 with draft-ietf-netmod-rfc6021-bis-00.txt > > > > Proposal > > > > This version adds new type definitions to the YANG modules. The > > first YANG module, ietf-yang-types adds the following new data > > types: yang-identifier, hex-string, uuid, and dotted-quad. The > > second YANG module, ietf-inet-types, adds the following new data > > types: ip-address-no-zone, ipv4-address-no-zone, and > > ipv6-address-no-zone. > > +1. > > Lada > Sure, I will do whatever pleases the IESG and other readers that do not have the time to lookup the revision statements. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Fri Mar 22 15:39:48 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972C421F9451 for ; Fri, 22 Mar 2013 15:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.394 X-Spam-Level: X-Spam-Status: No, score=-10.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qexiiqyZeQth for ; Fri, 22 Mar 2013 15:39:47 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1F121F944B for ; Fri, 22 Mar 2013 15:39:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2MMSf1T023528 for ; Fri, 22 Mar 2013 23:28:41 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2MMSNpw027704 for ; Fri, 22 Mar 2013 23:28:34 +0100 (CET) Message-ID: <514CDAE7.401@cisco.com> Date: Fri, 22 Mar 2013 23:27:51 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: NETMOD Working Group References: <514C93E9.8@cisco.com> <20130322210354.GA16103@elstar.local> In-Reply-To: <20130322210354.GA16103@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6021-bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 22:39:48 -0000 On 22/03/2013 22:03, Juergen Schoenwaelder wrote: > On Fri, Mar 22, 2013 at 07:07:27PM +0100, Ladislav Lhotka wrote: >> Benoit Claise writes: >> >>> Juergen, NETMOD participants, >>> >>> Two comments >>> >>> 1. >>> For the ip-address-no-zone, ipv4-address-no-zone, and >>> ipv6-address-no-zone, don't you need a reference to the zone information >>> in the description? >>> >>> description >>> "The ip-address-no-zone type represents an IP address without >>> zone information in an IP version neutral way. The format >>> of the textual representations implies the IP version."; >>> >>> Doesn't give me a pointer to what a zone information is. So I don't know >>> what ip-address-no-zone is. >>> Note: I faced the zone issue only a year ago. Before that, I had no clue >>> what it was. >>> >> Actually, I think it would be MUCH better to have "ipv4-address" with no mention of zone whatsoever, and then perhaps "ipv4-address-with-zone". >> >> The problem with this is that it is not backwards compatible with the old revision of the module. But maybe it should be done anyway. My main concern is that an implementor will see the "ipv4-address" type and will not bother to look up the definition to realize that the client may append the zone id without breaking type validity. This could lead to nasty security holes. >> >> And the problem is further amplified by the fact that this type is used in unions - "ip-address" and "host". > Lada, we have been there, I believe there is no problem. And breaking > interoperability is IMHO a no go. Agreed. It's a no go > >>> 2. >>> The section "Appendix A. Changes from RFC 6021" is pretty light: >>> >>> This version adds new type definitions to the YANG modules. For >>> the further details, see the revision statement of the YANG modules. >>> >>> Take it or leave it. However, I can tell that its resolution will please >>> some IESG members, specifically because the rfcdiff tool doesn't do a >>> good job of comparing RFC6021 with draft-ietf-netmod-rfc6021-bis-00.txt >>> >>> Proposal >>> >>> This version adds new type definitions to the YANG modules. The >>> first YANG module, ietf-yang-types adds the following new data >>> types: yang-identifier, hex-string, uuid, and dotted-quad. The >>> second YANG module, ietf-inet-types, adds the following new data >>> types: ip-address-no-zone, ipv4-address-no-zone, and >>> ipv6-address-no-zone. >> +1. >> >> Lada >> > Sure, I will do whatever pleases the IESG and other readers that do > not have the time to lookup the revision statements. ;-) The time ... or the willingness ;-) Regards, Benoit > > /js > From alex@cisco.com Fri Mar 22 17:41:36 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36AE621F9020 for ; Fri, 22 Mar 2013 17:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsKFH1efpuUJ for ; Fri, 22 Mar 2013 17:41:35 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 19FB721F9011 for ; Fri, 22 Mar 2013 17:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5199; q=dns/txt; s=iport; t=1363999295; x=1365208895; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uzGunrr9x9gTOrtVqoCln4BPTXTXG7dilbOFgtj5oSA=; b=R+EUPEw2ifB9wU/Ptea6sXJUaQEuTmMcuQaZIxoOvYLAXkaWtC6mzlTV fxyy/RW9IWJI7WUJ9EZw5TSYZ7Vya8wExl/eZ16bbIrDuaBCOzfocSRbs cq4Ggadsosx7EFrRMl6Wj8KkEF39MbEAqc1sldKutHkjHclYvy0GF/KCU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANT4TFGtJXHA/2dsb2JhbABDxWaBaRZ0giQBAQEEAQEBNzQLDAQCAQgRBAEBAQoUCQcnCxQJCAEBBA4FCIgMDMFrjmcmCwcGgllhA5gDiF2HCIMKgWwkGA X-IronPort-AV: E=Sophos;i="4.84,895,1355097600"; d="scan'208";a="190614216" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 23 Mar 2013 00:41:34 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2N0fYk9010355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Mar 2013 00:41:34 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.147]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 19:41:34 -0500 From: "Alexander Clemm (alex)" To: "Andy Bierman (andy@yumaworks.com)" Thread-Topic: [netmod] Mounting YANG-Defined Information from Remote Datastores Thread-Index: Ac4nDbVuUnWlik2KRgGCoCl67WLA8QAMz5AAAAagufA= Date: Sat, 23 Mar 2013 00:41:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.32.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jan Medved \(jmedved\)" , "netmod@ietf.org" Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 00:41:36 -0000 Hello Andy, What we have in mind is a little less complicated than what you are concern= ed with. Think of a mount client as a client app, like other client apps. This can = be transparent to the owner/server of the datastore with the data items tha= t are mounted. The owner/server of the datastore with mounted data items r= eally isn't affected at all, nor are other client applications that interac= t with the same server; the mount client constitutes just another client ap= plication. The "ownership" of the data - the master copy, if you will - is= not in question, and not changed by our proposal. Validation still occurs= in the original datastore. The mount client merely "renders" the informat= ion that is retrieved, and operated on, in a way that makes it appear as if= it were part of its own datastore. However, the mount client now does hav= e the capability to validate "its" configurations in its own datastore (the= ones that it actually owns, not ones that are mounted) against other confi= gurations in the network. This is a problem today, where you need to rely = on external applications to ensure network-wide consistency. =20 Many uses for this only require providing visibility and the ability to ret= rieve information. Only some of the use cases involve the need to actually= modify information from remote. Where that is the case, the mount client = acts analogous to a provisioning application as far as the server is concer= ned. Obviously, transactionality is an issue for a mount client, just like= it is an issue to a provisioning application. Where a client app is not a= ble to obtain a needed lock, for instance, it cannot provide a lock to its = own applications, which is really no different from the situation that a pr= ovisioning application that provisions a service across a network would fac= e. =20 Regards --- Alex -----Original Message----- From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Friday, March 22, 2013 9:05 AM To: Alexander Clemm (alex) Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datasto= res Hi, I'm not sure I understand the use-cases here. This is certainly a different approach to network-wide config. This would seem to require that all the NETCONF servers sharing the same co= nfig subtree need to be highly coordinated, since operations on each server= affect all the others. For example, if a client takes out a partial-lock on a shared node from ser= ver-1, it has to check all the other servers and the lock is shared across = all servers. Access control would also be shared I guess. Do the contexts of shared nodes in candidate configs magically change or do= they stay out-of-date if modified in another server? Does the entire running config in every server have to validate before any = 1 server can commit a change to a shared node? The complexities this adds to the NETCONF transaction model and confirmed c= ommit procedure are dramatic. The possibilities for must/when expressions = to evaluate differently in each server just adds to the fun ;-) In previous discussions on network-wide configuration it was assumed a YANG= model representing the network wide feature would be provided by a single = server, and it is an implementation detail how that server interacts with o= ther network devices. I do not see the advantages of treating the config like an NFS file system. Andy On Fri, Mar 22, 2013 at 8:00 AM, Alexander Clemm (alex) wr= ote: > Hi, > > > > We just posted last night a new Internet Draft "Mounting YANG-Defined=20 > Information from Remote Datastores", see=20 > http://tools.ietf.org/html/draft-clemm-netmod-mount-00. > > > > The draft addresses the problem of how to reference information from=20 > remote datastores, without needing to actually replicate that=20 > information (in its own model and datastore). This helps address=20 > multiple problems, for example the issue of maintaining an authorative=20 > set of global configuration settings that are shared and exposed by=20 > multiple devices, and the issue of allowing one device to expose=20 > information about the network and other devices without need for replicat= ion, but in a federated way. > > > > The abstract reads as follows: > > This document introduces a new capability that allows YANG=20 > datastores > > to reference and incorporate information from remote datastores. > > This is accomplished using a new YANG data model that allows to > > define and manage datastore mount points that reference data nodes=20 > in > > remote datastores. The data model includes a set of YANG=20 > extensions > > for the purposes of declaring such mount points. > > > > We are looking forward to discussing this with the working group and=20 > welcome your feedback. > > > > Regards > > --- Alex > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From andy@yumaworks.com Fri Mar 22 18:26:30 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6397921F8E11 for ; Fri, 22 Mar 2013 18:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98V6x5-WWlKc for ; Fri, 22 Mar 2013 18:26:29 -0700 (PDT) Received: from mail-ia0-x22d.google.com (mail-ia0-x22d.google.com [IPv6:2607:f8b0:4001:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9143121F8E2C for ; Fri, 22 Mar 2013 18:26:29 -0700 (PDT) Received: by mail-ia0-f173.google.com with SMTP id h37so4073056iak.4 for ; Fri, 22 Mar 2013 18:26:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=MYwpIxfStjbB0J5EPwoBlVxhGjujX13ANrGTDRPH7uo=; b=C+k0KWx9fSRWtgAsjRutMu1vNGPHHIFvy0KM/k68Q2+IExEzmhuSHrMOSAHw8IQklL bT8bWOv9IPO2qDN7S9GD76xLbHUobv3C9WYa2jnqaaUBDvL2/xlm97wJ9lnbDimTdmsX dUKtUfwyV16LvjQ8CmFNu00iprbmQmnyzC5OpNwS161egLAu5aYgoNr3/kcjpRhnWFDv 4jKzS/pS6iY8xoK1yAJVl+F9URUYZ+nxzdMCVyDkLMx0UwmcGGVUNnEdngoMOLYMl7q2 /Km86O3HWyaBWytQaXbMqqGprxXqVpf36w/cxXk0aCW19zy+ryg2AFXFJxgQZatqm/On 2k7Q== MIME-Version: 1.0 X-Received: by 10.50.219.168 with SMTP id pp8mr6167029igc.57.1364001989023; Fri, 22 Mar 2013 18:26:29 -0700 (PDT) Received: by 10.231.34.68 with HTTP; Fri, 22 Mar 2013 18:26:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Mar 2013 18:26:28 -0700 Message-ID: From: Andy Bierman To: "Alexander Clemm (alex)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlYJyW5L/lmTy7GMiJcyTkb6fkV1jNDzrac6HCNecL3tFf77GbYy2YhyAH1dGSqyIk8mCFB Cc: "Jan Medved \(jmedved\)" , "netmod@ietf.org" Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 01:26:30 -0000 Hi, So a section of config is never actually shared? If 2 clients mount the same shared config sub-tree, then don't each of these servers think they own that sub-tree? But when 1 server modifies the shared data, isn't the data in the other server changed as well? Andy On Fri, Mar 22, 2013 at 5:41 PM, Alexander Clemm (alex) wr= ote: > Hello Andy, > > What we have in mind is a little less complicated than what you are conce= rned with. > > Think of a mount client as a client app, like other client apps. This ca= n be transparent to the owner/server of the datastore with the data items t= hat are mounted. The owner/server of the datastore with mounted data items= really isn't affected at all, nor are other client applications that inter= act with the same server; the mount client constitutes just another client = application. The "ownership" of the data - the master copy, if you will - = is not in question, and not changed by our proposal. Validation still occu= rs in the original datastore. The mount client merely "renders" the inform= ation that is retrieved, and operated on, in a way that makes it appear as = if it were part of its own datastore. However, the mount client now does h= ave the capability to validate "its" configurations in its own datastore (t= he ones that it actually owns, not ones that are mounted) against other con= figurations in the network. This is a problem today, where you need to rel= y on external applications to ensure network-wide consistency. > > Many uses for this only require providing visibility and the ability to r= etrieve information. Only some of the use cases involve the need to actual= ly modify information from remote. Where that is the case, the mount clien= t acts analogous to a provisioning application as far as the server is conc= erned. Obviously, transactionality is an issue for a mount client, just li= ke it is an issue to a provisioning application. Where a client app is not= able to obtain a needed lock, for instance, it cannot provide a lock to it= s own applications, which is really no different from the situation that a = provisioning application that provisions a service across a network would f= ace. > > Regards > --- Alex > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Friday, March 22, 2013 9:05 AM > To: Alexander Clemm (alex) > Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) > Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datas= tores > > Hi, > > I'm not sure I understand the use-cases here. > This is certainly a different approach to network-wide config. > This would seem to require that all the NETCONF servers sharing the same = config subtree need to be highly coordinated, since operations on each serv= er affect all the others. > > For example, if a client takes out a partial-lock on a shared node from s= erver-1, it has to check all the other servers and the lock is shared acros= s all servers. Access control would also be shared I guess. > > Do the contexts of shared nodes in candidate configs magically change or = do they stay out-of-date if modified in another server? > Does the entire running config in every server have to validate before an= y 1 server can commit a change to a shared node? > > The complexities this adds to the NETCONF transaction model and confirmed= commit procedure are dramatic. The possibilities for must/when expression= s to evaluate differently in each server just adds to the fun ;-) > > In previous discussions on network-wide configuration it was assumed a YA= NG model representing the network wide feature would be provided by a singl= e server, and it is an implementation detail how that server interacts with= other network devices. > > I do not see the advantages of treating the config like an NFS file syste= m. > > > > Andy > > > On Fri, Mar 22, 2013 at 8:00 AM, Alexander Clemm (alex) = wrote: >> Hi, >> >> >> >> We just posted last night a new Internet Draft "Mounting YANG-Defined >> Information from Remote Datastores", see >> http://tools.ietf.org/html/draft-clemm-netmod-mount-00. >> >> >> >> The draft addresses the problem of how to reference information from >> remote datastores, without needing to actually replicate that >> information (in its own model and datastore). This helps address >> multiple problems, for example the issue of maintaining an authorative >> set of global configuration settings that are shared and exposed by >> multiple devices, and the issue of allowing one device to expose >> information about the network and other devices without need for replica= tion, but in a federated way. >> >> >> >> The abstract reads as follows: >> >> This document introduces a new capability that allows YANG >> datastores >> >> to reference and incorporate information from remote datastores. >> >> This is accomplished using a new YANG data model that allows to >> >> define and manage datastore mount points that reference data nodes >> in >> >> remote datastores. The data model includes a set of YANG >> extensions >> >> for the purposes of declaring such mount points. >> >> >> >> We are looking forward to discussing this with the working group and >> welcome your feedback. >> >> >> >> Regards >> >> --- Alex >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> From andy@yumaworks.com Fri Mar 22 19:08:03 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA7921F8E7F for ; Fri, 22 Mar 2013 19:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ErLeiJwk4nL for ; Fri, 22 Mar 2013 19:08:02 -0700 (PDT) Received: from mail-ia0-x22d.google.com (mail-ia0-x22d.google.com [IPv6:2607:f8b0:4001:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 87C5D21F8735 for ; Fri, 22 Mar 2013 19:08:02 -0700 (PDT) Received: by mail-ia0-f173.google.com with SMTP id h37so4090836iak.32 for ; Fri, 22 Mar 2013 19:08:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=JK0nCScyV/t/FfNr05SDZ6Gs9vxroC211f6IKsclT9E=; b=BXwxVMcPxz9JHESsdWPyDOwUBUojqAI7Um+1V7O7tefkMWqUwJAYRjaPPT+MTil6GA dhHSU5nNBXjhcAXVCyVq/VmeUzyYZlMXXvOKIziRkv9GICQSN8Y/7gRyk7W8i8+EO5PE HBeXoqxkwRfoTo2RQwYGaPegWuUNSsU5MJ/OZPzj7HDK42xaCYGv26Fn853HS31A2q2L JzYPEwh7dhJ3nmhSJPrCUTYNdL9hUguCWDUMVS6mWW0DZmMMbUNNTRvYamk7fFiik4Rp ESbC76sfuUxfGIK4J2+1OsRoXg1OVItMAHx6V0wYqFua9hms7aHHeSwUwTy0m2Zm9EZ7 D/xA== MIME-Version: 1.0 X-Received: by 10.50.7.69 with SMTP id h5mr2784758iga.69.1364004482084; Fri, 22 Mar 2013 19:08:02 -0700 (PDT) Received: by 10.231.34.68 with HTTP; Fri, 22 Mar 2013 19:08:01 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Mar 2013 19:08:01 -0700 Message-ID: From: Andy Bierman To: "Alexander Clemm (alex)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlPxEo4pYsHkGntgq0WOXesONp3A+yqWBiT7zoQKzi0FlqgXvSJ5LXHoWZqtiCY0stsjeEQ Cc: "Jan Medved \(jmedved\)" , "netmod@ietf.org" Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 02:08:03 -0000 Hi, Let me try a simple example: There are 3 servers (S1, S2, S3): +------------------+ | S1 | --> /public +-----------------+ +------------------+ | S2 | --> mount(S1:/public) +-----------------+ +------------------+ | S3 | --> mount(S1:/public) +-----------------+ S1 is the server that is sharing the subtree /public. S2 and S3 both 'clients', and mount S1:/public in their configs. Any changes to /public done on any server magically appear on the other 2 servers. Correct or not? IMO, NFS is a fairly heavy-weight protocol and making NETCONF as complex as NFS is not a feature. Andy On Fri, Mar 22, 2013 at 5:41 PM, Alexander Clemm (alex) wr= ote: > Hello Andy, > > What we have in mind is a little less complicated than what you are conce= rned with. > > Think of a mount client as a client app, like other client apps. This ca= n be transparent to the owner/server of the datastore with the data items t= hat are mounted. The owner/server of the datastore with mounted data items= really isn't affected at all, nor are other client applications that inter= act with the same server; the mount client constitutes just another client = application. The "ownership" of the data - the master copy, if you will - = is not in question, and not changed by our proposal. Validation still occu= rs in the original datastore. The mount client merely "renders" the inform= ation that is retrieved, and operated on, in a way that makes it appear as = if it were part of its own datastore. However, the mount client now does h= ave the capability to validate "its" configurations in its own datastore (t= he ones that it actually owns, not ones that are mounted) against other con= figurations in the network. This is a problem today, where you need to rel= y on external applications to ensure network-wide consistency. > > Many uses for this only require providing visibility and the ability to r= etrieve information. Only some of the use cases involve the need to actual= ly modify information from remote. Where that is the case, the mount clien= t acts analogous to a provisioning application as far as the server is conc= erned. Obviously, transactionality is an issue for a mount client, just li= ke it is an issue to a provisioning application. Where a client app is not= able to obtain a needed lock, for instance, it cannot provide a lock to it= s own applications, which is really no different from the situation that a = provisioning application that provisions a service across a network would f= ace. > > Regards > --- Alex > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Friday, March 22, 2013 9:05 AM > To: Alexander Clemm (alex) > Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) > Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datas= tores > > Hi, > > I'm not sure I understand the use-cases here. > This is certainly a different approach to network-wide config. > This would seem to require that all the NETCONF servers sharing the same = config subtree need to be highly coordinated, since operations on each serv= er affect all the others. > > For example, if a client takes out a partial-lock on a shared node from s= erver-1, it has to check all the other servers and the lock is shared acros= s all servers. Access control would also be shared I guess. > > Do the contexts of shared nodes in candidate configs magically change or = do they stay out-of-date if modified in another server? > Does the entire running config in every server have to validate before an= y 1 server can commit a change to a shared node? > > The complexities this adds to the NETCONF transaction model and confirmed= commit procedure are dramatic. The possibilities for must/when expression= s to evaluate differently in each server just adds to the fun ;-) > > In previous discussions on network-wide configuration it was assumed a YA= NG model representing the network wide feature would be provided by a singl= e server, and it is an implementation detail how that server interacts with= other network devices. > > I do not see the advantages of treating the config like an NFS file syste= m. > > > > Andy > > > On Fri, Mar 22, 2013 at 8:00 AM, Alexander Clemm (alex) = wrote: >> Hi, >> >> >> >> We just posted last night a new Internet Draft "Mounting YANG-Defined >> Information from Remote Datastores", see >> http://tools.ietf.org/html/draft-clemm-netmod-mount-00. >> >> >> >> The draft addresses the problem of how to reference information from >> remote datastores, without needing to actually replicate that >> information (in its own model and datastore). This helps address >> multiple problems, for example the issue of maintaining an authorative >> set of global configuration settings that are shared and exposed by >> multiple devices, and the issue of allowing one device to expose >> information about the network and other devices without need for replica= tion, but in a federated way. >> >> >> >> The abstract reads as follows: >> >> This document introduces a new capability that allows YANG >> datastores >> >> to reference and incorporate information from remote datastores. >> >> This is accomplished using a new YANG data model that allows to >> >> define and manage datastore mount points that reference data nodes >> in >> >> remote datastores. The data model includes a set of YANG >> extensions >> >> for the purposes of declaring such mount points. >> >> >> >> We are looking forward to discussing this with the working group and >> welcome your feedback. >> >> >> >> Regards >> >> --- Alex >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> From lhotka@nic.cz Sat Mar 23 06:00:22 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343C421F8AF8 for ; Sat, 23 Mar 2013 06:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BBnHe0fW5QJ for ; Sat, 23 Mar 2013 06:00:21 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3835321F8AE7 for ; Sat, 23 Mar 2013 06:00:20 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 985E613F6A0; Sat, 23 Mar 2013 14:00:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1364043619; bh=dwpUWpl6IW+/zvn+/qbpf798LTYc/8FhcvDSnhM8n7Y=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Ol4GUXaxVsvbEwwm/HoHs9x7TynOMeYH89bCB72JLfrZEcTQQAW2ZJAoNqoqAIeqs hNzRHpqVTnhtxGK1+OQ1r3dybsUuAeIjL8gkUOa4s7ANPhISrTmx3PYC3GFg+TaIiv 9hdsA7Ogd2SAaLumGKiZbc6s1vL4PZ6wf+jJzMOM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: <514CDAE7.401@cisco.com> Date: Sat, 23 Mar 2013 14:00:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <514C93E9.8@cisco.com> <20130322210354.GA16103@elstar.local> <514CDAE7.401@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: NETMOD Working Group Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6021-bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 13:00:22 -0000 On Mar 22, 2013, at 11:27 PM, Benoit Claise wrote: > On 22/03/2013 22:03, Juergen Schoenwaelder wrote: >> On Fri, Mar 22, 2013 at 07:07:27PM +0100, Ladislav Lhotka wrote: >>> Benoit Claise writes: >>>=20 >>>> Juergen, NETMOD participants, >>>>=20 >>>> Two comments >>>>=20 >>>> 1. >>>> For the ip-address-no-zone, ipv4-address-no-zone, and >>>> ipv6-address-no-zone, don't you need a reference to the zone = information >>>> in the description? >>>>=20 >>>> description >>>> "The ip-address-no-zone type represents an IP address = without >>>> zone information in an IP version neutral way. The = format >>>> of the textual representations implies the IP version."; >>>>=20 >>>> Doesn't give me a pointer to what a zone information is. So I don't = know >>>> what ip-address-no-zone is. >>>> Note: I faced the zone issue only a year ago. Before that, I had no = clue >>>> what it was. >>>>=20 >>> Actually, I think it would be MUCH better to have "ipv4-address" = with no mention of zone whatsoever, and then perhaps = "ipv4-address-with-zone". >>>=20 >>> The problem with this is that it is not backwards compatible with = the old revision of the module. But maybe it should be done anyway. My = main concern is that an implementor will see the "ipv4-address" type and = will not bother to look up the definition to realize that the client may = append the zone id without breaking type validity. This could lead to = nasty security holes. >>>=20 >>> And the problem is further amplified by the fact that this type is = used in unions - "ip-address" and "host". >> Lada, we have been there, I believe there is no problem. And breaking >> interoperability is IMHO a no go. > Agreed. It's a no go OK, but I wonder - do we have any strategy for correcting mistakes in = our modules? They will be typically revealed only after a module is put = under stress and used in advanced data models. If breaking compatibility = is a no go, then we are pretty much stuck. Lada >> =20 >>>> 2. >>>> The section "Appendix A. Changes from RFC 6021" is pretty light: >>>>=20 >>>> This version adds new type definitions to the YANG modules. = For >>>> the further details, see the revision statement of the YANG = modules. >>>>=20 >>>> Take it or leave it. However, I can tell that its resolution will = please >>>> some IESG members, specifically because the rfcdiff tool doesn't do = a >>>> good job of comparing RFC6021 with = draft-ietf-netmod-rfc6021-bis-00.txt >>>>=20 >>>> Proposal >>>>=20 >>>> This version adds new type definitions to the YANG modules. = The >>>> first YANG module, ietf-yang-types adds the following new data >>>> types: yang-identifier, hex-string, uuid, and dotted-quad. The >>>> second YANG module, ietf-inet-types, adds the following new = data >>>> types: ip-address-no-zone, ipv4-address-no-zone, and >>>> ipv6-address-no-zone. >>> +1. >>>=20 >>> Lada >>> =20 >> Sure, I will do whatever pleases the IESG and other readers that do >> not have the time to lookup the revision statements. ;-) > The time ... or the willingness ;-) >=20 > Regards, Benoit >>=20 >> /js >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Sun Mar 24 02:21:06 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FBF21F8AB8 for ; Sun, 24 Mar 2013 02:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.174 X-Spam-Level: X-Spam-Status: No, score=-103.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dH-rOJbGufIE for ; Sun, 24 Mar 2013 02:21:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD4D21F89FB for ; Sun, 24 Mar 2013 02:21:05 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3750A20BEC; Sun, 24 Mar 2013 10:21:04 +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 Zo4g7N3NXTEm; Sun, 24 Mar 2013 10:21:04 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A61AB20BEA; Sun, 24 Mar 2013 10:21:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 03686252DAAE; Sun, 24 Mar 2013 10:21:07 +0100 (CET) Date: Sun, 24 Mar 2013 10:21:07 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20130324092107.GA19518@elstar.local> Mail-Followup-To: Ladislav Lhotka , Benoit Claise , NETMOD Working Group References: <514C93E9.8@cisco.com> <20130322210354.GA16103@elstar.local> <514CDAE7.401@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: NETMOD Working Group Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6021-bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 09:21:06 -0000 On Sat, Mar 23, 2013 at 02:00:19PM +0100, Ladislav Lhotka wrote: > > OK, but I wonder - do we have any strategy for correcting mistakes > in our modules? They will be typically revealed only after a module > is put under stress and used in advanced data models. If breaking > compatibility is a no go, then we are pretty much stuck. YANG has specific rules how to make changes. This is what we follow. In this particular case, I do not at all agree with you that there is a mistake to correct. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Sun Mar 24 02:22:25 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF4721F844C for ; Sun, 24 Mar 2013 02:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.182 X-Spam-Level: X-Spam-Status: No, score=-103.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mT9X3RvXLxVL for ; Sun, 24 Mar 2013 02:22:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AB04521F8440 for ; Sun, 24 Mar 2013 02:22:24 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15B0220BEC; Sun, 24 Mar 2013 10:22:24 +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 X4KTQiJtB2lk; Sun, 24 Mar 2013 10:22:24 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD8C420BEA; Sun, 24 Mar 2013 10:22:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AB5FA252DB14; Sun, 24 Mar 2013 10:22:28 +0100 (CET) Date: Sun, 24 Mar 2013 10:22:28 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20130324092228.GB19518@elstar.local> Mail-Followup-To: Benoit Claise , NETMOD Working Group References: <514C93E9.8@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <514C93E9.8@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: NETMOD Working Group Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6021-bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 09:22:25 -0000 Benoit, do you prefer to get a revised module before you do the IETF last call or do you just want the editors to track those changes and we post a revision at some later point during the process? /js On Fri, Mar 22, 2013 at 06:24:57PM +0100, Benoit Claise wrote: > Juergen, NETMOD participants, > > Two comments > > 1. > For the ip-address-no-zone, ipv4-address-no-zone, and > ipv6-address-no-zone, don't you need a reference to the zone > information in the description? > > description > "The ip-address-no-zone type represents an IP address without > zone information in an IP version neutral way. The format > of the textual representations implies the IP version."; > > Doesn't give me a pointer to what a zone information is. So I don't > know what ip-address-no-zone is. > Note: I faced the zone issue only a year ago. Before that, I had no > clue what it was. > > > 2. > The section "Appendix A. Changes from RFC 6021" is pretty light: > > This version adds new type definitions to the YANG modules. For > the further details, see the revision statement of the YANG modules. > > Take it or leave it. However, I can tell that its resolution will > please some IESG members, specifically because the rfcdiff tool > doesn't do a good job of comparing RFC6021 with > draft-ietf-netmod-rfc6021-bis-00.txt > > Proposal > > This version adds new type definitions to the YANG modules. The > first YANG module, ietf-yang-types adds the following new data > types: yang-identifier, hex-string, uuid, and dotted-quad. The > second YANG module, ietf-inet-types, adds the following new data > types: ip-address-no-zone, ipv4-address-no-zone, and > ipv6-address-no-zone. > > Regards, Benoit (OPS AD) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Sun Mar 24 09:18:31 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766E621F8D13 for ; Sun, 24 Mar 2013 09:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.574 X-Spam-Level: X-Spam-Status: No, score=-1.574 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUgqbHqByWVz for ; Sun, 24 Mar 2013 09:18:30 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C2B8821F8D09 for ; Sun, 24 Mar 2013 09:18:30 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9CDDA13F95F; Sun, 24 Mar 2013 17:18:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1364141909; bh=4d8eepV/PuJWFewLr+aituY9EinLSn3JBsyCCP7buok=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=W91sOkwmMzPBngKFE/g9rC8jr1rXMdQ60ABL/eUY0sb6iolY+Pxxdi6sDcAnegJgS rB0QaGdOvs2nnRiguC53FDM1EwRdGu1AhdliQoueBET6ZanEEQoZF9B3MhDCAj1bZa PYK6U+o9m0V3NxX//bTUfkvEt9S9zNPzEfGKxz1k= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: <20130324092107.GA19518@elstar.local> Date: Sun, 24 Mar 2013 17:18:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5162BD50-7673-4BBD-AAD7-A297ABE29906@nic.cz> References: <514C93E9.8@cisco.com> <20130322210354.GA16103@elstar.local> <514CDAE7.401@cisco.com> <20130324092107.GA19518@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: NETMOD Working Group Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6021-bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 16:18:31 -0000 On Mar 24, 2013, at 10:21 AM, Juergen Schoenwaelder = wrote: > On Sat, Mar 23, 2013 at 02:00:19PM +0100, Ladislav Lhotka wrote: >>=20 >> OK, but I wonder - do we have any strategy for correcting mistakes >> in our modules? They will be typically revealed only after a module >> is put under stress and used in advanced data models. If breaking >> compatibility is a no go, then we are pretty much stuck. >=20 > YANG has specific rules how to make changes. This is what we follow. > In this particular case, I do not at all agree with you that there > is a mistake to correct. My question had nothing to do with the particular problem of IP = addresses and zones, though I'd argue that ipv4-address-no-zone is at = least ugly and sounds to me like beef-no-horse. YANG change rules require strict backward compatibility. I am afraid it = is counterproductive at this stage because our initial YANG modules = generally get published before they have been thouroughly tested. It = would be quite daring to think that our work is flawless, despite all = the effort we put in it. What if we publish the routing module and then = get feedback from protocol implementors or I2RS, indicating that = something should be changed, and this something breaks compatibility? I believe errors should be corrected and significant improvements = implemented, and the sooner the better. It will be much harder after a = module becomes widely used. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Sun Mar 24 12:07:22 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFCF21F8576 for ; Sun, 24 Mar 2013 12:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.189 X-Spam-Level: X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHsJsc-9F9lE for ; Sun, 24 Mar 2013 12:07:22 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED2921F856D for ; Sun, 24 Mar 2013 12:07:22 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A70C820BDB; Sun, 24 Mar 2013 20:07:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VzDqn2s10r7X; Sun, 24 Mar 2013 20:07:21 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1855220BDA; Sun, 24 Mar 2013 20:07:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3E7CB252E3E1; Sun, 24 Mar 2013 20:07:24 +0100 (CET) Date: Sun, 24 Mar 2013 20:07:24 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20130324190724.GA20421@elstar.local> Mail-Followup-To: Ladislav Lhotka , Benoit Claise , NETMOD Working Group References: <514C93E9.8@cisco.com> <20130322210354.GA16103@elstar.local> <514CDAE7.401@cisco.com> <20130324092107.GA19518@elstar.local> <5162BD50-7673-4BBD-AAD7-A297ABE29906@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5162BD50-7673-4BBD-AAD7-A297ABE29906@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: NETMOD Working Group Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6021-bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 19:07:23 -0000 On Sun, Mar 24, 2013 at 05:18:29PM +0100, Ladislav Lhotka wrote: > > YANG change rules require strict backward compatibility. I am afraid it is counterproductive at this stage because our initial YANG modules generally get published before they have been thouroughly tested. It would be quite daring to think that our work is flawless, despite all the effort we put in it. What if we publish the routing module and then get feedback from protocol implementors or I2RS, indicating that something should be changed, and this something breaks compatibility? > > I believe errors should be corrected and significant improvements implemented, and the sooner the better. It will be much harder after a module becomes widely used. > If something is seriously flawed, it can be deprecated or even made historic and you start a second attempt. All this is possible. Changing the semantics of an existing published definition is generally a no go. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Mon Mar 25 02:20:25 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8F921F8EC2 for ; Mon, 25 Mar 2013 02:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcSxFIcfW9xf for ; Mon, 25 Mar 2013 02:20:24 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 73BEF21F8EBB for ; Mon, 25 Mar 2013 02:20:24 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2P9KNrC025508 for ; Mon, 25 Mar 2013 10:20:23 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2P9Jrq9011247 for ; Mon, 25 Mar 2013 10:20:03 +0100 (CET) Message-ID: <51501692.4050909@cisco.com> Date: Mon, 25 Mar 2013 10:19:14 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: NETMOD Working Group References: <514C93E9.8@cisco.com> <20130324092228.GB19518@elstar.local> In-Reply-To: <20130324092228.GB19518@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6021-bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 09:20:25 -0000 Hi Juergen, Please publish a new version, and the WG agrees on the solution. Regards, Benoit > Benoit, > > do you prefer to get a revised module before you do the IETF last call > or do you just want the editors to track those changes and we post a > revision at some later point during the process? > > /js > > On Fri, Mar 22, 2013 at 06:24:57PM +0100, Benoit Claise wrote: >> Juergen, NETMOD participants, >> >> Two comments >> >> 1. >> For the ip-address-no-zone, ipv4-address-no-zone, and >> ipv6-address-no-zone, don't you need a reference to the zone >> information in the description? >> >> description >> "The ip-address-no-zone type represents an IP address without >> zone information in an IP version neutral way. The format >> of the textual representations implies the IP version."; >> >> Doesn't give me a pointer to what a zone information is. So I don't >> know what ip-address-no-zone is. >> Note: I faced the zone issue only a year ago. Before that, I had no >> clue what it was. >> >> >> 2. >> The section "Appendix A. Changes from RFC 6021" is pretty light: >> >> This version adds new type definitions to the YANG modules. For >> the further details, see the revision statement of the YANG modules. >> >> Take it or leave it. However, I can tell that its resolution will >> please some IESG members, specifically because the rfcdiff tool >> doesn't do a good job of comparing RFC6021 with >> draft-ietf-netmod-rfc6021-bis-00.txt >> >> Proposal >> >> This version adds new type definitions to the YANG modules. The >> first YANG module, ietf-yang-types adds the following new data >> types: yang-identifier, hex-string, uuid, and dotted-quad. The >> second YANG module, ietf-inet-types, adds the following new data >> types: ip-address-no-zone, ipv4-address-no-zone, and >> ipv6-address-no-zone. >> >> Regards, Benoit (OPS AD) From mbj@tail-f.com Mon Mar 25 03:18:52 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD4521F8EB3 for ; Mon, 25 Mar 2013 03:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.557 X-Spam-Level: X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3NCqwIroVkL for ; Mon, 25 Mar 2013 03:18:52 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0D221E8034 for ; Mon, 25 Mar 2013 03:18:52 -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 6024A1200A6E; Mon, 25 Mar 2013 11:18:50 +0100 (CET) Date: Mon, 25 Mar 2013 11:18:50 +0100 (CET) Message-Id: <20130325.111850.814366468990422367.mbj@tail-f.com> To: bclaise@cisco.com From: Martin Bjorklund In-Reply-To: <514C8C6F.60704@cisco.com> References: <514C8C6F.60704@cisco.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] AD review of draft-ietf-netmod-iana-if-type-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 10:18:52 -0000 Benoit Claise wrote: > Hi Martin, netmod participants, > > - IANAifType-MIB > - http://www.iana.org/assignments/smi-numbers/smi-numbers.xml > There is a new value 273, which should be added to the draft, at first > glance. > Note: this entry 273 is called "Reserved". This is a weird name, > because there is RFC6825 next to it. Agreed. But since this value is not in reflected in IANAifType-MIB, I assume that the value really is just reserved for future use. So I don't think there is anything for us to update right now, do you agree? /martin From lhotka@nic.cz Mon Mar 25 03:47:25 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97B421F8EB3 for ; Mon, 25 Mar 2013 03:47:24 -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=[BAYES_20=-0.74, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gqk39geFe37k for ; Mon, 25 Mar 2013 03:47:24 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1943821F8EAF for ; Mon, 25 Mar 2013 03:47:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id D55D15401C2 for ; Mon, 25 Mar 2013 11:47:17 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thgI2OkQdq2v for ; Mon, 25 Mar 2013 11:47:14 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id E26EE5401A3 for ; Mon, 25 Mar 2013 11:47:05 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20130324190724.GA20421@elstar.local> References: <514C93E9.8@cisco.com> <20130322210354.GA16103@elstar.local> <514CDAE7.401@cisco.com> <20130324092107.GA19518@elstar.local> <5162BD50-7673-4BBD-AAD7-A297ABE29906@nic.cz> <20130324190724.GA20421@elstar.local> User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Mon, 25 Mar 2013 11:47:05 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6021-bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 10:47:25 -0000 Juergen Schoenwaelder writes: > On Sun, Mar 24, 2013 at 05:18:29PM +0100, Ladislav Lhotka wrote: >> >> YANG change rules require strict backward compatibility. I am afraid it is counterproductive at this stage because our initial YANG modules generally get published before they have been thouroughly tested. It would be quite daring to think that our work is flawless, despite all the effort we put in it. What if we publish the routing module and then get feedback from protocol implementors or I2RS, indicating that something should be changed, and this something breaks compatibility? >> >> I believe errors should be corrected and significant improvements implemented, and the sooner the better. It will be much harder after a module becomes widely used. >> > > If something is seriously flawed, it can be deprecated or even made > historic and you start a second attempt. All this is possible. This all too heavy-weight, so we shall be forced to various kludges and workarounds instead, and the elegance and readability of the modules will suffer from this cruft. The *-no-zone types are an example. Lada > Changing the semantics of an existing published definition is > generally a no go. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Mar 25 05:14:33 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781DE21F8C69 for ; Mon, 25 Mar 2013 05:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.372 X-Spam-Level: X-Spam-Status: No, score=-0.372 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Wh4hdZZl5ur for ; Mon, 25 Mar 2013 05:14:32 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id AB89C21F8C67 for ; Mon, 25 Mar 2013 05:14:26 -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 9D31C1200A6E; Mon, 25 Mar 2013 13:14:25 +0100 (CET) Date: Mon, 25 Mar 2013 13:14:25 +0100 (CET) Message-Id: <20130325.131425.832973611833975103.mbj@tail-f.com> To: bclaise@cisco.com From: Martin Bjorklund In-Reply-To: <20130325.111850.814366468990422367.mbj@tail-f.com> References: <514C8C6F.60704@cisco.com> <20130325.111850.814366468990422367.mbj@tail-f.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] AD review of draft-ietf-netmod-iana-if-type-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 12:14:33 -0000 Martin Bjorklund wrote: > Benoit Claise wrote: > > Hi Martin, netmod participants, > > > > - IANAifType-MIB > > - http://www.iana.org/assignments/smi-numbers/smi-numbers.xml > > There is a new value 273, which should be added to the draft, at first > > glance. > > Note: this entry 273 is called "Reserved". This is a weird name, > > because there is RFC6825 next to it. > > Agreed. But since this value is not in reflected in IANAifType-MIB, I > assume that the value really is just reserved for future use. BTW, I found the answer to this reservation here: http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-7 Note For every transmission number registration, the corresponding ifType value should be registered or marked "Reserved." (there is a corresponding rule for the reverse mapping: http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-5) /martin From j.schoenwaelder@jacobs-university.de Mon Mar 25 07:31:17 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3105721F8FE8 for ; Mon, 25 Mar 2013 07:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.649 X-Spam-Level: X-Spam-Status: No, score=-100.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1Z8cTiTA9oq for ; Mon, 25 Mar 2013 07:31:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8FC21F8FD7 for ; Mon, 25 Mar 2013 07:31:16 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 518A320BE2; Mon, 25 Mar 2013 15:31:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TeFqXBx-oMCq; Mon, 25 Mar 2013 15:31:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 14A5D20BD7; Mon, 25 Mar 2013 15:31:13 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 57DC2252F9F0; Mon, 25 Mar 2013 15:31:19 +0100 (CET) Date: Mon, 25 Mar 2013 15:31:19 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20130325143119.GC22576@elstar.local> Mail-Followup-To: netmod@ietf.org References: <514C93E9.8@cisco.com> <20130322210354.GA16103@elstar.local> <514CDAE7.401@cisco.com> <20130324092107.GA19518@elstar.local> <5162BD50-7673-4BBD-AAD7-A297ABE29906@nic.cz> <20130324190724.GA20421@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6021-bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 14:31:17 -0000 On Mon, Mar 25, 2013 at 11:47:05AM +0100, Ladislav Lhotka wrote: > > If something is seriously flawed, it can be deprecated or even made > > historic and you start a second attempt. All this is possible. > > This all too heavy-weight, so we shall be forced to various kludges > and workarounds instead, and the elegance and readability of the > modules will suffer from this cruft. The *-no-zone types are an > example. This is how the IETF works. We care about interoperability and hence changing the semantics of published definitions is a no go. And once again, I strongly disagree with your notion that *-no-zone types are 'kludges'. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From internet-drafts@ietf.org Mon Mar 25 10:22:13 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4684621F93CB; Mon, 25 Mar 2013 10:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJJfBGOXQLmo; Mon, 25 Mar 2013 10:22:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA33D21F9020; Mon, 25 Mar 2013 10:22:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130325172212.27030.68141.idtracker@ietfa.amsl.com> Date: Mon, 25 Mar 2013 10:22:12 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6021-bis-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 17:22:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : Common YANG Data Types Author(s) : Juergen Schoenwaelder Filename : draft-ietf-netmod-rfc6021-bis-01.txt Pages : 37 Date : 2013-03-25 Abstract: This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6021-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-rfc6021-bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-rfc6021-bis-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From j.schoenwaelder@jacobs-university.de Mon Mar 25 10:27:47 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2256C21F8B27 for ; Mon, 25 Mar 2013 10:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTHxQ20ANDLC for ; Mon, 25 Mar 2013 10:27:46 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5D521F8B25 for ; Mon, 25 Mar 2013 10:27:46 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12AEB20BC1; Mon, 25 Mar 2013 18:27:44 +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 JRNVsIiDPOgX; Mon, 25 Mar 2013 18:27:44 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 60825206D7; Mon, 25 Mar 2013 18:27:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CF5E4252FF47; Mon, 25 Mar 2013 18:27:47 +0100 (CET) Date: Mon, 25 Mar 2013 18:27:47 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20130325172747.GA23391@elstar.local> Mail-Followup-To: Benoit Claise , NETMOD Working Group References: <514C93E9.8@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <514C93E9.8@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: NETMOD Working Group Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6021-bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 17:27:47 -0000 Hi, I have posted a new I-D that addresses your comments (I hope). I also fixed the quoting bug reported by Jernej Tuljak on the mailing list on 2013-02-24. The diff is already available here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6021-bis-01.txt /js On Fri, Mar 22, 2013 at 06:24:57PM +0100, Benoit Claise wrote: > Juergen, NETMOD participants, > > Two comments > > 1. > For the ip-address-no-zone, ipv4-address-no-zone, and > ipv6-address-no-zone, don't you need a reference to the zone > information in the description? > > description > "The ip-address-no-zone type represents an IP address without > zone information in an IP version neutral way. The format > of the textual representations implies the IP version."; > > Doesn't give me a pointer to what a zone information is. So I don't > know what ip-address-no-zone is. > Note: I faced the zone issue only a year ago. Before that, I had no > clue what it was. > > > 2. > The section "Appendix A. Changes from RFC 6021" is pretty light: > > This version adds new type definitions to the YANG modules. For > the further details, see the revision statement of the YANG modules. > > Take it or leave it. However, I can tell that its resolution will > please some IESG members, specifically because the rfcdiff tool > doesn't do a good job of comparing RFC6021 with > draft-ietf-netmod-rfc6021-bis-00.txt > > Proposal > > This version adds new type definitions to the YANG modules. The > first YANG module, ietf-yang-types adds the following new data > types: yang-identifier, hex-string, uuid, and dotted-quad. The > second YANG module, ietf-inet-types, adds the following new data > types: ip-address-no-zone, ipv4-address-no-zone, and > ipv6-address-no-zone. > > Regards, Benoit (OPS AD) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From alex@cisco.com Mon Mar 25 14:37:32 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20CF21F8555 for ; Mon, 25 Mar 2013 14:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsKb4Go6TZnA for ; Mon, 25 Mar 2013 14:37:31 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id EA7F621F854D for ; Mon, 25 Mar 2013 14:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8159; q=dns/txt; s=iport; t=1364247451; x=1365457051; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=F01WswxomYQ1Uo0MMDIutwhhuxpAFZtZ/4eUTlW9YHk=; b=V/UONKWpU52Sl4edQ6bQNFYX1IsT7NruD9SB9Zz3kMhpXnStqv/G+xlc DE0Mngd2bO8M3veT+eiVsQFfw0IQIkQ0I++K6bhFFNqHmkW7LoR0ePceo GXjTmX9Q4PYvlMj/d+D7JNQVNfE1ZIzEmWBHOI59qMlFWBiy8SI73/lu/ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACPCUFGtJV2d/2dsb2JhbABDw3SBChZ0gh8BAQEEAQEBJBM0CwwEAgEIEQQBAQEKFAkHJwsUCQgBAQQOBQiIDAzDIo1OgRkmCwcGgllhA5gGiF2HCIMKgWwHFwYY X-IronPort-AV: E=Sophos;i="4.84,907,1355097600"; d="scan'208";a="191346137" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 25 Mar 2013 21:37:30 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2PLbUOd005991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Mar 2013 21:37:30 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.147]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Mon, 25 Mar 2013 16:37:30 -0500 From: "Alexander Clemm (alex)" To: Andy Bierman Thread-Topic: [netmod] Mounting YANG-Defined Information from Remote Datastores Thread-Index: Ac4nDbVuUnWlik2KRgGCoCl67WLA8QAMz5AAAAagufAADmxIgACBCd9g Date: Mon, 25 Mar 2013 21:37:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.200.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jan Medved \(jmedved\)" , "netmod@ietf.org" Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 21:37:33 -0000 Hi Andy, Correct, if information in the server (S1 in this case) is updated, the cha= nge will show up in the places that mount that information (S2 and S3, in t= his case), just like changes made by a provisioning system to a server will= show up in other applications when they obtain a view of the configuration= information on a server. =20 Our proposal does not make transactionality issues disappear, just like a p= rovisioning system cannot guarantee transactionality to its clients if the = underlying server(s) do not provide corresponding support as well. These d= ependencies and what our proposal does and does not do are something we wil= l make clearer in the next revision. At the same time, with the mount prop= osal, it is always clear who the authorative copy/owner of data is where th= e data is maintained, validated, etc. There is an authorative copy, and aut= horative owner; this is not about "peers" sharing "equal copies" that need = to be kept in synch etc. Instead, any mount client is "just a client", sim= ilar to e.g. a service provisioning app. Another way to look at a mount cl= ient is as a "proxy", retrieving and accessing information on another clien= t's behalf. The fact that the client "mounts" information from the server = does not change anything for the server; it does not affect its model, nor = how the server maintains its datastore. The mount proposal does make it e= asier for such a client application to render information that it accesses = from another system in a way that does not require to maintain and implemen= t a separate set of data models that would in effect duplicate the same inf= ormation. =20 Regards --- Alex -----Original Message----- From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Friday, March 22, 2013 7:08 PM To: Alexander Clemm (alex) Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datasto= res Hi, Let me try a simple example: There are 3 servers (S1, S2, S3): +------------------+ | S1 | --> /public +-----------------+ +------------------+ | S2 | --> mount(S1:/public) +-----------------+ +------------------+ | S3 | --> mount(S1:/public) +-----------------+ S1 is the server that is sharing the subtree /public. S2 and S3 both 'clients', and mount S1:/public in their configs. Any changes to /public done on any server magically appear on the other 2 s= ervers. Correct or not? IMO, NFS is a fairly heavy-weight protocol and making NETCONF as complex as= NFS is not a feature. Andy On Fri, Mar 22, 2013 at 5:41 PM, Alexander Clemm (alex) wr= ote: > Hello Andy, > > What we have in mind is a little less complicated than what you are conce= rned with. > > Think of a mount client as a client app, like other client apps. This ca= n be transparent to the owner/server of the datastore with the data items t= hat are mounted. The owner/server of the datastore with mounted data items= really isn't affected at all, nor are other client applications that inter= act with the same server; the mount client constitutes just another client = application. The "ownership" of the data - the master copy, if you will - = is not in question, and not changed by our proposal. Validation still occu= rs in the original datastore. The mount client merely "renders" the inform= ation that is retrieved, and operated on, in a way that makes it appear as = if it were part of its own datastore. However, the mount client now does h= ave the capability to validate "its" configurations in its own datastore (t= he ones that it actually owns, not ones that are mounted) against other con= figurations in the network. This is a problem today, where you need to rel= y on external applications to ensure network-wide consistency. > > Many uses for this only require providing visibility and the ability to r= etrieve information. Only some of the use cases involve the need to actual= ly modify information from remote. Where that is the case, the mount clien= t acts analogous to a provisioning application as far as the server is conc= erned. Obviously, transactionality is an issue for a mount client, just li= ke it is an issue to a provisioning application. Where a client app is not= able to obtain a needed lock, for instance, it cannot provide a lock to it= s own applications, which is really no different from the situation that a = provisioning application that provisions a service across a network would f= ace. > > Regards > --- Alex > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Friday, March 22, 2013 9:05 AM > To: Alexander Clemm (alex) > Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) > Subject: Re: [netmod] Mounting YANG-Defined Information from Remote=20 > Datastores > > Hi, > > I'm not sure I understand the use-cases here. > This is certainly a different approach to network-wide config. > This would seem to require that all the NETCONF servers sharing the same = config subtree need to be highly coordinated, since operations on each serv= er affect all the others. > > For example, if a client takes out a partial-lock on a shared node from s= erver-1, it has to check all the other servers and the lock is shared acros= s all servers. Access control would also be shared I guess. > > Do the contexts of shared nodes in candidate configs magically change or = do they stay out-of-date if modified in another server? > Does the entire running config in every server have to validate before an= y 1 server can commit a change to a shared node? > > The complexities this adds to the NETCONF transaction model and=20 > confirmed commit procedure are dramatic. The possibilities for=20 > must/when expressions to evaluate differently in each server just adds=20 > to the fun ;-) > > In previous discussions on network-wide configuration it was assumed a YA= NG model representing the network wide feature would be provided by a singl= e server, and it is an implementation detail how that server interacts with= other network devices. > > I do not see the advantages of treating the config like an NFS file syste= m. > > > > Andy > > > On Fri, Mar 22, 2013 at 8:00 AM, Alexander Clemm (alex) = wrote: >> Hi, >> >> >> >> We just posted last night a new Internet Draft "Mounting YANG-Defined=20 >> Information from Remote Datastores", see=20 >> http://tools.ietf.org/html/draft-clemm-netmod-mount-00. >> >> >> >> The draft addresses the problem of how to reference information from=20 >> remote datastores, without needing to actually replicate that=20 >> information (in its own model and datastore). This helps address=20 >> multiple problems, for example the issue of maintaining an=20 >> authorative set of global configuration settings that are shared and=20 >> exposed by multiple devices, and the issue of allowing one device to=20 >> expose information about the network and other devices without need for = replication, but in a federated way. >> >> >> >> The abstract reads as follows: >> >> This document introduces a new capability that allows YANG=20 >> datastores >> >> to reference and incorporate information from remote datastores. >> >> This is accomplished using a new YANG data model that allows to >> >> define and manage datastore mount points that reference data nodes=20 >> in >> >> remote datastores. The data model includes a set of YANG=20 >> extensions >> >> for the purposes of declaring such mount points. >> >> >> >> We are looking forward to discussing this with the working group and=20 >> welcome your feedback. >> >> >> >> Regards >> >> --- Alex >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> From bclaise@cisco.com Mon Mar 25 15:29:52 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32C921F8941 for ; Mon, 25 Mar 2013 15:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArElYJuHkMbz for ; Mon, 25 Mar 2013 15:29:51 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 45A4D21F8945 for ; Mon, 25 Mar 2013 15:29:51 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2PMTo7s013868; Mon, 25 Mar 2013 23:29:50 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2PMTAxl024714; Mon, 25 Mar 2013 23:29:20 +0100 (CET) Message-ID: <5150CF8E.8090006@cisco.com> Date: Mon, 25 Mar 2013 23:28:30 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: NETMOD Working Group , Martin Bjorklund Content-Type: multipart/alternative; boundary="------------090003050403070007010607" Subject: [netmod] AD review of draft-ietf-netmod-interfaces-cfg-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 22:29:52 -0000 This is a multi-part message in MIME format. --------------090003050403070007010607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Disclaimer: - If any of those points have been discussed on the mailing list, don't hesitate to let me know. - I probably should have mentioned some of these documents during the last call. Sorry. After a year in the new position, I'm still playing catch up mode. _CLARIFYING QUE__STION__S_ - Section 3.1 The interface List The data model for interfaces presented in this document uses a flat list of interfaces. Each interface in the list is identified by its name. Furthermore, each interface has a mandatory "type" leaf, and a "location" leaf. The combination of "type" and "location" is unique within the interface list. First time I read this, I thought the location was mandatory. However, it's not: +--rw interfaces +--rw interface [name] +--rw name string +--rw description? string +--rw type ianaift:iana-if-type +--rw location? string Proposal: OLD: Furthermore, each interface has a mandatory "type" leaf, and a "location" leaf. NEW: Furthermore, each interface has a mandatory "type" leaf, and an optional "location" leaf. When I understood that the location is optional, I have some difficulties to understand the following sentence "The combination of "type" and "location" is unique within the interface list." when the location is an optional field. - How does the mechanism above apply to subinterfaces? example: Interface Ethernet 0.1? I believe it deserves some explanation. Now, it's true that the RFC 2863 doesn't mention the notion of subinterface, and I believe that the notion of sub-layer (in RFC 2863) and interface layering (in draft-ietf-netmod-interfaces-cfg) notions don't apply to subinterfaces? I would be happy to stand corrected. For example, how should I understand the following sentence, if we speak about an subinterface The "location" leaf is a string. It is optional in the data model, but if the type represents a physical interface, it is mandatory. Does the subinterface really _represent _a physical interface? - The "if-index" leaf contains the value of the corresponding ifEntry's ifIndex. Shouldn't we stress this sentence with a MUST? Let's face it, we still have many MIB modules for monitoring. We can use NETCONF/YANG for interface management, but we need the link to the ifIndex, to access the corresponding entries in the existing MIB modules - One of the real pain point of RFC 2863 is the ifIndex non persistence. "Its value ranges between 1 and the value of ifNumber. The value for each interface must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization." Can we assume that the leaf name will remain constant after a "re-initialization of the entity's network management system", and that only the leaf if-index could change. Or we can't assume anything, and the NMS must rediscover everything. So same pain point as SNMP? Or should the NMS compare the config (which contains the ifName/leaf-name), and if they're unchanged after a reboot, the NMS just have query leaf if-index for the mapping to the MIB module? Could/should we say a few words about this in the draft? _EDITORIAL:_ - Section 2 o It is recognized that existing implementations will have to map the interface data model defined in this memo to their proprietary native data model. The new data model should be simple to facilitate such mappings. What does new refer to? The YANG module in this document, or the extensions, referred by the text seen in the introduction It is expected that interface type specific data models augment the generic interfaces data model defined in this document. I guess the YANG module in this document. So removing "new" would solve the confusion. - You might to stress in the section 4 that the non HC counters are not modeled. | in-octets | ifHCInOctets | | in-unicast-pkts | ifHCInUcastPkts | | in-broadcast-pkts | ifHCInBroadcastPkts | | in-multicast-pkts | ifHCInMulticastPkts | Btw, could this be a problem for sensors? - leaf last-change { type yang:date-and-time; config false; description "The time the interface entered its current operational state. If the current state was entered prior to the last re-initialization of the local network management subsystem, then this node is not present."; reference "RFC 2863 : The Interfaces Group MIB - ifLastChange"; } From the date-and-time definition in RFC 6021, do I understand correctly that the date-and-time are absolute time (and not the equivalent of the sysUpTime, as mentioned in ifLastChange). What if the device doesn't have any absolute time, but simply the sysUpTime? Same question for leaf discontinuity-time - I discovered the following feature in the YANG module feature arbitrary-names { description "This feature indicates that the server allows interfaces to be named arbitrarily."; } The only information I can find is If the device allows arbitrarily named interfaces, the feature 'arbitrary-names' is advertised. This leaf MAY be mapped to ifName by an implementation. Such an implementation MAY restrict the allowed values for this leaf so that it matches the restrictions of ifName. As an implementor, I don't have much idea what is meant by this 'arbitrary-names' feature. Some explanatory text outside of the YANG module would be welcome. Note: it's only when I read the appendix E that I finally got the information I was after. Not sure why this is in the appendix... Up to you. At least, I would make it clear in which of the E.X examples, the "feature arbitrary-names" is advertised. I guess, from the title, E2 and E5 Regards, Benoit --------------090003050403070007010607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Disclaimer:
- If any of those points have been discussed on the mailing list, don't hesitate to let me know.
- I probably should have mentioned some of these documents during the last call. Sorry. After a year in the new position, I'm still playing catch up mode.

CLARIFYING QUESTIONS
- Section 3.1 The interface List

   The data model for interfaces presented in this document uses a flat
   list of interfaces.  Each interface in the list is identified by its
   name.  Furthermore, each interface has a mandatory "type" leaf, and a
   "location" leaf.  The combination of "type" and "location" is unique
   within the interface list.

First time I read this, I thought the location was mandatory.
However, it's not: 

      +--rw interfaces
         +--rw interface [name]
            +--rw name                        string
            +--rw description?                string
            +--rw type                        ianaift:iana-if-type
            +--rw location?                   string

Proposal:
OLD:
	
   Furthermore, each interface has a mandatory "type" leaf, and a
   "location" leaf. 

NEW:
   Furthermore, each interface has a mandatory "type" leaf, and an optional
   "location" leaf.
When I understood that the location is optional, I have some difficulties to understand the following sentence
"The combination of "type" and "location" is unique within the interface list." when the location is an optional field.
 
- How does the mechanism above apply to subinterfaces? example: Interface Ethernet 0.1?
I believe it deserves some explanation. Now, it's true that the RFC 2863 doesn't mention the notion of subinterface, and I believe that the notion of sub-layer (in RFC 2863) and interface layering (in draft-ietf-netmod-interfaces-cfg) notions don't apply to subinterfaces? I would be happy to stand corrected.
For example, how should I understand the following sentence, if we speak about an subinterface
   The "location" leaf is a string.  It is optional in the data model,
   but if the type represents a physical interface, it is mandatory.
Does the subinterface really represent a physical interface?

- 
The "if-index" leaf contains the value of the corresponding ifEntry's ifIndex.
Shouldn't we stress this sentence with a MUST?
Let's face it, we still have many MIB modules for monitoring. We can use NETCONF/YANG for interface management, but we need the link to the ifIndex, to access the corresponding entries in the existing MIB modules

- One of the real pain point of RFC 2863 is the ifIndex non persistence.
      "Its value ranges between 1 and the value of ifNumber.  The
      value for each interface must remain constant at least from
      one re-initialization of the entity's network management
      system to the next re-initialization."

Can we assume that the leaf name will remain constant after a "re-initialization of the entity's network management system", and that only the leaf if-index could change.
Or we can't assume anything, and the NMS must rediscover everything. So same pain point as SNMP?
Or should the NMS compare the config (which contains the ifName/leaf-name), and if they're unchanged after a reboot, the NMS just have query leaf if-index for the mapping to the MIB module?
Could/should we say a few words about this in the draft?

EDITORIAL:

- Section 2
   o  It is recognized that existing implementations will have to map
      the interface data model defined in this memo to their proprietary
      native data model.  The new data model should be simple to
      facilitate such mappings.
What does new refer to? The YANG module in this document, or the extensions, referred by the text seen in the introduction
   It is expected that interface type specific
   data models augment the generic interfaces data model defined in this
   document.
I guess the YANG module in this document. So removing "new" would solve the confusion.

- You might to stress in the section 4 that the non HC counters are not modeled.
       | in-octets                        | ifHCInOctets           |
       | in-unicast-pkts                  | ifHCInUcastPkts        |
       | in-broadcast-pkts                | ifHCInBroadcastPkts    |
       | in-multicast-pkts                | ifHCInMulticastPkts    |
Btw, could this be a problem for sensors?

-
       leaf last-change {
           type yang:date-and-time;
           config false;
           description
             "The time the interface entered its current operational
              state.  If the current state was entered prior to the
              last re-initialization of the local network management
              subsystem, then this node is not present.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifLastChange";
         }
From the date-and-time definition in RFC 6021, do I understand correctly that the date-and-time are absolute time (and not the equivalent of the sysUpTime, as mentioned in ifLastChange).
What if the device doesn't have any absolute time, but simply the sysUpTime?
Same question for leaf discontinuity-time

-  I discovered the following feature in the YANG module
     feature arbitrary-names {
       description
         "This feature indicates that the server allows interfaces to
          be named arbitrarily.";
     }
The only information I can find is 
     If the device allows arbitrarily named interfaces, the
     feature 'arbitrary-names' is advertised.
  
     This leaf MAY be mapped to ifName by an implementation.
     Such an implementation MAY restrict the allowed values for
     this leaf so that it matches the restrictions of ifName.
As an implementor, I don't have much idea what is meant by this 'arbitrary-names' feature. Some explanatory text outside of the YANG module would be welcome.
Note: it's only when I read the appendix E that I finally got the information I was after. Not sure why this is in the appendix... Up to you.
At least, I would make it clear in which of the E.X examples, the "feature arbitrary-names" is advertised. I guess, from the title, E2 and E5

Regards, Benoit
--------------090003050403070007010607-- From andy@yumaworks.com Mon Mar 25 15:34:26 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AA721F897F for ; Mon, 25 Mar 2013 15:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuRjw4G6mPqA for ; Mon, 25 Mar 2013 15:34:25 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B9BD821F896E for ; Mon, 25 Mar 2013 15:34:24 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id aq17so5049873iec.19 for ; Mon, 25 Mar 2013 15:34:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=wynfkGQOSQ48iv5sLpS2Ow+eH34u8+vqZWOA39pLf8w=; b=EcSD1PECa4OxEwA869/vBduE7kEMcRL5k2XhLFDQixNLkcKjTY10VeBojcuGoJ+tqG DYea1+QwKfSNN4mn7zFFvMGpSmdldagbcPVLS/xmwLAn3ayV5HOTm6cfN9Go2XE/8xf9 VW5L0AdBYp+8qmOX1f5cyXVg2TKKmE7swU15gT+biSkUS9GFII0d1dF9XM9mR2RZYWkF 1gcqqon+CsQtHFWDm2P9gjcRzm3889zl1VV+ag65e4XbP6oDypfSjNkS/BSD8asWCqVs jq5IlTjELHOWAMY3UhuXKmU7mupuwdx2eGSkVepd2+/TijOGJvNAx8ZXd9oFn+7ETONa Decg== MIME-Version: 1.0 X-Received: by 10.42.64.135 with SMTP id g7mr7733129ici.37.1364250864238; Mon, 25 Mar 2013 15:34:24 -0700 (PDT) Received: by 10.231.34.68 with HTTP; Mon, 25 Mar 2013 15:34:23 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Mar 2013 15:34:23 -0700 Message-ID: From: Andy Bierman To: "Alexander Clemm (alex)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkImRL/aiFfFOH+57RI9z+/eGvU1I7puCVI/kYSnJ08Zj+8HzOnrXK2A9E/zwvrlZ6BRhIl Cc: "Jan Medved \(jmedved\)" , "netmod@ietf.org" Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 22:34:26 -0000 "Instead, any mount client is "just a client", similar to e.g. a service provisioning app." Whatever the NETCONF server advertises as configuration in its running config, a NETCONF client will think it is "just a server". This breaks existing NETCONF clients. Andy On Mon, Mar 25, 2013 at 2:37 PM, Alexander Clemm (alex) wr= ote: > Hi Andy, > > Correct, if information in the server (S1 in this case) is updated, the c= hange will show up in the places that mount that information (S2 and S3, in= this case), just like changes made by a provisioning system to a server wi= ll show up in other applications when they obtain a view of the configurati= on information on a server. > > Our proposal does not make transactionality issues disappear, just like a= provisioning system cannot guarantee transactionality to its clients if th= e underlying server(s) do not provide corresponding support as well. These= dependencies and what our proposal does and does not do are something we w= ill make clearer in the next revision. At the same time, with the mount pr= oposal, it is always clear who the authorative copy/owner of data is where = the data is maintained, validated, etc. There is an authorative copy, and a= uthorative owner; this is not about "peers" sharing "equal copies" that nee= d to be kept in synch etc. Instead, any mount client is "just a client", s= imilar to e.g. a service provisioning app. Another way to look at a mount = client is as a "proxy", retrieving and accessing information on another cli= ent's behalf. The fact that the client "mounts" information from the serve= r does not change anything for the server; it does not affect its model, no= r how the server maintains its datastore. The mount proposal does make it= easier for such a client application to render information that it accesse= s from another system in a way that does not require to maintain and implem= ent a separate set of data models that would in effect duplicate the same i= nformation. > > Regards > --- Alex > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Friday, March 22, 2013 7:08 PM > To: Alexander Clemm (alex) > Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) > Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datas= tores > > Hi, > > Let me try a simple example: > > There are 3 servers (S1, S2, S3): > > +------------------+ > | S1 | --> /public > +-----------------+ > > > +------------------+ > | S2 | --> mount(S1:/public) > +-----------------+ > > > +------------------+ > | S3 | --> mount(S1:/public) > +-----------------+ > > S1 is the server that is sharing the subtree /public. > S2 and S3 both 'clients', and mount S1:/public in their configs. > Any changes to /public done on any server magically appear on the other 2= servers. Correct or not? > > IMO, NFS is a fairly heavy-weight protocol and making NETCONF as complex = as NFS is not a feature. > > > > Andy > > > On Fri, Mar 22, 2013 at 5:41 PM, Alexander Clemm (alex) = wrote: >> Hello Andy, >> >> What we have in mind is a little less complicated than what you are conc= erned with. >> >> Think of a mount client as a client app, like other client apps. This c= an be transparent to the owner/server of the datastore with the data items = that are mounted. The owner/server of the datastore with mounted data item= s really isn't affected at all, nor are other client applications that inte= ract with the same server; the mount client constitutes just another client= application. The "ownership" of the data - the master copy, if you will -= is not in question, and not changed by our proposal. Validation still occ= urs in the original datastore. The mount client merely "renders" the infor= mation that is retrieved, and operated on, in a way that makes it appear as= if it were part of its own datastore. However, the mount client now does = have the capability to validate "its" configurations in its own datastore (= the ones that it actually owns, not ones that are mounted) against other co= nfigurations in the network. This is a problem today, where you need to re= ly on external applications to ensure network-wide consistency. >> >> Many uses for this only require providing visibility and the ability to = retrieve information. Only some of the use cases involve the need to actua= lly modify information from remote. Where that is the case, the mount clie= nt acts analogous to a provisioning application as far as the server is con= cerned. Obviously, transactionality is an issue for a mount client, just l= ike it is an issue to a provisioning application. Where a client app is no= t able to obtain a needed lock, for instance, it cannot provide a lock to i= ts own applications, which is really no different from the situation that a= provisioning application that provisions a service across a network would = face. >> >> Regards >> --- Alex >> >> -----Original Message----- >> From: Andy Bierman [mailto:andy@yumaworks.com] >> Sent: Friday, March 22, 2013 9:05 AM >> To: Alexander Clemm (alex) >> Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) >> Subject: Re: [netmod] Mounting YANG-Defined Information from Remote >> Datastores >> >> Hi, >> >> I'm not sure I understand the use-cases here. >> This is certainly a different approach to network-wide config. >> This would seem to require that all the NETCONF servers sharing the same= config subtree need to be highly coordinated, since operations on each ser= ver affect all the others. >> >> For example, if a client takes out a partial-lock on a shared node from = server-1, it has to check all the other servers and the lock is shared acro= ss all servers. Access control would also be shared I guess. >> >> Do the contexts of shared nodes in candidate configs magically change or= do they stay out-of-date if modified in another server? >> Does the entire running config in every server have to validate before a= ny 1 server can commit a change to a shared node? >> >> The complexities this adds to the NETCONF transaction model and >> confirmed commit procedure are dramatic. The possibilities for >> must/when expressions to evaluate differently in each server just adds >> to the fun ;-) >> >> In previous discussions on network-wide configuration it was assumed a Y= ANG model representing the network wide feature would be provided by a sing= le server, and it is an implementation detail how that server interacts wit= h other network devices. >> >> I do not see the advantages of treating the config like an NFS file syst= em. >> >> >> >> Andy >> >> >> On Fri, Mar 22, 2013 at 8:00 AM, Alexander Clemm (alex) = wrote: >>> Hi, >>> >>> >>> >>> We just posted last night a new Internet Draft "Mounting YANG-Defined >>> Information from Remote Datastores", see >>> http://tools.ietf.org/html/draft-clemm-netmod-mount-00. >>> >>> >>> >>> The draft addresses the problem of how to reference information from >>> remote datastores, without needing to actually replicate that >>> information (in its own model and datastore). This helps address >>> multiple problems, for example the issue of maintaining an >>> authorative set of global configuration settings that are shared and >>> exposed by multiple devices, and the issue of allowing one device to >>> expose information about the network and other devices without need for= replication, but in a federated way. >>> >>> >>> >>> The abstract reads as follows: >>> >>> This document introduces a new capability that allows YANG >>> datastores >>> >>> to reference and incorporate information from remote datastores. >>> >>> This is accomplished using a new YANG data model that allows to >>> >>> define and manage datastore mount points that reference data nodes >>> in >>> >>> remote datastores. The data model includes a set of YANG >>> extensions >>> >>> for the purposes of declaring such mount points. >>> >>> >>> >>> We are looking forward to discussing this with the working group and >>> welcome your feedback. >>> >>> >>> >>> Regards >>> >>> --- Alex >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> From alex@cisco.com Mon Mar 25 16:09:33 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A18C21F8821 for ; Mon, 25 Mar 2013 16:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ir+dOZ67N65a for ; Mon, 25 Mar 2013 16:09:32 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 16DA821F87B6 for ; Mon, 25 Mar 2013 16:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9760; q=dns/txt; s=iport; t=1364252972; x=1365462572; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=L+I9ksUEtq4d8jkDxkMNt+KN+fdm1VLkhM43PleN9GA=; b=jg/LNe0oX02Hs+n2I/IfeQhnwI+lkfkGL4fFXCkU6XLlaYQcIdqvlybA +Gx7u62NcLfZRl7sYjW1xpiVbcyeBxizejxyhHZP8ps0asjsqGvwnK6l7 H0t0Si2hE/JAoVw5lrnK9XgLV+KnD+27luGzLeXS22ppYwQFdPO57xJbz w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAjYUFGtJV2c/2dsb2JhbABDw3WBCxZ0gh8BAQEEAQEBJBM0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBA4FCIgMDMMIjU6BGSYLBwZdgXxhA5gGiF2HCIJ9DYFsBxcGGA X-IronPort-AV: E=Sophos;i="4.84,907,1355097600"; d="scan'208";a="191338766" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 25 Mar 2013 23:09:31 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2PN9V01013738 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Mar 2013 23:09:31 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.147]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Mon, 25 Mar 2013 18:09:30 -0500 From: "Alexander Clemm (alex)" To: Andy Bierman Thread-Topic: [netmod] Mounting YANG-Defined Information from Remote Datastores Thread-Index: Ac4nDbVuUnWlik2KRgGCoCl67WLA8QAMz5AAAAagufAADmxIgACBCd9gAA5f6IAACkisoA== Date: Mon, 25 Mar 2013 23:09:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.200.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jan Medved \(jmedved\)" , "netmod@ietf.org" Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 23:09:33 -0000 I am not clear how the presence of one Netconf client will break another Ne= tconf client. =20 I don't think there is anything that would prohibit a system that implement= s a Netconf client to act as a server to another application. =20 How to have such a system implement full transactional capabilities has cha= llenges, much like full transactionality is a challenge for a service provi= sioning application. Agree, we need to call these out, in particular in as= far it would mean not being able to support full transactional capabilitie= s (at the level of the mount client in as far as it acts as a server to ano= ther app - I think it is these higher apps that you are concerned about - t= he clients of the clients, so to speak). =20 --- Alex -----Original Message----- From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Monday, March 25, 2013 3:34 PM To: Alexander Clemm (alex) Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datasto= res "Instead, any mount client is "just a client", similar to e.g. a service pr= ovisioning app." Whatever the NETCONF server advertises as configuration in its running conf= ig, a NETCONF client will think it is "just a server". This breaks existing NETCONF clients. Andy On Mon, Mar 25, 2013 at 2:37 PM, Alexander Clemm (alex) wr= ote: > Hi Andy, > > Correct, if information in the server (S1 in this case) is updated, the c= hange will show up in the places that mount that information (S2 and S3, in= this case), just like changes made by a provisioning system to a server wi= ll show up in other applications when they obtain a view of the configurati= on information on a server. > > Our proposal does not make transactionality issues disappear, just like a= provisioning system cannot guarantee transactionality to its clients if th= e underlying server(s) do not provide corresponding support as well. These= dependencies and what our proposal does and does not do are something we w= ill make clearer in the next revision. At the same time, with the mount pr= oposal, it is always clear who the authorative copy/owner of data is where = the data is maintained, validated, etc. There is an authorative copy, and a= uthorative owner; this is not about "peers" sharing "equal copies" that nee= d to be kept in synch etc. Instead, any mount client is "just a client", s= imilar to e.g. a service provisioning app. Another way to look at a mount = client is as a "proxy", retrieving and accessing information on another cli= ent's behalf. The fact that the client "mounts" information from the serve= r does not change anything for the server; it does not affect its model, no= r how the server maintains its datastore. The mount proposal does make it= easier for such a client application to render information that it accesse= s from another system in a way that does not require to maintain and implem= ent a separate set of data models that would in effect duplicate the same i= nformation. > > Regards > --- Alex > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Friday, March 22, 2013 7:08 PM > To: Alexander Clemm (alex) > Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) > Subject: Re: [netmod] Mounting YANG-Defined Information from Remote=20 > Datastores > > Hi, > > Let me try a simple example: > > There are 3 servers (S1, S2, S3): > > +------------------+ > | S1 | --> /public > +-----------------+ > > > +------------------+ > | S2 | --> mount(S1:/public) > +-----------------+ > > > +------------------+ > | S3 | --> mount(S1:/public) > +-----------------+ > > S1 is the server that is sharing the subtree /public. > S2 and S3 both 'clients', and mount S1:/public in their configs. > Any changes to /public done on any server magically appear on the other 2= servers. Correct or not? > > IMO, NFS is a fairly heavy-weight protocol and making NETCONF as complex = as NFS is not a feature. > > > > Andy > > > On Fri, Mar 22, 2013 at 5:41 PM, Alexander Clemm (alex) = wrote: >> Hello Andy, >> >> What we have in mind is a little less complicated than what you are conc= erned with. >> >> Think of a mount client as a client app, like other client apps. This c= an be transparent to the owner/server of the datastore with the data items = that are mounted. The owner/server of the datastore with mounted data item= s really isn't affected at all, nor are other client applications that inte= ract with the same server; the mount client constitutes just another client= application. The "ownership" of the data - the master copy, if you will -= is not in question, and not changed by our proposal. Validation still occ= urs in the original datastore. The mount client merely "renders" the infor= mation that is retrieved, and operated on, in a way that makes it appear as= if it were part of its own datastore. However, the mount client now does = have the capability to validate "its" configurations in its own datastore (= the ones that it actually owns, not ones that are mounted) against other co= nfigurations in the network. This is a problem today, where you need to re= ly on external applications to ensure network-wide consistency. >> >> Many uses for this only require providing visibility and the ability to = retrieve information. Only some of the use cases involve the need to actua= lly modify information from remote. Where that is the case, the mount clie= nt acts analogous to a provisioning application as far as the server is con= cerned. Obviously, transactionality is an issue for a mount client, just l= ike it is an issue to a provisioning application. Where a client app is no= t able to obtain a needed lock, for instance, it cannot provide a lock to i= ts own applications, which is really no different from the situation that a= provisioning application that provisions a service across a network would = face. >> >> Regards >> --- Alex >> >> -----Original Message----- >> From: Andy Bierman [mailto:andy@yumaworks.com] >> Sent: Friday, March 22, 2013 9:05 AM >> To: Alexander Clemm (alex) >> Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) >> Subject: Re: [netmod] Mounting YANG-Defined Information from Remote=20 >> Datastores >> >> Hi, >> >> I'm not sure I understand the use-cases here. >> This is certainly a different approach to network-wide config. >> This would seem to require that all the NETCONF servers sharing the same= config subtree need to be highly coordinated, since operations on each ser= ver affect all the others. >> >> For example, if a client takes out a partial-lock on a shared node from = server-1, it has to check all the other servers and the lock is shared acro= ss all servers. Access control would also be shared I guess. >> >> Do the contexts of shared nodes in candidate configs magically change or= do they stay out-of-date if modified in another server? >> Does the entire running config in every server have to validate before a= ny 1 server can commit a change to a shared node? >> >> The complexities this adds to the NETCONF transaction model and=20 >> confirmed commit procedure are dramatic. The possibilities for=20 >> must/when expressions to evaluate differently in each server just=20 >> adds to the fun ;-) >> >> In previous discussions on network-wide configuration it was assumed a Y= ANG model representing the network wide feature would be provided by a sing= le server, and it is an implementation detail how that server interacts wit= h other network devices. >> >> I do not see the advantages of treating the config like an NFS file syst= em. >> >> >> >> Andy >> >> >> On Fri, Mar 22, 2013 at 8:00 AM, Alexander Clemm (alex) = wrote: >>> Hi, >>> >>> >>> >>> We just posted last night a new Internet Draft "Mounting=20 >>> YANG-Defined Information from Remote Datastores", see=20 >>> http://tools.ietf.org/html/draft-clemm-netmod-mount-00. >>> >>> >>> >>> The draft addresses the problem of how to reference information from=20 >>> remote datastores, without needing to actually replicate that=20 >>> information (in its own model and datastore). This helps address=20 >>> multiple problems, for example the issue of maintaining an=20 >>> authorative set of global configuration settings that are shared and=20 >>> exposed by multiple devices, and the issue of allowing one device to=20 >>> expose information about the network and other devices without need for= replication, but in a federated way. >>> >>> >>> >>> The abstract reads as follows: >>> >>> This document introduces a new capability that allows YANG=20 >>> datastores >>> >>> to reference and incorporate information from remote datastores. >>> >>> This is accomplished using a new YANG data model that allows to >>> >>> define and manage datastore mount points that reference data=20 >>> nodes in >>> >>> remote datastores. The data model includes a set of YANG=20 >>> extensions >>> >>> for the purposes of declaring such mount points. >>> >>> >>> >>> We are looking forward to discussing this with the working group and=20 >>> welcome your feedback. >>> >>> >>> >>> Regards >>> >>> --- Alex >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> From andy@yumaworks.com Mon Mar 25 16:27:00 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE69221F862A for ; Mon, 25 Mar 2013 16:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dww1dAKzDTEi for ; Mon, 25 Mar 2013 16:27:00 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D2DFE21F861F for ; Mon, 25 Mar 2013 16:26:59 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id 9so8213728iec.18 for ; Mon, 25 Mar 2013 16:26:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=D4CdAPJKOWe0Gqgff5IrqQO66ryAEhFnJ5syXvccHog=; b=fGDqDsB6unVBqci8QxL6Cv9bkZ5/8WpouhlneghwZsqn3AmJIzlrYE0WBARCNT53xb 1+4cZY1dM7+L/Gji62DQsADbEzsEhHqrnuvHJBxW/FZ3Z5AyEoRbZ9KKfjXTs1Z852PT /LJWO4N5Y/Pom8Z/g5fJaL9sPbaSLAEPVuGw9zOP3lB4BrcLg/X+qwBBh0eSPXVRx58R A31ntwvKrH5L7bwPFchh5cT+7YupyxYQ231X6Oi+1YIxtaZFSm2Oqpepv8NNcvhGw3Pf vVebaRpn2bKQmnJ600YSsmqe3otd/P33FouofrsEiW8kygHSstSsISucgvb4QafSrXnx biVg== MIME-Version: 1.0 X-Received: by 10.50.7.69 with SMTP id h5mr9585307iga.69.1364254019334; Mon, 25 Mar 2013 16:26:59 -0700 (PDT) Received: by 10.231.34.68 with HTTP; Mon, 25 Mar 2013 16:26:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Mar 2013 16:26:59 -0700 Message-ID: From: Andy Bierman To: "Alexander Clemm (alex)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmhhlT8PyluaAbDvlW8O3V1L0MAaNoN2fGTTLzzteYgG/NhKbdHdX788jD5o85FtDHxYsNM Cc: "Jan Medved \(jmedved\)" , "netmod@ietf.org" Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 23:27:00 -0000 Hi, I am still not clear what problem is being solved here. It sure looks like a really complicated form of NETCONF Proxy. Operators begged us at the IAB Workshop on NM not to let proxy servers anywhere near NETCONF. You talk about mounting read-only shared config so it can be rendered properly in an application. This sounds like a mid-level manager job. The NETCONF transaction model and definition of the running datastore is very clear, and already complicated enough. The protocol does not allow for "guest config" that is really shared. One could view it is just a huge implementation detail I guess, making it completely proprietary and outside the scope of the standard. It also seems to be quite a security hole. A vulnerability in server A can allow config in server B to be changed. A hole in the access control could allow a hacker to mount additional remote config sections from other routers, spreading the attack through the network. Andy On Mon, Mar 25, 2013 at 4:09 PM, Alexander Clemm (alex) wr= ote: > I am not clear how the presence of one Netconf client will break another = Netconf client. > I don't think there is anything that would prohibit a system that impleme= nts a Netconf client to act as a server to another application. > How to have such a system implement full transactional capabilities has c= hallenges, much like full transactionality is a challenge for a service pro= visioning application. Agree, we need to call these out, in particular in = as far it would mean not being able to support full transactional capabilit= ies (at the level of the mount client in as far as it acts as a server to a= nother app - I think it is these higher apps that you are concerned about -= the clients of the clients, so to speak). > --- Alex > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Monday, March 25, 2013 3:34 PM > To: Alexander Clemm (alex) > Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) > Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datas= tores > > "Instead, any mount client is "just a client", similar to e.g. a service = provisioning app." > > Whatever the NETCONF server advertises as configuration in its running co= nfig, a NETCONF client will think it is "just a server". > This breaks existing NETCONF clients. > > > > Andy > > > On Mon, Mar 25, 2013 at 2:37 PM, Alexander Clemm (alex) = wrote: >> Hi Andy, >> >> Correct, if information in the server (S1 in this case) is updated, the = change will show up in the places that mount that information (S2 and S3, i= n this case), just like changes made by a provisioning system to a server w= ill show up in other applications when they obtain a view of the configurat= ion information on a server. >> >> Our proposal does not make transactionality issues disappear, just like = a provisioning system cannot guarantee transactionality to its clients if t= he underlying server(s) do not provide corresponding support as well. Thes= e dependencies and what our proposal does and does not do are something we = will make clearer in the next revision. At the same time, with the mount p= roposal, it is always clear who the authorative copy/owner of data is where= the data is maintained, validated, etc. There is an authorative copy, and = authorative owner; this is not about "peers" sharing "equal copies" that ne= ed to be kept in synch etc. Instead, any mount client is "just a client", = similar to e.g. a service provisioning app. Another way to look at a mount= client is as a "proxy", retrieving and accessing information on another cl= ient's behalf. The fact that the client "mounts" information from the serv= er does not change anything for the server; it does not affect its model, n= or how the server maintains its datastore. The mount proposal does make i= t easier for such a client application to render information that it access= es from another system in a way that does not require to maintain and imple= ment a separate set of data models that would in effect duplicate the same = information. >> >> Regards >> --- Alex >> >> -----Original Message----- >> From: Andy Bierman [mailto:andy@yumaworks.com] >> Sent: Friday, March 22, 2013 7:08 PM >> To: Alexander Clemm (alex) >> Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) >> Subject: Re: [netmod] Mounting YANG-Defined Information from Remote >> Datastores >> >> Hi, >> >> Let me try a simple example: >> >> There are 3 servers (S1, S2, S3): >> >> +------------------+ >> | S1 | --> /public >> +-----------------+ >> >> >> +------------------+ >> | S2 | --> mount(S1:/public) >> +-----------------+ >> >> >> +------------------+ >> | S3 | --> mount(S1:/public) >> +-----------------+ >> >> S1 is the server that is sharing the subtree /public. >> S2 and S3 both 'clients', and mount S1:/public in their configs. >> Any changes to /public done on any server magically appear on the other = 2 servers. Correct or not? >> >> IMO, NFS is a fairly heavy-weight protocol and making NETCONF as complex= as NFS is not a feature. >> >> >> >> Andy >> >> >> On Fri, Mar 22, 2013 at 5:41 PM, Alexander Clemm (alex) = wrote: >>> Hello Andy, >>> >>> What we have in mind is a little less complicated than what you are con= cerned with. >>> >>> Think of a mount client as a client app, like other client apps. This = can be transparent to the owner/server of the datastore with the data items= that are mounted. The owner/server of the datastore with mounted data ite= ms really isn't affected at all, nor are other client applications that int= eract with the same server; the mount client constitutes just another clien= t application. The "ownership" of the data - the master copy, if you will = - is not in question, and not changed by our proposal. Validation still oc= curs in the original datastore. The mount client merely "renders" the info= rmation that is retrieved, and operated on, in a way that makes it appear a= s if it were part of its own datastore. However, the mount client now does= have the capability to validate "its" configurations in its own datastore = (the ones that it actually owns, not ones that are mounted) against other c= onfigurations in the network. This is a problem today, where you need to r= ely on external applications to ensure network-wide consistency. >>> >>> Many uses for this only require providing visibility and the ability to= retrieve information. Only some of the use cases involve the need to actu= ally modify information from remote. Where that is the case, the mount cli= ent acts analogous to a provisioning application as far as the server is co= ncerned. Obviously, transactionality is an issue for a mount client, just = like it is an issue to a provisioning application. Where a client app is n= ot able to obtain a needed lock, for instance, it cannot provide a lock to = its own applications, which is really no different from the situation that = a provisioning application that provisions a service across a network would= face. >>> >>> Regards >>> --- Alex >>> >>> -----Original Message----- >>> From: Andy Bierman [mailto:andy@yumaworks.com] >>> Sent: Friday, March 22, 2013 9:05 AM >>> To: Alexander Clemm (alex) >>> Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) >>> Subject: Re: [netmod] Mounting YANG-Defined Information from Remote >>> Datastores >>> >>> Hi, >>> >>> I'm not sure I understand the use-cases here. >>> This is certainly a different approach to network-wide config. >>> This would seem to require that all the NETCONF servers sharing the sam= e config subtree need to be highly coordinated, since operations on each se= rver affect all the others. >>> >>> For example, if a client takes out a partial-lock on a shared node from= server-1, it has to check all the other servers and the lock is shared acr= oss all servers. Access control would also be shared I guess. >>> >>> Do the contexts of shared nodes in candidate configs magically change o= r do they stay out-of-date if modified in another server? >>> Does the entire running config in every server have to validate before = any 1 server can commit a change to a shared node? >>> >>> The complexities this adds to the NETCONF transaction model and >>> confirmed commit procedure are dramatic. The possibilities for >>> must/when expressions to evaluate differently in each server just >>> adds to the fun ;-) >>> >>> In previous discussions on network-wide configuration it was assumed a = YANG model representing the network wide feature would be provided by a sin= gle server, and it is an implementation detail how that server interacts wi= th other network devices. >>> >>> I do not see the advantages of treating the config like an NFS file sys= tem. >>> >>> >>> >>> Andy >>> >>> >>> On Fri, Mar 22, 2013 at 8:00 AM, Alexander Clemm (alex) wrote: >>>> Hi, >>>> >>>> >>>> >>>> We just posted last night a new Internet Draft "Mounting >>>> YANG-Defined Information from Remote Datastores", see >>>> http://tools.ietf.org/html/draft-clemm-netmod-mount-00. >>>> >>>> >>>> >>>> The draft addresses the problem of how to reference information from >>>> remote datastores, without needing to actually replicate that >>>> information (in its own model and datastore). This helps address >>>> multiple problems, for example the issue of maintaining an >>>> authorative set of global configuration settings that are shared and >>>> exposed by multiple devices, and the issue of allowing one device to >>>> expose information about the network and other devices without need fo= r replication, but in a federated way. >>>> >>>> >>>> >>>> The abstract reads as follows: >>>> >>>> This document introduces a new capability that allows YANG >>>> datastores >>>> >>>> to reference and incorporate information from remote datastores. >>>> >>>> This is accomplished using a new YANG data model that allows to >>>> >>>> define and manage datastore mount points that reference data >>>> nodes in >>>> >>>> remote datastores. The data model includes a set of YANG >>>> extensions >>>> >>>> for the purposes of declaring such mount points. >>>> >>>> >>>> >>>> We are looking forward to discussing this with the working group and >>>> welcome your feedback. >>>> >>>> >>>> >>>> Regards >>>> >>>> --- Alex >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> From bclaise@cisco.com Mon Mar 25 16:38:42 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B1621F86BC for ; Mon, 25 Mar 2013 16:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eVX+nvCO2kp for ; Mon, 25 Mar 2013 16:38:40 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB7821F867E for ; Mon, 25 Mar 2013 16:38:40 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2PNcc0h019551 for ; Tue, 26 Mar 2013 00:38:38 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2PNc9ot020351 for ; Tue, 26 Mar 2013 00:38:19 +0100 (CET) Message-ID: <5150DFB8.1030709@cisco.com> Date: Tue, 26 Mar 2013 00:37:28 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: NETMOD Working Group References: <514C93E9.8@cisco.com> <20130324092228.GB19518@elstar.local> <51501692.4050909@cisco.com> In-Reply-To: <51501692.4050909@cisco.com> Content-Type: multipart/alternative; boundary="------------020107000703070205040209" Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6021-bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 23:38:42 -0000 This is a multi-part message in MIME format. --------------020107000703070205040209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 25/03/2013 10:19, Benoit Claise wrote: > Hi Juergen, > > Please publish a new version, and the WG agrees on the solution. Typo: Please publish a new version _once _the WG agrees on the solution. I should really start re-reading my emails before sending. That will be my resolution next year ;-) Regards, Benoit > > Regards, Benoit >> Benoit, >> >> do you prefer to get a revised module before you do the IETF last call >> or do you just want the editors to track those changes and we post a >> revision at some later point during the process? >> >> /js >> >> On Fri, Mar 22, 2013 at 06:24:57PM +0100, Benoit Claise wrote: >>> Juergen, NETMOD participants, >>> >>> Two comments >>> >>> 1. >>> For the ip-address-no-zone, ipv4-address-no-zone, and >>> ipv6-address-no-zone, don't you need a reference to the zone >>> information in the description? >>> >>> description >>> "The ip-address-no-zone type represents an IP address without >>> zone information in an IP version neutral way. The format >>> of the textual representations implies the IP version."; >>> >>> Doesn't give me a pointer to what a zone information is. So I don't >>> know what ip-address-no-zone is. >>> Note: I faced the zone issue only a year ago. Before that, I had no >>> clue what it was. >>> >>> >>> 2. >>> The section "Appendix A. Changes from RFC 6021" is pretty light: >>> >>> This version adds new type definitions to the YANG modules. For >>> the further details, see the revision statement of the YANG >>> modules. >>> >>> Take it or leave it. However, I can tell that its resolution will >>> please some IESG members, specifically because the rfcdiff tool >>> doesn't do a good job of comparing RFC6021 with >>> draft-ietf-netmod-rfc6021-bis-00.txt >>> >>> Proposal >>> >>> This version adds new type definitions to the YANG modules. The >>> first YANG module, ietf-yang-types adds the following new data >>> types: yang-identifier, hex-string, uuid, and dotted-quad. The >>> second YANG module, ietf-inet-types, adds the following new data >>> types: ip-address-no-zone, ipv4-address-no-zone, and >>> ipv6-address-no-zone. >>> >>> Regards, Benoit (OPS AD) > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --------------020107000703070205040209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 25/03/2013 10:19, Benoit Claise wrote:
Hi Juergen,

Please publish a new version, and the WG agrees on the solution.
Typo: Please publish a new version once the WG agrees on the solution.
I should really start re-reading my emails before sending. That will be my resolution next year ;-)

Regards, Benoit

Regards, Benoit
Benoit,

do you prefer to get a revised module before you do the IETF last call
or do you just want the editors to track those changes and we post a
revision at some later point during the process?

/js

On Fri, Mar 22, 2013 at 06:24:57PM +0100, Benoit Claise wrote:
Juergen, NETMOD participants,

Two comments

1.
For the ip-address-no-zone, ipv4-address-no-zone, and
ipv6-address-no-zone, don't you need a reference to the zone
information in the description?

      description
         "The ip-address-no-zone type represents an IP address without
          zone information in an IP version neutral way.  The format
          of the textual representations implies the IP version.";

Doesn't give me a pointer to what a zone information is. So I don't
know what ip-address-no-zone is.
Note: I faced the zone issue only a year ago. Before that, I had no
clue what it was.


2.
The section "Appendix A. Changes from RFC 6021" is pretty light:

      This version adds new type definitions to the YANG modules. For
    the further details, see the revision statement of the YANG modules.

Take it or leave it. However, I can tell that its resolution will
please some IESG members, specifically because the rfcdiff tool
doesn't do a good job of comparing RFC6021 with
draft-ietf-netmod-rfc6021-bis-00.txt

Proposal

      This version adds new type definitions to the YANG modules. The
    first YANG module, ietf-yang-types adds the following new data
    types: yang-identifier, hex-string, uuid, and dotted-quad. The
    second YANG module, ietf-inet-types, adds the following new data
    types: ip-address-no-zone, ipv4-address-no-zone, and
    ipv6-address-no-zone.

Regards, Benoit (OPS AD)

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



--------------020107000703070205040209-- From bclaise@cisco.com Mon Mar 25 16:39:54 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9387B21F86C5 for ; Mon, 25 Mar 2013 16:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoomYGdG2Acq for ; Mon, 25 Mar 2013 16:39:54 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id A04F721F86C2 for ; Mon, 25 Mar 2013 16:39:53 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2PNdKCZ019591 for ; Tue, 26 Mar 2013 00:39:20 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2PNd4nP020737 for ; Tue, 26 Mar 2013 00:39:15 +0100 (CET) Message-ID: <5150DFF0.6040205@cisco.com> Date: Tue, 26 Mar 2013 00:38:24 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: NETMOD Working Group References: <514C93E9.8@cisco.com> <20130325172747.GA23391@elstar.local> In-Reply-To: <20130325172747.GA23391@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6021-bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 23:39:54 -0000 Hi Juergen, > Hi, > > I have posted a new I-D that addresses your comments (I hope). Yes, thank you. Regards, Benoit > > I also fixed the quoting bug reported by Jernej Tuljak > on the mailing list on 2013-02-24. > > The diff is already available here: > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6021-bis-01.txt > > /js > > On Fri, Mar 22, 2013 at 06:24:57PM +0100, Benoit Claise wrote: >> Juergen, NETMOD participants, >> >> Two comments >> >> 1. >> For the ip-address-no-zone, ipv4-address-no-zone, and >> ipv6-address-no-zone, don't you need a reference to the zone >> information in the description? >> >> description >> "The ip-address-no-zone type represents an IP address without >> zone information in an IP version neutral way. The format >> of the textual representations implies the IP version."; >> >> Doesn't give me a pointer to what a zone information is. So I don't >> know what ip-address-no-zone is. >> Note: I faced the zone issue only a year ago. Before that, I had no >> clue what it was. >> >> >> 2. >> The section "Appendix A. Changes from RFC 6021" is pretty light: >> >> This version adds new type definitions to the YANG modules. For >> the further details, see the revision statement of the YANG modules. >> >> Take it or leave it. However, I can tell that its resolution will >> please some IESG members, specifically because the rfcdiff tool >> doesn't do a good job of comparing RFC6021 with >> draft-ietf-netmod-rfc6021-bis-00.txt >> >> Proposal >> >> This version adds new type definitions to the YANG modules. The >> first YANG module, ietf-yang-types adds the following new data >> types: yang-identifier, hex-string, uuid, and dotted-quad. The >> second YANG module, ietf-inet-types, adds the following new data >> types: ip-address-no-zone, ipv4-address-no-zone, and >> ipv6-address-no-zone. >> >> Regards, Benoit (OPS AD) From anton.tkacik@pantheon.sk Tue Mar 26 05:59:56 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0BA21F8B98 for ; Tue, 26 Mar 2013 05:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.206 X-Spam-Level: X-Spam-Status: No, score=0.206 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, J_CHICKENPOX_210=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f24jBqluvv7k for ; Tue, 26 Mar 2013 05:59:55 -0700 (PDT) Received: from amalka.pantheon.sk (amalka.pantheon.sk [81.89.59.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3744821F8B9B for ; Tue, 26 Mar 2013 05:59:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by amalka.pantheon.sk (Postfix) with ESMTP id A0E361FFA4; Tue, 26 Mar 2013 13:59:51 +0100 (CET) X-Virus-Scanned: amavisd-new at pantheon.sk Authentication-Results: amalka.pantheon.sk (amavisd-new); dkim=pass header.i=@pantheon.sk Received: from amalka.pantheon.sk ([127.0.0.1]) by localhost (amalka.pantheon.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uswzX9tFVcTD; Tue, 26 Mar 2013 13:59:49 +0100 (CET) Received: from cipisek.dmz.pantheon.local (cipisek.pantheon.sk [81.89.59.176]) by amalka.pantheon.sk (Postfix) with ESMTP; Tue, 26 Mar 2013 13:59:49 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id 33B148632D; Tue, 26 Mar 2013 13:59:49 +0100 (CET) X-Virus-Scanned: amavisd-new at pantheon.sk Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rC_sqSsJs60S; Tue, 26 Mar 2013 13:59:48 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id D97F0DA315; Tue, 26 Mar 2013 13:59:47 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.7.1 cipisek.dmz.pantheon.local D97F0DA315 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.sk; s=D7204E10-2735-11E2-9595-0BDFE9028503; t=1364302787; bh=Ek75YLFQVds1vgfGtMnwSldYfcNGQp+zvKrCo/UyQz4=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=A4QuxNDbMXDJpRpP7bjrohiHTjevt+bOtaG9nsZlqjQlhplr9sLDuDePXd2a2rar1 aFpYFiQo8Yx303yh0rVjwe70X84IWbPtCjPFLxoEj4Rv/yVIGZTXpEshgKuyglTjQt CSswXyk8bQiXWvAhMyBBhIVdJ5SL8Z6oGU7zZ+Ws= X-Virus-Scanned: amavisd-new at pantheon.sk Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BS38FCzFG8et; Tue, 26 Mar 2013 13:59:46 +0100 (CET) Received: from cipisek.dmz.pantheon.local (cipisek.dmz.pantheon.local [192.168.1.176]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id 4F41FDA353; Tue, 26 Mar 2013 13:59:46 +0100 (CET) Date: Tue, 26 Mar 2013 13:59:46 +0100 (CET) From: Anton =?utf-8?B?VGvDocSNaWs=?= To: Andy Bierman Message-ID: <1404210365.223284.1364302786043.JavaMail.root@pantheon.sk> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.1.176] X-Mailer: Zimbra 8.0.2_GA_5569 (ZimbraWebClient - FF19 (Win)/8.0.2_GA_5569) Thread-Topic: Mounting YANG-Defined Information from Remote Datastores Thread-Index: 5PkeP1g0/Xhk8puYqTCYLPfuJMs2BQ== Cc: "Jan Medved \(jmedved\)" , netmod@ietf.org Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 12:59:57 -0000 Hi, The interesting idea in this draft is to reuse of existing YANG schemas and nesting their data definitions in the other schemas (config/running tree). YANG in current state does not allow reusing of containers defined in another modules (it could be done by using anyxml statement but we loose machine-readable semantics of the nested data). For example if we want to model logical subsystems of network element by reusing ietf-interfaces currently we have only one option: rw if:interfaces rw ls:logical-systems +-- rw ls:logical-system [id] +-- rw ls:interfaces Where interfaces is leaflist of instance-identifier or leafref of interfaces. With the nesting of data, the model is more straighforward and also the interfaces for logical subsystem are separated in the tree. rw ls:logical-systems +-- rw ls:logical-system +-- rw if:interfaces So I would suggest explore the use cases for the nesting YANG schemas / modules in the tree, because mounting of remote datastores is only special use case of the YANG data nesting. Anton Tkacik ----- Original Message ----- > From: "Andy Bierman" > To: "Alexander Clemm (alex)" > Cc: "Jan Medved (jmedved)" , netmod@ietf.org > Sent: Tuesday, March 26, 2013 12:26:59 AM > Subject: [netmod] Mounting YANG-Defined Information from Remote Datastores > > Hi, > > I am still not clear what problem is being solved here. > It sure looks like a really complicated form of NETCONF Proxy. > Operators begged us at the IAB Workshop on NM > not to let proxy servers anywhere near NETCONF. > > You talk about mounting read-only shared config so > it can be rendered properly in an application. > This sounds like a mid-level manager job. > > The NETCONF transaction model and definition of the running > datastore is very clear, and already complicated enough. > The protocol does not allow for "guest config" that is really > shared. One could view it is just a huge implementation > detail I guess, making it completely proprietary and outside > the scope of the standard. > > It also seems to be quite a security hole. > A vulnerability in server A can allow config > in server B to be changed. A hole in the > access control could allow a hacker to mount > additional remote config sections from other routers, > spreading the attack through the network. > > > Andy > > > > > On Mon, Mar 25, 2013 at 4:09 PM, Alexander Clemm (alex) > wrote: > > I am not clear how the presence of one Netconf client will break another > > Netconf client. > > I don't think there is anything that would prohibit a system that > > implements a Netconf client to act as a server to another application. > > How to have such a system implement full transactional capabilities has > > challenges, much like full transactionality is a challenge for a service > > provisioning application. Agree, we need to call these out, in particular > > in as far it would mean not being able to support full transactional > > capabilities (at the level of the mount client in as far as it acts as a > > server to another app - I think it is these higher apps that you are > > concerned about - the clients of the clients, so to speak). > > --- Alex > > > > -----Original Message----- > > From: Andy Bierman [mailto:andy@yumaworks.com] > > Sent: Monday, March 25, 2013 3:34 PM > > To: Alexander Clemm (alex) > > Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) > > Subject: Re: [netmod] Mounting YANG-Defined Information from Remote > > Datastores > > > > "Instead, any mount client is "just a client", similar to e.g. a service > > provisioning app." > > > > Whatever the NETCONF server advertises as configuration in its running > > config, a NETCONF client will think it is "just a server". > > This breaks existing NETCONF clients. > > > > > > > > Andy > > > > > > On Mon, Mar 25, 2013 at 2:37 PM, Alexander Clemm (alex) > > wrote: > >> Hi Andy, > >> > >> Correct, if information in the server (S1 in this case) is updated, the > >> change will show up in the places that mount that information (S2 and S3, > >> in this case), just like changes made by a provisioning system to a > >> server will show up in other applications when they obtain a view of the > >> configuration information on a server. > >> > >> Our proposal does not make transactionality issues disappear, just like a > >> provisioning system cannot guarantee transactionality to its clients if > >> the underlying server(s) do not provide corresponding support as well. > >> These dependencies and what our proposal does and does not do are > >> something we will make clearer in the next revision. At the same time, > >> with the mount proposal, it is always clear who the authorative > >> copy/owner of data is where the data is maintained, validated, etc. There > >> is an authorative copy, and authorative owner; this is not about "peers" > >> sharing "equal copies" that need to be kept in synch etc. Instead, any > >> mount client is "just a client", similar to e.g. a service provisioning > >> app. Another way to look at a mount client is as a "proxy", retrieving > >> and accessing information on another client's behalf. The fact that the > >> client "mounts" information from the server does not change anything for > >> the server; it does not affect its model, nor how the serv > er maintains its datastore. The mount proposal does make it easier for > such a client application to render information that it accesses from > another system in a way that does not require to maintain and implement a > separate set of data models that would in effect duplicate the same > information. > >> > >> Regards > >> --- Alex > >> > >> -----Original Message----- > >> From: Andy Bierman [mailto:andy@yumaworks.com] > >> Sent: Friday, March 22, 2013 7:08 PM > >> To: Alexander Clemm (alex) > >> Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) > >> Subject: Re: [netmod] Mounting YANG-Defined Information from Remote > >> Datastores > >> > >> Hi, > >> > >> Let me try a simple example: > >> > >> There are 3 servers (S1, S2, S3): > >> > >> +------------------+ > >> | S1 | --> /public > >> +-----------------+ > >> > >> > >> +------------------+ > >> | S2 | --> mount(S1:/public) > >> +-----------------+ > >> > >> > >> +------------------+ > >> | S3 | --> mount(S1:/public) > >> +-----------------+ > >> > >> S1 is the server that is sharing the subtree /public. > >> S2 and S3 both 'clients', and mount S1:/public in their configs. > >> Any changes to /public done on any server magically appear on the other 2 > >> servers. Correct or not? > >> > >> IMO, NFS is a fairly heavy-weight protocol and making NETCONF as complex > >> as NFS is not a feature. > >> > >> > >> > >> Andy > >> > >> > >> On Fri, Mar 22, 2013 at 5:41 PM, Alexander Clemm (alex) > >> wrote: > >>> Hello Andy, > >>> > >>> What we have in mind is a little less complicated than what you are > >>> concerned with. > >>> > >>> Think of a mount client as a client app, like other client apps. This > >>> can be transparent to the owner/server of the datastore with the data > >>> items that are mounted. The owner/server of the datastore with mounted > >>> data items really isn't affected at all, nor are other client > >>> applications that interact with the same server; the mount client > >>> constitutes just another client application. The "ownership" of the > >>> data - the master copy, if you will - is not in question, and not > >>> changed by our proposal. Validation still occurs in the original > >>> datastore. The mount client merely "renders" the information that is > >>> retrieved, and operated on, in a way that makes it appear as if it were > >>> part of its own datastore. However, the mount client now does have the > >>> capability to validate "its" configurations in its own datastore (the > >>> ones that it actually owns, not ones that are mounted) against other > >>> configurations in the network. This is a problem today, where you need > >>> to rely on external > applications to ensure network-wide consistency. > >>> > >>> Many uses for this only require providing visibility and the ability to > >>> retrieve information. Only some of the use cases involve the need to > >>> actually modify information from remote. Where that is the case, the > >>> mount client acts analogous to a provisioning application as far as the > >>> server is concerned. Obviously, transactionality is an issue for a > >>> mount client, just like it is an issue to a provisioning application. > >>> Where a client app is not able to obtain a needed lock, for instance, > >>> it cannot provide a lock to its own applications, which is really no > >>> different from the situation that a provisioning application that > >>> provisions a service across a network would face. > >>> > >>> Regards > >>> --- Alex > >>> > >>> -----Original Message----- > >>> From: Andy Bierman [mailto:andy@yumaworks.com] > >>> Sent: Friday, March 22, 2013 9:05 AM > >>> To: Alexander Clemm (alex) > >>> Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) > >>> Subject: Re: [netmod] Mounting YANG-Defined Information from Remote > >>> Datastores > >>> > >>> Hi, > >>> > >>> I'm not sure I understand the use-cases here. > >>> This is certainly a different approach to network-wide config. > >>> This would seem to require that all the NETCONF servers sharing the same > >>> config subtree need to be highly coordinated, since operations on each > >>> server affect all the others. > >>> > >>> For example, if a client takes out a partial-lock on a shared node from > >>> server-1, it has to check all the other servers and the lock is shared > >>> across all servers. Access control would also be shared I guess. > >>> > >>> Do the contexts of shared nodes in candidate configs magically change or > >>> do they stay out-of-date if modified in another server? > >>> Does the entire running config in every server have to validate before > >>> any 1 server can commit a change to a shared node? > >>> > >>> The complexities this adds to the NETCONF transaction model and > >>> confirmed commit procedure are dramatic. The possibilities for > >>> must/when expressions to evaluate differently in each server just > >>> adds to the fun ;-) > >>> > >>> In previous discussions on network-wide configuration it was assumed a > >>> YANG model representing the network wide feature would be provided by a > >>> single server, and it is an implementation detail how that server > >>> interacts with other network devices. > >>> > >>> I do not see the advantages of treating the config like an NFS file > >>> system. > >>> > >>> > >>> > >>> Andy > >>> > >>> > >>> On Fri, Mar 22, 2013 at 8:00 AM, Alexander Clemm (alex) > >>> wrote: > >>>> Hi, > >>>> > >>>> > >>>> > >>>> We just posted last night a new Internet Draft "Mounting > >>>> YANG-Defined Information from Remote Datastores", see > >>>> http://tools.ietf.org/html/draft-clemm-netmod-mount-00. > >>>> > >>>> > >>>> > >>>> The draft addresses the problem of how to reference information from > >>>> remote datastores, without needing to actually replicate that > >>>> information (in its own model and datastore). This helps address > >>>> multiple problems, for example the issue of maintaining an > >>>> authorative set of global configuration settings that are shared and > >>>> exposed by multiple devices, and the issue of allowing one device to > >>>> expose information about the network and other devices without need for > >>>> replication, but in a federated way. > >>>> > >>>> > >>>> > >>>> The abstract reads as follows: > >>>> > >>>> This document introduces a new capability that allows YANG > >>>> datastores > >>>> > >>>> to reference and incorporate information from remote datastores. > >>>> > >>>> This is accomplished using a new YANG data model that allows to > >>>> > >>>> define and manage datastore mount points that reference data > >>>> nodes in > >>>> > >>>> remote datastores. The data model includes a set of YANG > >>>> extensions > >>>> > >>>> for the purposes of declaring such mount points. > >>>> > >>>> > >>>> > >>>> We are looking forward to discussing this with the working group and > >>>> welcome your feedback. > >>>> > >>>> > >>>> > >>>> Regards > >>>> > >>>> --- Alex > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 andy@yumaworks.com Tue Mar 26 07:06:11 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E5D21F8B35 for ; Tue, 26 Mar 2013 07:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.528 X-Spam-Level: X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_210=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFm5ti87jbwR for ; Tue, 26 Mar 2013 07:06:10 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id EAD8421F8B6E for ; Tue, 26 Mar 2013 07:06:09 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id c11so8948286ieb.15 for ; Tue, 26 Mar 2013 07:06:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=NITywsSw+PqXmwP7CKz201KUMwX9TIuiQdn8Rf8Q3+0=; b=RW/VpO0/NsXu1R1rM3mIW4MavPEOyJ2s39vWxVSo5Mv8LR83Ngg1AY6jSQE22DqALD S7D0zOGpMfJCpIqEkvGHuyZ4m2iQPbqpZNN54p1NNGO49AnxN668k4TccusA0UKfic84 GCsRHOQN3p+6d2R3szz21Fwen35AysawrYnXvwkCrN57PfZQKMiRCpY7nQyaRxMHlTuf AbewqM8LgcwXDKbq9aRPKxJ0RH7fZ6shJGlKfVIh8w3YrNZ8bJPvyaUtvhy1+j8LkaHY E9zENPQB88MiW+1GHGk05UgOTiHQUHoWWuEQVJcvs0z8fsRW5R0HVwO7vjNt4n5TGUBl PjGQ== MIME-Version: 1.0 X-Received: by 10.50.153.198 with SMTP id vi6mr1367600igb.112.1364306769224; Tue, 26 Mar 2013 07:06:09 -0700 (PDT) Received: by 10.231.34.68 with HTTP; Tue, 26 Mar 2013 07:06:08 -0700 (PDT) In-Reply-To: <1404210365.223284.1364302786043.JavaMail.root@pantheon.sk> References: <1404210365.223284.1364302786043.JavaMail.root@pantheon.sk> Date: Tue, 26 Mar 2013 07:06:08 -0700 Message-ID: From: Andy Bierman To: =?UTF-8?B?QW50b24gVGvDocSNaWs=?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlhHUyQr8zsTZb8G8W1bm/giSpCAY90r6ezjETtZbW6LxwhhVjvWJi60NWbQHQ6MOE947RH Cc: "Jan Medved \(jmedved\)" , netmod@ietf.org Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 14:06:11 -0000 What about the augment-stmt? Why don't you think that counts as reuse. On Tue, Mar 26, 2013 at 5:59 AM, Anton Tk=C3=A1=C4=8Dik wrote: > Hi, > The interesting idea in this draft is to reuse of existing YANG schemas > and nesting their data definitions in the other schemas (config/running t= ree). > > YANG in current state does not allow reusing of containers defined in ano= ther modules > (it could be done by using anyxml statement but we loose machine-readable > semantics of the nested data). > > For example if we want to model logical subsystems of network element by = reusing ietf-interfaces > currently we have only one option: > > rw if:interfaces > rw ls:logical-systems > +-- rw ls:logical-system [id] > +-- rw ls:interfaces > > Where interfaces is leaflist of instance-identifier or leafref of interfa= ces. > > With the nesting of data, the model is more straighforward and also the i= nterfaces > for logical subsystem are separated in the tree. > > rw ls:logical-systems > +-- rw ls:logical-system > +-- rw if:interfaces > > > So I would suggest explore the use cases for the nesting YANG schemas / m= odules > in the tree, because mounting of remote datastores is only special use ca= se > of the YANG data nesting. > > > Anton Tkacik > Andy > ----- Original Message ----- >> From: "Andy Bierman" >> To: "Alexander Clemm (alex)" >> Cc: "Jan Medved (jmedved)" , netmod@ietf.org >> Sent: Tuesday, March 26, 2013 12:26:59 AM >> Subject: [netmod] Mounting YANG-Defined Information from Remote Datastor= es >> >> Hi, >> >> I am still not clear what problem is being solved here. >> It sure looks like a really complicated form of NETCONF Proxy. >> Operators begged us at the IAB Workshop on NM >> not to let proxy servers anywhere near NETCONF. >> >> You talk about mounting read-only shared config so >> it can be rendered properly in an application. >> This sounds like a mid-level manager job. >> >> The NETCONF transaction model and definition of the running >> datastore is very clear, and already complicated enough. >> The protocol does not allow for "guest config" that is really >> shared. One could view it is just a huge implementation >> detail I guess, making it completely proprietary and outside >> the scope of the standard. >> >> It also seems to be quite a security hole. >> A vulnerability in server A can allow config >> in server B to be changed. A hole in the >> access control could allow a hacker to mount >> additional remote config sections from other routers, >> spreading the attack through the network. >> >> >> Andy >> >> >> >> >> On Mon, Mar 25, 2013 at 4:09 PM, Alexander Clemm (alex) >> wrote: >> > I am not clear how the presence of one Netconf client will break anoth= er >> > Netconf client. >> > I don't think there is anything that would prohibit a system that >> > implements a Netconf client to act as a server to another application. >> > How to have such a system implement full transactional capabilities ha= s >> > challenges, much like full transactionality is a challenge for a servi= ce >> > provisioning application. Agree, we need to call these out, in partic= ular >> > in as far it would mean not being able to support full transactional >> > capabilities (at the level of the mount client in as far as it acts as= a >> > server to another app - I think it is these higher apps that you are >> > concerned about - the clients of the clients, so to speak). >> > --- Alex >> > >> > -----Original Message----- >> > From: Andy Bierman [mailto:andy@yumaworks.com] >> > Sent: Monday, March 25, 2013 3:34 PM >> > To: Alexander Clemm (alex) >> > Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) >> > Subject: Re: [netmod] Mounting YANG-Defined Information from Remote >> > Datastores >> > >> > "Instead, any mount client is "just a client", similar to e.g. a servi= ce >> > provisioning app." >> > >> > Whatever the NETCONF server advertises as configuration in its running >> > config, a NETCONF client will think it is "just a server". >> > This breaks existing NETCONF clients. >> > >> > >> > >> > Andy >> > >> > >> > On Mon, Mar 25, 2013 at 2:37 PM, Alexander Clemm (alex) >> > wrote: >> >> Hi Andy, >> >> >> >> Correct, if information in the server (S1 in this case) is updated, t= he >> >> change will show up in the places that mount that information (S2 and= S3, >> >> in this case), just like changes made by a provisioning system to a >> >> server will show up in other applications when they obtain a view of = the >> >> configuration information on a server. >> >> >> >> Our proposal does not make transactionality issues disappear, just li= ke a >> >> provisioning system cannot guarantee transactionality to its clients = if >> >> the underlying server(s) do not provide corresponding support as well= . >> >> These dependencies and what our proposal does and does not do are >> >> something we will make clearer in the next revision. At the same tim= e, >> >> with the mount proposal, it is always clear who the authorative >> >> copy/owner of data is where the data is maintained, validated, etc. T= here >> >> is an authorative copy, and authorative owner; this is not about "pee= rs" >> >> sharing "equal copies" that need to be kept in synch etc. Instead, a= ny >> >> mount client is "just a client", similar to e.g. a service provisioni= ng >> >> app. Another way to look at a mount client is as a "proxy", retrievi= ng >> >> and accessing information on another client's behalf. The fact that = the >> >> client "mounts" information from the server does not change anything = for >> >> the server; it does not affect its model, nor how the serv >> er maintains its datastore. The mount proposal does make it easier fo= r >> such a client application to render information that it accesses from >> another system in a way that does not require to maintain and implement= a >> separate set of data models that would in effect duplicate the same >> information. >> >> >> >> Regards >> >> --- Alex >> >> >> >> -----Original Message----- >> >> From: Andy Bierman [mailto:andy@yumaworks.com] >> >> Sent: Friday, March 22, 2013 7:08 PM >> >> To: Alexander Clemm (alex) >> >> Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) >> >> Subject: Re: [netmod] Mounting YANG-Defined Information from Remote >> >> Datastores >> >> >> >> Hi, >> >> >> >> Let me try a simple example: >> >> >> >> There are 3 servers (S1, S2, S3): >> >> >> >> +------------------+ >> >> | S1 | --> /public >> >> +-----------------+ >> >> >> >> >> >> +------------------+ >> >> | S2 | --> mount(S1:/public) >> >> +-----------------+ >> >> >> >> >> >> +------------------+ >> >> | S3 | --> mount(S1:/public) >> >> +-----------------+ >> >> >> >> S1 is the server that is sharing the subtree /public. >> >> S2 and S3 both 'clients', and mount S1:/public in their configs. >> >> Any changes to /public done on any server magically appear on the oth= er 2 >> >> servers. Correct or not? >> >> >> >> IMO, NFS is a fairly heavy-weight protocol and making NETCONF as comp= lex >> >> as NFS is not a feature. >> >> >> >> >> >> >> >> Andy >> >> >> >> >> >> On Fri, Mar 22, 2013 at 5:41 PM, Alexander Clemm (alex) >> >> wrote: >> >>> Hello Andy, >> >>> >> >>> What we have in mind is a little less complicated than what you are >> >>> concerned with. >> >>> >> >>> Think of a mount client as a client app, like other client apps. Th= is >> >>> can be transparent to the owner/server of the datastore with the dat= a >> >>> items that are mounted. The owner/server of the datastore with moun= ted >> >>> data items really isn't affected at all, nor are other client >> >>> applications that interact with the same server; the mount client >> >>> constitutes just another client application. The "ownership" of the >> >>> data - the master copy, if you will - is not in question, and not >> >>> changed by our proposal. Validation still occurs in the original >> >>> datastore. The mount client merely "renders" the information that i= s >> >>> retrieved, and operated on, in a way that makes it appear as if it w= ere >> >>> part of its own datastore. However, the mount client now does have = the >> >>> capability to validate "its" configurations in its own datastore (th= e >> >>> ones that it actually owns, not ones that are mounted) against other >> >>> configurations in the network. This is a problem today, where you n= eed >> >>> to rely on external >> applications to ensure network-wide consistency. >> >>> >> >>> Many uses for this only require providing visibility and the ability= to >> >>> retrieve information. Only some of the use cases involve the need t= o >> >>> actually modify information from remote. Where that is the case, th= e >> >>> mount client acts analogous to a provisioning application as far as = the >> >>> server is concerned. Obviously, transactionality is an issue for a >> >>> mount client, just like it is an issue to a provisioning application= . >> >>> Where a client app is not able to obtain a needed lock, for instance= , >> >>> it cannot provide a lock to its own applications, which is really no >> >>> different from the situation that a provisioning application that >> >>> provisions a service across a network would face. >> >>> >> >>> Regards >> >>> --- Alex >> >>> >> >>> -----Original Message----- >> >>> From: Andy Bierman [mailto:andy@yumaworks.com] >> >>> Sent: Friday, March 22, 2013 9:05 AM >> >>> To: Alexander Clemm (alex) >> >>> Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) >> >>> Subject: Re: [netmod] Mounting YANG-Defined Information from Remote >> >>> Datastores >> >>> >> >>> Hi, >> >>> >> >>> I'm not sure I understand the use-cases here. >> >>> This is certainly a different approach to network-wide config. >> >>> This would seem to require that all the NETCONF servers sharing the = same >> >>> config subtree need to be highly coordinated, since operations on ea= ch >> >>> server affect all the others. >> >>> >> >>> For example, if a client takes out a partial-lock on a shared node f= rom >> >>> server-1, it has to check all the other servers and the lock is shar= ed >> >>> across all servers. Access control would also be shared I guess. >> >>> >> >>> Do the contexts of shared nodes in candidate configs magically chang= e or >> >>> do they stay out-of-date if modified in another server? >> >>> Does the entire running config in every server have to validate befo= re >> >>> any 1 server can commit a change to a shared node? >> >>> >> >>> The complexities this adds to the NETCONF transaction model and >> >>> confirmed commit procedure are dramatic. The possibilities for >> >>> must/when expressions to evaluate differently in each server just >> >>> adds to the fun ;-) >> >>> >> >>> In previous discussions on network-wide configuration it was assumed= a >> >>> YANG model representing the network wide feature would be provided b= y a >> >>> single server, and it is an implementation detail how that server >> >>> interacts with other network devices. >> >>> >> >>> I do not see the advantages of treating the config like an NFS file >> >>> system. >> >>> >> >>> >> >>> >> >>> Andy >> >>> >> >>> >> >>> On Fri, Mar 22, 2013 at 8:00 AM, Alexander Clemm (alex) >> >>> wrote: >> >>>> Hi, >> >>>> >> >>>> >> >>>> >> >>>> We just posted last night a new Internet Draft "Mounting >> >>>> YANG-Defined Information from Remote Datastores", see >> >>>> http://tools.ietf.org/html/draft-clemm-netmod-mount-00. >> >>>> >> >>>> >> >>>> >> >>>> The draft addresses the problem of how to reference information fro= m >> >>>> remote datastores, without needing to actually replicate that >> >>>> information (in its own model and datastore). This helps address >> >>>> multiple problems, for example the issue of maintaining an >> >>>> authorative set of global configuration settings that are shared an= d >> >>>> exposed by multiple devices, and the issue of allowing one device t= o >> >>>> expose information about the network and other devices without need= for >> >>>> replication, but in a federated way. >> >>>> >> >>>> >> >>>> >> >>>> The abstract reads as follows: >> >>>> >> >>>> This document introduces a new capability that allows YANG >> >>>> datastores >> >>>> >> >>>> to reference and incorporate information from remote datastores. >> >>>> >> >>>> This is accomplished using a new YANG data model that allows to >> >>>> >> >>>> define and manage datastore mount points that reference data >> >>>> nodes in >> >>>> >> >>>> remote datastores. The data model includes a set of YANG >> >>>> extensions >> >>>> >> >>>> for the purposes of declaring such mount points. >> >>>> >> >>>> >> >>>> >> >>>> We are looking forward to discussing this with the working group an= d >> >>>> welcome your feedback. >> >>>> >> >>>> >> >>>> >> >>>> Regards >> >>>> >> >>>> --- Alex >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> 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 andy@yumaworks.com Tue Mar 26 08:26:04 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C49821F8837 for ; Tue, 26 Mar 2013 08:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_210=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nrq7MOlPN4Zf for ; Tue, 26 Mar 2013 08:25:56 -0700 (PDT) Received: from mail-ia0-x231.google.com (mail-ia0-x231.google.com [IPv6:2607:f8b0:4001:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7DC21F883A for ; Tue, 26 Mar 2013 08:25:55 -0700 (PDT) Received: by mail-ia0-f177.google.com with SMTP id w33so3325101iag.8 for ; Tue, 26 Mar 2013 08:25:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=2I3YDDWqGyHR7+wvoq3JtCB3771wxsh0LxWkLQlnGaQ=; b=f07FuYllwpnrjE45d8OzTmtyV17ZkPgPdIlBVczhLfmSy8pcQpu3YwIIgsWLgLGKao 7dNjaqqFukLONLy6Dpq8Tp2Q0P953l2Kyji0AJx+J7cV+6bR6pJxMlNejyUMutZVDcHQ 5vqvnS2Tg/CpbQeBVd+wo+EBUAb/ACkcF/hUqKlcnOF3uQpktacbRHT372AEoxVAu8fY 2T12B/vfjyK65Pzj05aRjDBJRAB7tnM9L410iNaA9S0ZgIS17gh0p04CuV0fjuZgUlPx AZeOVOpLCi+InOcGkDbcNc/AVM0bd/Hg1OSjA1Gh6ZP3ntMNUSSAgmRLFIM9fkduwS// wcLw== MIME-Version: 1.0 X-Received: by 10.50.78.202 with SMTP id d10mr1631937igx.69.1364311553796; Tue, 26 Mar 2013 08:25:53 -0700 (PDT) Received: by 10.231.34.68 with HTTP; Tue, 26 Mar 2013 08:25:53 -0700 (PDT) In-Reply-To: <1404210365.223284.1364302786043.JavaMail.root@pantheon.sk> References: <1404210365.223284.1364302786043.JavaMail.root@pantheon.sk> Date: Tue, 26 Mar 2013 08:25:53 -0700 Message-ID: From: Andy Bierman To: =?UTF-8?B?QW50b24gVGvDocSNaWs=?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnSkVZh3bFZbQ+AcRAksY38S0u2NjW6Vui8vOpTE944mub8ugelfQ34Vq/BIbirfFrNFk3X Cc: "Jan Medved \(jmedved\)" , netmod@ietf.org Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 15:26:05 -0000 On Tue, Mar 26, 2013 at 5:59 AM, Anton Tk=C3=A1=C4=8Dik wrote: > Hi, > The interesting idea in this draft is to reuse of existing YANG schemas > and nesting their data definitions in the other schemas (config/running t= ree). > I did not realize you were trying to relocate data nodes or replicate them in different parts of the config, for objects that are not defined in group= ings. I don't agree that replicating the interface list under some other (vendor) config is a good idea. I think leafrefs are a better design than replicati= ng the data nodes. Relocating data from its YANG defined location to a different part of the tree is pointless for applications. They use whateve= r instance-identifier is plugged in and do not care where it is in the tree. Andy > YANG in current state does not allow reusing of containers defined in ano= ther modules > (it could be done by using anyxml statement but we loose machine-readable > semantics of the nested data). > > For example if we want to model logical subsystems of network element by = reusing ietf-interfaces > currently we have only one option: > > rw if:interfaces > rw ls:logical-systems > +-- rw ls:logical-system [id] > +-- rw ls:interfaces > > Where interfaces is leaflist of instance-identifier or leafref of interfa= ces. > > With the nesting of data, the model is more straighforward and also the i= nterfaces > for logical subsystem are separated in the tree. > > rw ls:logical-systems > +-- rw ls:logical-system > +-- rw if:interfaces > > > So I would suggest explore the use cases for the nesting YANG schemas / m= odules > in the tree, because mounting of remote datastores is only special use ca= se > of the YANG data nesting. > > > Anton Tkacik > > ----- Original Message ----- >> From: "Andy Bierman" >> To: "Alexander Clemm (alex)" >> Cc: "Jan Medved (jmedved)" , netmod@ietf.org >> Sent: Tuesday, March 26, 2013 12:26:59 AM >> Subject: [netmod] Mounting YANG-Defined Information from Remote Datastor= es >> >> Hi, >> >> I am still not clear what problem is being solved here. >> It sure looks like a really complicated form of NETCONF Proxy. >> Operators begged us at the IAB Workshop on NM >> not to let proxy servers anywhere near NETCONF. >> >> You talk about mounting read-only shared config so >> it can be rendered properly in an application. >> This sounds like a mid-level manager job. >> >> The NETCONF transaction model and definition of the running >> datastore is very clear, and already complicated enough. >> The protocol does not allow for "guest config" that is really >> shared. One could view it is just a huge implementation >> detail I guess, making it completely proprietary and outside >> the scope of the standard. >> >> It also seems to be quite a security hole. >> A vulnerability in server A can allow config >> in server B to be changed. A hole in the >> access control could allow a hacker to mount >> additional remote config sections from other routers, >> spreading the attack through the network. >> >> >> Andy >> >> >> >> >> On Mon, Mar 25, 2013 at 4:09 PM, Alexander Clemm (alex) >> wrote: >> > I am not clear how the presence of one Netconf client will break anoth= er >> > Netconf client. >> > I don't think there is anything that would prohibit a system that >> > implements a Netconf client to act as a server to another application. >> > How to have such a system implement full transactional capabilities ha= s >> > challenges, much like full transactionality is a challenge for a servi= ce >> > provisioning application. Agree, we need to call these out, in partic= ular >> > in as far it would mean not being able to support full transactional >> > capabilities (at the level of the mount client in as far as it acts as= a >> > server to another app - I think it is these higher apps that you are >> > concerned about - the clients of the clients, so to speak). >> > --- Alex >> > >> > -----Original Message----- >> > From: Andy Bierman [mailto:andy@yumaworks.com] >> > Sent: Monday, March 25, 2013 3:34 PM >> > To: Alexander Clemm (alex) >> > Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) >> > Subject: Re: [netmod] Mounting YANG-Defined Information from Remote >> > Datastores >> > >> > "Instead, any mount client is "just a client", similar to e.g. a servi= ce >> > provisioning app." >> > >> > Whatever the NETCONF server advertises as configuration in its running >> > config, a NETCONF client will think it is "just a server". >> > This breaks existing NETCONF clients. >> > >> > >> > >> > Andy >> > >> > >> > On Mon, Mar 25, 2013 at 2:37 PM, Alexander Clemm (alex) >> > wrote: >> >> Hi Andy, >> >> >> >> Correct, if information in the server (S1 in this case) is updated, t= he >> >> change will show up in the places that mount that information (S2 and= S3, >> >> in this case), just like changes made by a provisioning system to a >> >> server will show up in other applications when they obtain a view of = the >> >> configuration information on a server. >> >> >> >> Our proposal does not make transactionality issues disappear, just li= ke a >> >> provisioning system cannot guarantee transactionality to its clients = if >> >> the underlying server(s) do not provide corresponding support as well= . >> >> These dependencies and what our proposal does and does not do are >> >> something we will make clearer in the next revision. At the same tim= e, >> >> with the mount proposal, it is always clear who the authorative >> >> copy/owner of data is where the data is maintained, validated, etc. T= here >> >> is an authorative copy, and authorative owner; this is not about "pee= rs" >> >> sharing "equal copies" that need to be kept in synch etc. Instead, a= ny >> >> mount client is "just a client", similar to e.g. a service provisioni= ng >> >> app. Another way to look at a mount client is as a "proxy", retrievi= ng >> >> and accessing information on another client's behalf. The fact that = the >> >> client "mounts" information from the server does not change anything = for >> >> the server; it does not affect its model, nor how the serv >> er maintains its datastore. The mount proposal does make it easier fo= r >> such a client application to render information that it accesses from >> another system in a way that does not require to maintain and implement= a >> separate set of data models that would in effect duplicate the same >> information. >> >> >> >> Regards >> >> --- Alex >> >> >> >> -----Original Message----- >> >> From: Andy Bierman [mailto:andy@yumaworks.com] >> >> Sent: Friday, March 22, 2013 7:08 PM >> >> To: Alexander Clemm (alex) >> >> Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) >> >> Subject: Re: [netmod] Mounting YANG-Defined Information from Remote >> >> Datastores >> >> >> >> Hi, >> >> >> >> Let me try a simple example: >> >> >> >> There are 3 servers (S1, S2, S3): >> >> >> >> +------------------+ >> >> | S1 | --> /public >> >> +-----------------+ >> >> >> >> >> >> +------------------+ >> >> | S2 | --> mount(S1:/public) >> >> +-----------------+ >> >> >> >> >> >> +------------------+ >> >> | S3 | --> mount(S1:/public) >> >> +-----------------+ >> >> >> >> S1 is the server that is sharing the subtree /public. >> >> S2 and S3 both 'clients', and mount S1:/public in their configs. >> >> Any changes to /public done on any server magically appear on the oth= er 2 >> >> servers. Correct or not? >> >> >> >> IMO, NFS is a fairly heavy-weight protocol and making NETCONF as comp= lex >> >> as NFS is not a feature. >> >> >> >> >> >> >> >> Andy >> >> >> >> >> >> On Fri, Mar 22, 2013 at 5:41 PM, Alexander Clemm (alex) >> >> wrote: >> >>> Hello Andy, >> >>> >> >>> What we have in mind is a little less complicated than what you are >> >>> concerned with. >> >>> >> >>> Think of a mount client as a client app, like other client apps. Th= is >> >>> can be transparent to the owner/server of the datastore with the dat= a >> >>> items that are mounted. The owner/server of the datastore with moun= ted >> >>> data items really isn't affected at all, nor are other client >> >>> applications that interact with the same server; the mount client >> >>> constitutes just another client application. The "ownership" of the >> >>> data - the master copy, if you will - is not in question, and not >> >>> changed by our proposal. Validation still occurs in the original >> >>> datastore. The mount client merely "renders" the information that i= s >> >>> retrieved, and operated on, in a way that makes it appear as if it w= ere >> >>> part of its own datastore. However, the mount client now does have = the >> >>> capability to validate "its" configurations in its own datastore (th= e >> >>> ones that it actually owns, not ones that are mounted) against other >> >>> configurations in the network. This is a problem today, where you n= eed >> >>> to rely on external >> applications to ensure network-wide consistency. >> >>> >> >>> Many uses for this only require providing visibility and the ability= to >> >>> retrieve information. Only some of the use cases involve the need t= o >> >>> actually modify information from remote. Where that is the case, th= e >> >>> mount client acts analogous to a provisioning application as far as = the >> >>> server is concerned. Obviously, transactionality is an issue for a >> >>> mount client, just like it is an issue to a provisioning application= . >> >>> Where a client app is not able to obtain a needed lock, for instance= , >> >>> it cannot provide a lock to its own applications, which is really no >> >>> different from the situation that a provisioning application that >> >>> provisions a service across a network would face. >> >>> >> >>> Regards >> >>> --- Alex >> >>> >> >>> -----Original Message----- >> >>> From: Andy Bierman [mailto:andy@yumaworks.com] >> >>> Sent: Friday, March 22, 2013 9:05 AM >> >>> To: Alexander Clemm (alex) >> >>> Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) >> >>> Subject: Re: [netmod] Mounting YANG-Defined Information from Remote >> >>> Datastores >> >>> >> >>> Hi, >> >>> >> >>> I'm not sure I understand the use-cases here. >> >>> This is certainly a different approach to network-wide config. >> >>> This would seem to require that all the NETCONF servers sharing the = same >> >>> config subtree need to be highly coordinated, since operations on ea= ch >> >>> server affect all the others. >> >>> >> >>> For example, if a client takes out a partial-lock on a shared node f= rom >> >>> server-1, it has to check all the other servers and the lock is shar= ed >> >>> across all servers. Access control would also be shared I guess. >> >>> >> >>> Do the contexts of shared nodes in candidate configs magically chang= e or >> >>> do they stay out-of-date if modified in another server? >> >>> Does the entire running config in every server have to validate befo= re >> >>> any 1 server can commit a change to a shared node? >> >>> >> >>> The complexities this adds to the NETCONF transaction model and >> >>> confirmed commit procedure are dramatic. The possibilities for >> >>> must/when expressions to evaluate differently in each server just >> >>> adds to the fun ;-) >> >>> >> >>> In previous discussions on network-wide configuration it was assumed= a >> >>> YANG model representing the network wide feature would be provided b= y a >> >>> single server, and it is an implementation detail how that server >> >>> interacts with other network devices. >> >>> >> >>> I do not see the advantages of treating the config like an NFS file >> >>> system. >> >>> >> >>> >> >>> >> >>> Andy >> >>> >> >>> >> >>> On Fri, Mar 22, 2013 at 8:00 AM, Alexander Clemm (alex) >> >>> wrote: >> >>>> Hi, >> >>>> >> >>>> >> >>>> >> >>>> We just posted last night a new Internet Draft "Mounting >> >>>> YANG-Defined Information from Remote Datastores", see >> >>>> http://tools.ietf.org/html/draft-clemm-netmod-mount-00. >> >>>> >> >>>> >> >>>> >> >>>> The draft addresses the problem of how to reference information fro= m >> >>>> remote datastores, without needing to actually replicate that >> >>>> information (in its own model and datastore). This helps address >> >>>> multiple problems, for example the issue of maintaining an >> >>>> authorative set of global configuration settings that are shared an= d >> >>>> exposed by multiple devices, and the issue of allowing one device t= o >> >>>> expose information about the network and other devices without need= for >> >>>> replication, but in a federated way. >> >>>> >> >>>> >> >>>> >> >>>> The abstract reads as follows: >> >>>> >> >>>> This document introduces a new capability that allows YANG >> >>>> datastores >> >>>> >> >>>> to reference and incorporate information from remote datastores. >> >>>> >> >>>> This is accomplished using a new YANG data model that allows to >> >>>> >> >>>> define and manage datastore mount points that reference data >> >>>> nodes in >> >>>> >> >>>> remote datastores. The data model includes a set of YANG >> >>>> extensions >> >>>> >> >>>> for the purposes of declaring such mount points. >> >>>> >> >>>> >> >>>> >> >>>> We are looking forward to discussing this with the working group an= d >> >>>> welcome your feedback. >> >>>> >> >>>> >> >>>> >> >>>> Regards >> >>>> >> >>>> --- Alex >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> 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 lhotka@nic.cz Wed Mar 27 07:03:00 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C18B21F85F3 for ; Wed, 27 Mar 2013 07:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.166 X-Spam-Level: X-Spam-Status: No, score=-0.166 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVAuyW7lsDNi for ; Wed, 27 Mar 2013 07:02:59 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id BEF6521F85E0 for ; Wed, 27 Mar 2013 07:02:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 3493854014F; Wed, 27 Mar 2013 15:02:52 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWxzpRDhFOEK; Wed, 27 Mar 2013 15:02:44 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 7B0B15400CD; Wed, 27 Mar 2013 15:02:39 +0100 (CET) From: Ladislav Lhotka To: "Alexander Clemm \(alex\)" , "netmod\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: "Alexander Clemm \(alex\)" , "netmod\@ietf.org" , "Eric Voit \(evoit\)" , "Jan Medved \(jmedved\)" Date: Wed, 27 Mar 2013 15:02:38 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Jan Medved \(jmedved\)" Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 14:03:00 -0000 Hi Alex, while I do understand the use cases, there is one tough issue that the draft doesn't touch upon, namely client authentication. Consider a client connecting to a proxy server (= mount client) via ssh and using certificate authentication. How is the proxy server supposed to authenticate against the mount server without having the client's private key? We all know that authentication in the original NFS is broken, and requiring things like Kerberos for NETCONF is a non-starter. Lada "Alexander Clemm (alex)" writes: > Hi, > > > We just posted last night a new Internet Draft "Mounting YANG-Defined Information from Remote Datastores", see http://tools.ietf.org/html/draft-clemm-netmod-mount-00. > > > > The draft addresses the problem of how to reference information from remote datastores, without needing to actually replicate that information (in its own model and datastore). This helps address multiple problems, for example the issue of maintaining an authorative set of global configuration settings that are shared and exposed by multiple devices, and the issue of allowing one device to expose information about the network and other devices without need for replication, but in a federated way. > > > > The abstract reads as follows: > > This document introduces a new capability that allows YANG datastores > > to reference and incorporate information from remote datastores. > > This is accomplished using a new YANG data model that allows to > > define and manage datastore mount points that reference data nodes in > > remote datastores. The data model includes a set of YANG extensions > > for the purposes of declaring such mount points. > > > We are looking forward to discussing this with the working group and welcome your feedback. > > Regards > --- Alex > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Wed Mar 27 07:20:26 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE31121F9154 for ; Wed, 27 Mar 2013 07:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.18 X-Spam-Level: X-Spam-Status: No, score=-0.18 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_210=0.6, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bc3D8gdd1mC for ; Wed, 27 Mar 2013 07:20:25 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id ACB6C21F914C for ; Wed, 27 Mar 2013 07:20:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id AE51854014F; Wed, 27 Mar 2013 15:20:20 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbEkCqAxJa-N; Wed, 27 Mar 2013 15:20:04 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 0D39C5400CD; Wed, 27 Mar 2013 15:20:03 +0100 (CET) From: Ladislav Lhotka To: Anton =?utf-8?B?VGvDocSNaWs=?= , Andy Bierman In-Reply-To: <1404210365.223284.1364302786043.JavaMail.root@pantheon.sk> References: <1404210365.223284.1364302786043.JavaMail.root@pantheon.sk> User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Anton =?utf-8?B?VGvDocSNaWs=?= , Andy Bierman , "Jan Medved \(jmedved\)" , netmod@ietf.org Date: Wed, 27 Mar 2013 15:20:02 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "Jan Medved \(jmedved\)" , netmod@ietf.org Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 14:20:26 -0000 Hi, Anton Tk=C3=A1=C4=8Dik writes: > Hi, > The interesting idea in this draft is to reuse of existing YANG schemas > and nesting their data definitions in the other schemas (config/running t= ree). IMO the draft is about sharing a subtree from a remote datastore (i.e., an = instance document in XML terms) and not about reusing schemas. The draft as= sumes that all checks are done on the mount server. > > YANG in current state does not allow reusing of containers defined in ano= ther modules > (it could be done by using anyxml statement but we loose machine-readable > semantics of the nested data). > > For example if we want to model logical subsystems of network element by = reusing ietf-interfaces > currently we have only one option: > > rw if:interfaces > rw ls:logical-systems > +-- rw ls:logical-system [id] > +-- rw ls:interfaces > > Where interfaces is leaflist of instance-identifier or leafref of interfa= ces. > > With the nesting of data, the model is more straighforward and also the i= nterfaces > for logical subsystem are separated in the tree. > > rw ls:logical-systems > +-- rw ls:logical-system > +-- rw if:interfaces YANG is not designed to allow such an bottom-up approach. Note that this co= uld for example break XPath expressions. Lada > > > So I would suggest explore the use cases for the nesting YANG schemas / m= odules > in the tree, because mounting of remote datastores is only special use ca= se=20 > of the YANG data nesting. > > > Anton Tkacik > > ----- Original Message ----- >> From: "Andy Bierman" >> To: "Alexander Clemm (alex)" >> Cc: "Jan Medved (jmedved)" , netmod@ietf.org >> Sent: Tuesday, March 26, 2013 12:26:59 AM >> Subject: [netmod] Mounting YANG-Defined Information from Remote Datastor= es >>=20 >> Hi, >>=20 >> I am still not clear what problem is being solved here. >> It sure looks like a really complicated form of NETCONF Proxy. >> Operators begged us at the IAB Workshop on NM >> not to let proxy servers anywhere near NETCONF. >>=20 >> You talk about mounting read-only shared config so >> it can be rendered properly in an application. >> This sounds like a mid-level manager job. >>=20 >> The NETCONF transaction model and definition of the running >> datastore is very clear, and already complicated enough. >> The protocol does not allow for "guest config" that is really >> shared. One could view it is just a huge implementation >> detail I guess, making it completely proprietary and outside >> the scope of the standard. >>=20 >> It also seems to be quite a security hole. >> A vulnerability in server A can allow config >> in server B to be changed. A hole in the >> access control could allow a hacker to mount >> additional remote config sections from other routers, >> spreading the attack through the network. >>=20 >>=20 >> Andy >>=20 >>=20 >>=20 >>=20 >> On Mon, Mar 25, 2013 at 4:09 PM, Alexander Clemm (alex) >> wrote: >> > I am not clear how the presence of one Netconf client will break anoth= er >> > Netconf client. >> > I don't think there is anything that would prohibit a system that >> > implements a Netconf client to act as a server to another application. >> > How to have such a system implement full transactional capabilities has >> > challenges, much like full transactionality is a challenge for a servi= ce >> > provisioning application. Agree, we need to call these out, in partic= ular >> > in as far it would mean not being able to support full transactional >> > capabilities (at the level of the mount client in as far as it acts as= a >> > server to another app - I think it is these higher apps that you are >> > concerned about - the clients of the clients, so to speak). >> > --- Alex >> > >> > -----Original Message----- >> > From: Andy Bierman [mailto:andy@yumaworks.com] >> > Sent: Monday, March 25, 2013 3:34 PM >> > To: Alexander Clemm (alex) >> > Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) >> > Subject: Re: [netmod] Mounting YANG-Defined Information from Remote >> > Datastores >> > >> > "Instead, any mount client is "just a client", similar to e.g. a servi= ce >> > provisioning app." >> > >> > Whatever the NETCONF server advertises as configuration in its running >> > config, a NETCONF client will think it is "just a server". >> > This breaks existing NETCONF clients. >> > >> > >> > >> > Andy >> > >> > >> > On Mon, Mar 25, 2013 at 2:37 PM, Alexander Clemm (alex) >> > wrote: >> >> Hi Andy, >> >> >> >> Correct, if information in the server (S1 in this case) is updated, t= he >> >> change will show up in the places that mount that information (S2 and= S3, >> >> in this case), just like changes made by a provisioning system to a >> >> server will show up in other applications when they obtain a view of = the >> >> configuration information on a server. >> >> >> >> Our proposal does not make transactionality issues disappear, just li= ke a >> >> provisioning system cannot guarantee transactionality to its clients = if >> >> the underlying server(s) do not provide corresponding support as well. >> >> These dependencies and what our proposal does and does not do are >> >> something we will make clearer in the next revision. At the same tim= e, >> >> with the mount proposal, it is always clear who the authorative >> >> copy/owner of data is where the data is maintained, validated, etc. T= here >> >> is an authorative copy, and authorative owner; this is not about "pee= rs" >> >> sharing "equal copies" that need to be kept in synch etc. Instead, a= ny >> >> mount client is "just a client", similar to e.g. a service provisioni= ng >> >> app. Another way to look at a mount client is as a "proxy", retrievi= ng >> >> and accessing information on another client's behalf. The fact that = the >> >> client "mounts" information from the server does not change anything = for >> >> the server; it does not affect its model, nor how the serv >> er maintains its datastore. The mount proposal does make it easier for >> such a client application to render information that it accesses from >> another system in a way that does not require to maintain and implement= a >> separate set of data models that would in effect duplicate the same >> information. >> >> >> >> Regards >> >> --- Alex >> >> >> >> -----Original Message----- >> >> From: Andy Bierman [mailto:andy@yumaworks.com] >> >> Sent: Friday, March 22, 2013 7:08 PM >> >> To: Alexander Clemm (alex) >> >> Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) >> >> Subject: Re: [netmod] Mounting YANG-Defined Information from Remote >> >> Datastores >> >> >> >> Hi, >> >> >> >> Let me try a simple example: >> >> >> >> There are 3 servers (S1, S2, S3): >> >> >> >> +------------------+ >> >> | S1 | --> /public >> >> +-----------------+ >> >> >> >> >> >> +------------------+ >> >> | S2 | --> mount(S1:/public) >> >> +-----------------+ >> >> >> >> >> >> +------------------+ >> >> | S3 | --> mount(S1:/public) >> >> +-----------------+ >> >> >> >> S1 is the server that is sharing the subtree /public. >> >> S2 and S3 both 'clients', and mount S1:/public in their configs. >> >> Any changes to /public done on any server magically appear on the oth= er 2 >> >> servers. Correct or not? >> >> >> >> IMO, NFS is a fairly heavy-weight protocol and making NETCONF as comp= lex >> >> as NFS is not a feature. >> >> >> >> >> >> >> >> Andy >> >> >> >> >> >> On Fri, Mar 22, 2013 at 5:41 PM, Alexander Clemm (alex) >> >> wrote: >> >>> Hello Andy, >> >>> >> >>> What we have in mind is a little less complicated than what you are >> >>> concerned with. >> >>> >> >>> Think of a mount client as a client app, like other client apps. Th= is >> >>> can be transparent to the owner/server of the datastore with the data >> >>> items that are mounted. The owner/server of the datastore with moun= ted >> >>> data items really isn't affected at all, nor are other client >> >>> applications that interact with the same server; the mount client >> >>> constitutes just another client application. The "ownership" of the >> >>> data - the master copy, if you will - is not in question, and not >> >>> changed by our proposal. Validation still occurs in the original >> >>> datastore. The mount client merely "renders" the information that is >> >>> retrieved, and operated on, in a way that makes it appear as if it w= ere >> >>> part of its own datastore. However, the mount client now does have = the >> >>> capability to validate "its" configurations in its own datastore (the >> >>> ones that it actually owns, not ones that are mounted) against other >> >>> configurations in the network. This is a problem today, where you n= eed >> >>> to rely on external >> applications to ensure network-wide consistency. >> >>> >> >>> Many uses for this only require providing visibility and the ability= to >> >>> retrieve information. Only some of the use cases involve the need to >> >>> actually modify information from remote. Where that is the case, the >> >>> mount client acts analogous to a provisioning application as far as = the >> >>> server is concerned. Obviously, transactionality is an issue for a >> >>> mount client, just like it is an issue to a provisioning application. >> >>> Where a client app is not able to obtain a needed lock, for instance, >> >>> it cannot provide a lock to its own applications, which is really no >> >>> different from the situation that a provisioning application that >> >>> provisions a service across a network would face. >> >>> >> >>> Regards >> >>> --- Alex >> >>> >> >>> -----Original Message----- >> >>> From: Andy Bierman [mailto:andy@yumaworks.com] >> >>> Sent: Friday, March 22, 2013 9:05 AM >> >>> To: Alexander Clemm (alex) >> >>> Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) >> >>> Subject: Re: [netmod] Mounting YANG-Defined Information from Remote >> >>> Datastores >> >>> >> >>> Hi, >> >>> >> >>> I'm not sure I understand the use-cases here. >> >>> This is certainly a different approach to network-wide config. >> >>> This would seem to require that all the NETCONF servers sharing the = same >> >>> config subtree need to be highly coordinated, since operations on ea= ch >> >>> server affect all the others. >> >>> >> >>> For example, if a client takes out a partial-lock on a shared node f= rom >> >>> server-1, it has to check all the other servers and the lock is shar= ed >> >>> across all servers. Access control would also be shared I guess. >> >>> >> >>> Do the contexts of shared nodes in candidate configs magically chang= e or >> >>> do they stay out-of-date if modified in another server? >> >>> Does the entire running config in every server have to validate befo= re >> >>> any 1 server can commit a change to a shared node? >> >>> >> >>> The complexities this adds to the NETCONF transaction model and >> >>> confirmed commit procedure are dramatic. The possibilities for >> >>> must/when expressions to evaluate differently in each server just >> >>> adds to the fun ;-) >> >>> >> >>> In previous discussions on network-wide configuration it was assumed= a >> >>> YANG model representing the network wide feature would be provided b= y a >> >>> single server, and it is an implementation detail how that server >> >>> interacts with other network devices. >> >>> >> >>> I do not see the advantages of treating the config like an NFS file >> >>> system. >> >>> >> >>> >> >>> >> >>> Andy >> >>> >> >>> >> >>> On Fri, Mar 22, 2013 at 8:00 AM, Alexander Clemm (alex) >> >>> wrote: >> >>>> Hi, >> >>>> >> >>>> >> >>>> >> >>>> We just posted last night a new Internet Draft "Mounting >> >>>> YANG-Defined Information from Remote Datastores", see >> >>>> http://tools.ietf.org/html/draft-clemm-netmod-mount-00. >> >>>> >> >>>> >> >>>> >> >>>> The draft addresses the problem of how to reference information from >> >>>> remote datastores, without needing to actually replicate that >> >>>> information (in its own model and datastore). This helps address >> >>>> multiple problems, for example the issue of maintaining an >> >>>> authorative set of global configuration settings that are shared and >> >>>> exposed by multiple devices, and the issue of allowing one device to >> >>>> expose information about the network and other devices without need= for >> >>>> replication, but in a federated way. >> >>>> >> >>>> >> >>>> >> >>>> The abstract reads as follows: >> >>>> >> >>>> This document introduces a new capability that allows YANG >> >>>> datastores >> >>>> >> >>>> to reference and incorporate information from remote datastores. >> >>>> >> >>>> This is accomplished using a new YANG data model that allows to >> >>>> >> >>>> define and manage datastore mount points that reference data >> >>>> nodes in >> >>>> >> >>>> remote datastores. The data model includes a set of YANG >> >>>> extensions >> >>>> >> >>>> for the purposes of declaring such mount points. >> >>>> >> >>>> >> >>>> >> >>>> We are looking forward to discussing this with the working group and >> >>>> welcome your feedback. >> >>>> >> >>>> >> >>>> >> >>>> Regards >> >>>> >> >>>> --- Alex >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> 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 >>=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Wed Mar 27 07:47:56 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4EC21F85C6 for ; Wed, 27 Mar 2013 07:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.403 X-Spam-Level: X-Spam-Status: No, score=-0.403 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_210=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3VmmqI+HFYc for ; Wed, 27 Mar 2013 07:47:55 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0D55221F91A5 for ; Wed, 27 Mar 2013 07:47:54 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id bn7so8092198ieb.9 for ; Wed, 27 Mar 2013 07:47:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding :x-gm-message-state; bh=mrgWRNH+kBFfwrmdJmDKzXn6GDzJGHTdVGvs6DnGTLc=; b=QHvmojEyGY/PmfCHgunwDEXB6CJHQBqniHEXiIfi5QjaB5oEBu/+phZ031rPsrU3z1 Y3ygjlI2hHzXhTRR2irhV+noF7ROJDYDFmUxNWYYjhjGIBetCKVXrtp9YDQz0en+EDAm ifCchmnaxGNVsTXoUcIhcDW/RfkM1C22G3qUvsbnWgiJsRWXy81/Cx7Yc0NsFAOqeKTM MjUqLxwsNaU2OV8k6J/JlwB3hlpHSBKmdl20VK1Res/b5a1Oil6Bcl+3KTwVSdkytVjB pYAuhPc2ze+K4B9F/gzDkgrNcpw2+rroNgIgfM7adfvZxqjngPZ7i1y1KV4l8TmXFaEz swhg== MIME-Version: 1.0 X-Received: by 10.50.153.198 with SMTP id vi6mr4407815igb.112.1364395674570; Wed, 27 Mar 2013 07:47:54 -0700 (PDT) Received: by 10.231.34.68 with HTTP; Wed, 27 Mar 2013 07:47:54 -0700 (PDT) In-Reply-To: References: <1404210365.223284.1364302786043.JavaMail.root@pantheon.sk> Date: Wed, 27 Mar 2013 07:47:54 -0700 Message-ID: From: Andy Bierman To: =?UTF-8?B?QW50b24gVGvDocSNaWs=?= , Andy Bierman , "Jan Medved (jmedved)" , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkZC0QJPK5kxdTSsk8W+hvPuwqSIMR/O1BCV6gI99x5h5Va/T0ciYr8LOa8NEG9haVmm0Hq Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 14:47:56 -0000 On Wed, Mar 27, 2013 at 7:20 AM, Ladislav Lhotka wrote: > Hi, > > Anton Tk=C3=A1=C4=8Dik writes: > >> Hi, >> The interesting idea in this draft is to reuse of existing YANG schemas >> and nesting their data definitions in the other schemas (config/running = tree). > > IMO the draft is about sharing a subtree from a remote datastore (i.e., a= n instance document in XML terms) and not about reusing schemas. The draft = assumes that all checks are done on the mount server. > The operators at the IAB NM Workshop discussed why they did not like SNMP Proxy, citing cascading security vulnerabilities and unwarranted complexity. NETCONF Proxy looks even worse. The server mounting the shared data sub-trees is still obligated to provide all the functionality it advertises to RFC 6241 compliant clients. In order for the config nodes to be read-only, the server must advertise deviation statements that change the config=3Dtrue to config=3Dfalse nodes. In order for the shared data nodes to be config=3Dtrue, the server must honor all supported operations, including locking. Locks on shared nodes has to be enforced on all servers that have the shared data. There is no authoritative server according to RFC 6241. There is only the 1 server that the client is managing with 1 NETCONF session. Andy >> >> YANG in current state does not allow reusing of containers defined in an= other modules >> (it could be done by using anyxml statement but we loose machine-readabl= e >> semantics of the nested data). >> >> For example if we want to model logical subsystems of network element by= reusing ietf-interfaces >> currently we have only one option: >> >> rw if:interfaces >> rw ls:logical-systems >> +-- rw ls:logical-system [id] >> +-- rw ls:interfaces >> >> Where interfaces is leaflist of instance-identifier or leafref of interf= aces. >> >> With the nesting of data, the model is more straighforward and also the = interfaces >> for logical subsystem are separated in the tree. >> >> rw ls:logical-systems >> +-- rw ls:logical-system >> +-- rw if:interfaces > > YANG is not designed to allow such an bottom-up approach. Note that this = could for example break XPath expressions. > > Lada > >> >> >> So I would suggest explore the use cases for the nesting YANG schemas / = modules >> in the tree, because mounting of remote datastores is only special use c= ase >> of the YANG data nesting. >> >> >> Anton Tkacik >> >> ----- Original Message ----- >>> From: "Andy Bierman" >>> To: "Alexander Clemm (alex)" >>> Cc: "Jan Medved (jmedved)" , netmod@ietf.org >>> Sent: Tuesday, March 26, 2013 12:26:59 AM >>> Subject: [netmod] Mounting YANG-Defined Information from Remote Datasto= res >>> >>> Hi, >>> >>> I am still not clear what problem is being solved here. >>> It sure looks like a really complicated form of NETCONF Proxy. >>> Operators begged us at the IAB Workshop on NM >>> not to let proxy servers anywhere near NETCONF. >>> >>> You talk about mounting read-only shared config so >>> it can be rendered properly in an application. >>> This sounds like a mid-level manager job. >>> >>> The NETCONF transaction model and definition of the running >>> datastore is very clear, and already complicated enough. >>> The protocol does not allow for "guest config" that is really >>> shared. One could view it is just a huge implementation >>> detail I guess, making it completely proprietary and outside >>> the scope of the standard. >>> >>> It also seems to be quite a security hole. >>> A vulnerability in server A can allow config >>> in server B to be changed. A hole in the >>> access control could allow a hacker to mount >>> additional remote config sections from other routers, >>> spreading the attack through the network. >>> >>> >>> Andy >>> >>> >>> >>> >>> On Mon, Mar 25, 2013 at 4:09 PM, Alexander Clemm (alex) >>> wrote: >>> > I am not clear how the presence of one Netconf client will break anot= her >>> > Netconf client. >>> > I don't think there is anything that would prohibit a system that >>> > implements a Netconf client to act as a server to another application= . >>> > How to have such a system implement full transactional capabilities h= as >>> > challenges, much like full transactionality is a challenge for a serv= ice >>> > provisioning application. Agree, we need to call these out, in parti= cular >>> > in as far it would mean not being able to support full transactional >>> > capabilities (at the level of the mount client in as far as it acts a= s a >>> > server to another app - I think it is these higher apps that you are >>> > concerned about - the clients of the clients, so to speak). >>> > --- Alex >>> > >>> > -----Original Message----- >>> > From: Andy Bierman [mailto:andy@yumaworks.com] >>> > Sent: Monday, March 25, 2013 3:34 PM >>> > To: Alexander Clemm (alex) >>> > Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) >>> > Subject: Re: [netmod] Mounting YANG-Defined Information from Remote >>> > Datastores >>> > >>> > "Instead, any mount client is "just a client", similar to e.g. a serv= ice >>> > provisioning app." >>> > >>> > Whatever the NETCONF server advertises as configuration in its runnin= g >>> > config, a NETCONF client will think it is "just a server". >>> > This breaks existing NETCONF clients. >>> > >>> > >>> > >>> > Andy >>> > >>> > >>> > On Mon, Mar 25, 2013 at 2:37 PM, Alexander Clemm (alex) >>> > wrote: >>> >> Hi Andy, >>> >> >>> >> Correct, if information in the server (S1 in this case) is updated, = the >>> >> change will show up in the places that mount that information (S2 an= d S3, >>> >> in this case), just like changes made by a provisioning system to a >>> >> server will show up in other applications when they obtain a view of= the >>> >> configuration information on a server. >>> >> >>> >> Our proposal does not make transactionality issues disappear, just l= ike a >>> >> provisioning system cannot guarantee transactionality to its clients= if >>> >> the underlying server(s) do not provide corresponding support as wel= l. >>> >> These dependencies and what our proposal does and does not do are >>> >> something we will make clearer in the next revision. At the same ti= me, >>> >> with the mount proposal, it is always clear who the authorative >>> >> copy/owner of data is where the data is maintained, validated, etc. = There >>> >> is an authorative copy, and authorative owner; this is not about "pe= ers" >>> >> sharing "equal copies" that need to be kept in synch etc. Instead, = any >>> >> mount client is "just a client", similar to e.g. a service provision= ing >>> >> app. Another way to look at a mount client is as a "proxy", retriev= ing >>> >> and accessing information on another client's behalf. The fact that= the >>> >> client "mounts" information from the server does not change anything= for >>> >> the server; it does not affect its model, nor how the serv >>> er maintains its datastore. The mount proposal does make it easier f= or >>> such a client application to render information that it accesses from >>> another system in a way that does not require to maintain and implemen= t a >>> separate set of data models that would in effect duplicate the same >>> information. >>> >> >>> >> Regards >>> >> --- Alex >>> >> >>> >> -----Original Message----- >>> >> From: Andy Bierman [mailto:andy@yumaworks.com] >>> >> Sent: Friday, March 22, 2013 7:08 PM >>> >> To: Alexander Clemm (alex) >>> >> Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) >>> >> Subject: Re: [netmod] Mounting YANG-Defined Information from Remote >>> >> Datastores >>> >> >>> >> Hi, >>> >> >>> >> Let me try a simple example: >>> >> >>> >> There are 3 servers (S1, S2, S3): >>> >> >>> >> +------------------+ >>> >> | S1 | --> /public >>> >> +-----------------+ >>> >> >>> >> >>> >> +------------------+ >>> >> | S2 | --> mount(S1:/public) >>> >> +-----------------+ >>> >> >>> >> >>> >> +------------------+ >>> >> | S3 | --> mount(S1:/public) >>> >> +-----------------+ >>> >> >>> >> S1 is the server that is sharing the subtree /public. >>> >> S2 and S3 both 'clients', and mount S1:/public in their configs. >>> >> Any changes to /public done on any server magically appear on the ot= her 2 >>> >> servers. Correct or not? >>> >> >>> >> IMO, NFS is a fairly heavy-weight protocol and making NETCONF as com= plex >>> >> as NFS is not a feature. >>> >> >>> >> >>> >> >>> >> Andy >>> >> >>> >> >>> >> On Fri, Mar 22, 2013 at 5:41 PM, Alexander Clemm (alex) >>> >> wrote: >>> >>> Hello Andy, >>> >>> >>> >>> What we have in mind is a little less complicated than what you are >>> >>> concerned with. >>> >>> >>> >>> Think of a mount client as a client app, like other client apps. T= his >>> >>> can be transparent to the owner/server of the datastore with the da= ta >>> >>> items that are mounted. The owner/server of the datastore with mou= nted >>> >>> data items really isn't affected at all, nor are other client >>> >>> applications that interact with the same server; the mount client >>> >>> constitutes just another client application. The "ownership" of th= e >>> >>> data - the master copy, if you will - is not in question, and not >>> >>> changed by our proposal. Validation still occurs in the original >>> >>> datastore. The mount client merely "renders" the information that = is >>> >>> retrieved, and operated on, in a way that makes it appear as if it = were >>> >>> part of its own datastore. However, the mount client now does have= the >>> >>> capability to validate "its" configurations in its own datastore (t= he >>> >>> ones that it actually owns, not ones that are mounted) against othe= r >>> >>> configurations in the network. This is a problem today, where you = need >>> >>> to rely on external >>> applications to ensure network-wide consistency. >>> >>> >>> >>> Many uses for this only require providing visibility and the abilit= y to >>> >>> retrieve information. Only some of the use cases involve the need = to >>> >>> actually modify information from remote. Where that is the case, t= he >>> >>> mount client acts analogous to a provisioning application as far as= the >>> >>> server is concerned. Obviously, transactionality is an issue for a >>> >>> mount client, just like it is an issue to a provisioning applicatio= n. >>> >>> Where a client app is not able to obtain a needed lock, for instanc= e, >>> >>> it cannot provide a lock to its own applications, which is really n= o >>> >>> different from the situation that a provisioning application that >>> >>> provisions a service across a network would face. >>> >>> >>> >>> Regards >>> >>> --- Alex >>> >>> >>> >>> -----Original Message----- >>> >>> From: Andy Bierman [mailto:andy@yumaworks.com] >>> >>> Sent: Friday, March 22, 2013 9:05 AM >>> >>> To: Alexander Clemm (alex) >>> >>> Cc: netmod@ietf.org; Eric Voit (evoit); Jan Medved (jmedved) >>> >>> Subject: Re: [netmod] Mounting YANG-Defined Information from Remote >>> >>> Datastores >>> >>> >>> >>> Hi, >>> >>> >>> >>> I'm not sure I understand the use-cases here. >>> >>> This is certainly a different approach to network-wide config. >>> >>> This would seem to require that all the NETCONF servers sharing the= same >>> >>> config subtree need to be highly coordinated, since operations on e= ach >>> >>> server affect all the others. >>> >>> >>> >>> For example, if a client takes out a partial-lock on a shared node = from >>> >>> server-1, it has to check all the other servers and the lock is sha= red >>> >>> across all servers. Access control would also be shared I guess. >>> >>> >>> >>> Do the contexts of shared nodes in candidate configs magically chan= ge or >>> >>> do they stay out-of-date if modified in another server? >>> >>> Does the entire running config in every server have to validate bef= ore >>> >>> any 1 server can commit a change to a shared node? >>> >>> >>> >>> The complexities this adds to the NETCONF transaction model and >>> >>> confirmed commit procedure are dramatic. The possibilities for >>> >>> must/when expressions to evaluate differently in each server just >>> >>> adds to the fun ;-) >>> >>> >>> >>> In previous discussions on network-wide configuration it was assume= d a >>> >>> YANG model representing the network wide feature would be provided = by a >>> >>> single server, and it is an implementation detail how that server >>> >>> interacts with other network devices. >>> >>> >>> >>> I do not see the advantages of treating the config like an NFS file >>> >>> system. >>> >>> >>> >>> >>> >>> >>> >>> Andy >>> >>> >>> >>> >>> >>> On Fri, Mar 22, 2013 at 8:00 AM, Alexander Clemm (alex) >>> >>> wrote: >>> >>>> Hi, >>> >>>> >>> >>>> >>> >>>> >>> >>>> We just posted last night a new Internet Draft "Mounting >>> >>>> YANG-Defined Information from Remote Datastores", see >>> >>>> http://tools.ietf.org/html/draft-clemm-netmod-mount-00. >>> >>>> >>> >>>> >>> >>>> >>> >>>> The draft addresses the problem of how to reference information fr= om >>> >>>> remote datastores, without needing to actually replicate that >>> >>>> information (in its own model and datastore). This helps address >>> >>>> multiple problems, for example the issue of maintaining an >>> >>>> authorative set of global configuration settings that are shared a= nd >>> >>>> exposed by multiple devices, and the issue of allowing one device = to >>> >>>> expose information about the network and other devices without nee= d for >>> >>>> replication, but in a federated way. >>> >>>> >>> >>>> >>> >>>> >>> >>>> The abstract reads as follows: >>> >>>> >>> >>>> This document introduces a new capability that allows YANG >>> >>>> datastores >>> >>>> >>> >>>> to reference and incorporate information from remote datastores= . >>> >>>> >>> >>>> This is accomplished using a new YANG data model that allows to >>> >>>> >>> >>>> define and manage datastore mount points that reference data >>> >>>> nodes in >>> >>>> >>> >>>> remote datastores. The data model includes a set of YANG >>> >>>> extensions >>> >>>> >>> >>>> for the purposes of declaring such mount points. >>> >>>> >>> >>>> >>> >>>> >>> >>>> We are looking forward to discussing this with the working group a= nd >>> >>>> welcome your feedback. >>> >>>> >>> >>>> >>> >>>> >>> >>>> Regards >>> >>>> >>> >>>> --- Alex >>> >>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> 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 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C From andy@yumaworks.com Wed Mar 27 08:31:44 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D804421F91C5 for ; Wed, 27 Mar 2013 08:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.228 X-Spam-Level: X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWNSj1Voyugm for ; Wed, 27 Mar 2013 08:31:03 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3984321F91BF for ; Wed, 27 Mar 2013 08:31:02 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id 17so10461775iea.12 for ; Wed, 27 Mar 2013 08:30:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding :x-gm-message-state; bh=q8/8NRBBcXhuTbrEN8GcVzCh9UcAG12R3lWe+H27Pj0=; b=j6ntpvGcapaNLC3ic0Cv8wJeoFxR0jb6ivNfqUsA0QW36kxUFJkMaokpV+qamuq4y/ FbPxzIFAzCj3Geo75h0PWVHB9mKuwHMgFqAOB1/1BK8a9tq5yBU7THpkQKCdfGo7c6lq f+xAs7zGVx56uivI5Vrf0MnSnZK+qjGikrJ3S6LvklT+hsVcYxHySaKwYVKqbJOgsrCf vfkCUP+ZGSeKo1bLqJbBUpI2Ldq08Q21YWV6VSlHlxlsIF7Haq/GGSWCnE3abW+jGojK 5+o3y//CoWqJP/3Q83we8e55nk9RKBlQg10BnSU9dWN3Nv2W2DkzUPvVXJzCQTzY8g0e 7AMw== MIME-Version: 1.0 X-Received: by 10.42.29.198 with SMTP id s6mr12090829icc.54.1364398256515; Wed, 27 Mar 2013 08:30:56 -0700 (PDT) Received: by 10.231.34.68 with HTTP; Wed, 27 Mar 2013 08:30:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Mar 2013 08:30:56 -0700 Message-ID: From: Andy Bierman To: "Alexander Clemm (alex)" , "netmod@ietf.org" , "Eric Voit (evoit)" , "Jan Medved (jmedved)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQldIhCC4Rag7/ma62bJQvAuWgl1sJ9sl6rrWZ1kAoAYW6n3GO94zeOFoXi/4dT63HZ7QfVp Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 15:31:44 -0000 Hi, This seems to make existing NETCONF security weaknesses even worse. A NETCONF client that is able to invoke the operation on the running config on 1 server will prevent all sessions on all other servers from writing any of the shared config in the locked server. This gets complicated with N servers, each with potentially different shared data. Once any shared data is locked, no server that has that data can allow its config to be globally locked (already partially locked). The normal datastore edit procedure (lock + edit + unlock) will create a management plane bottleneck for all the servers sharing data. Clients will compete for locks (first wins) across all servers, not 1. Could be an interesting DoS attack. Andy On Wed, Mar 27, 2013 at 7:02 AM, Ladislav Lhotka wrote: > Hi Alex, > > while I do understand the use cases, there is one tough issue that the dr= aft doesn't touch upon, namely client authentication. Consider a client con= necting to a proxy server (=3D mount client) via ssh and using certificate = authentication. How is the proxy server supposed to authenticate against th= e mount server without having the client's private key? > > We all know that authentication in the original NFS is broken, and requir= ing things like Kerberos for NETCONF is a non-starter. > > Lada > > "Alexander Clemm (alex)" writes: > >> Hi, >> >> >> We just posted last night a new Internet Draft "Mounting YANG-Defined In= formation from Remote Datastores", see http://tools.ietf.org/html/draft-cl= emm-netmod-mount-00. >> >> >> >> The draft addresses the problem of how to reference information from rem= ote datastores, without needing to actually replicate that information (in = its own model and datastore). This helps address multiple problems, for ex= ample the issue of maintaining an authorative set of global configuration s= ettings that are shared and exposed by multiple devices, and the issue of a= llowing one device to expose information about the network and other device= s without need for replication, but in a federated way. >> >> >> >> The abstract reads as follows: >> >> This document introduces a new capability that allows YANG datastores >> >> to reference and incorporate information from remote datastores. >> >> This is accomplished using a new YANG data model that allows to >> >> define and manage datastore mount points that reference data nodes in >> >> remote datastores. The data model includes a set of YANG extensions >> >> for the purposes of declaring such mount points. >> >> >> We are looking forward to discussing this with the working group and wel= come your feedback. >> >> Regards >> --- Alex >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From jernej.tuljak@mg-soft.si Fri Mar 29 08:26:43 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5DC21F93CE for ; Fri, 29 Mar 2013 08:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRf-CcNMVwNx for ; Fri, 29 Mar 2013 08:26:40 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id B99F721F93FF for ; Fri, 29 Mar 2013 08:26:39 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id r2TFQbdf021621; Fri, 29 Mar 2013 16:26:37 +0100 Message-ID: <5155B2A8.8050104@mg-soft.com> Date: Fri, 29 Mar 2013 16:26:32 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ladislav Lhotka References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> In-Reply-To: <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> Content-Type: multipart/alternative; boundary="------------020800070109090101010805" Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 15:26:43 -0000 This is a multi-part message in MIME format. --------------020800070109090101010805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dne 22.2.2013 18:12, pis(e Ladislav Lhotka: > On Feb 22, 2013, at 6:03 PM, Andy Bierman wrote: > >> >> On Fri, Feb 22, 2013 at 8:50 AM, Ladislav Lhotka wrote: >> >> On Feb 22, 2013, at 5:33 PM, Andy Bierman wrote: >> >>> >>> On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklund wrote: >>> Ladislav Lhotka wrote: >>>> On Feb 22, 2013, at 4:19 PM, Martin Bjorklund wrote: >>>>> But what about collisions? Compare w/ #ifndef. >>>> With transitive inclusions, collisions have to be avoided in any >>>> case. >>> Exactly. But with the current text, collisions are avoided, since it >>> is only the module that "incorporates" the contents of the >>> submodules. >>> >>> >>> >>> IMO, for export purposes, submodules are conceptually flat -- they all contribute >>> to the module namespace. The compiler has to detect any naming collisions for the >>> entire module namespace. >>> >>> With your interpretation, how would the following corner-case be handled? >>> >>> module A { >>> include B; >>> typedef X { type string; } >>> } >>> >>> submodule B { >>> include C; >>> leaf a { type a:X; } >>> } >>> >>> submodule C { >>> typedef X { type int32; } >>> } >>> >> With scenario (3), leaf "a" would be int32, and for a module importing A, the X type would be an alias for string. With scenario (1), it is an error because B includes C but A doesn't. >> >> >> IMO, any compiler should report an error because it has to parse module A >> in order to get to submodule C. It must include B and then C and then >> must parse the duplicate typedef. >> >> But my example seems to be legal YANG if submodules are treated as separate namespaces. >> I don't think there is any text that says A MUST include C. >> If it does there will be a conflict, but if C is only visible to B, >> and the only typedef X visible to B is int32, the compiler must accept it, >> and the typedef "X" has a hidden different version within the module. > Yes, and that is, I think, the essence of (3). It can be useful, for instance, if one wants to share some definitions among multiple submodules but doesn't want to expose them to external modules. This is actually how I stumbled upon this whole issue. Sorry for reheating this up, but no matter how many times I read this entire discussion, I still have no idea what the proper way of implementing this is. Will there be modifications to RFC6020 text or not? I don't think that the current text supports option (3) the way Andy and Ladislav describe it at all. I don't like the "what's visible to external modules" part when a module that consists of submodules is imported in another module. The text for import statement says: When a module is imported, the importing module may: o use any grouping and typedef defined at the top level in the imported module or*its submodules*. o use any extension, feature, and identity defined in the imported module or*its submodules*. o use any node in the imported module's schema tree in "must", "path", and "when" statements, or as the target node in "augment" and "deviation" statements. This seems to suggest that the importing module sees MORE than may be visible to the imported module which starts the submodule inclusion chain. That is: the importing module sees both "X" typedefs, but the including module only sees the string version --> instant ambiguity upon importing. Isn't this just utterly broken? (2) would at least detect the error, which is correct IMO. The above text should say "in the imported module or *it's included submodules*" for this to work as described by Andy and Ladislav (?). Should be, since you decided that there are now two types of submodules - the ones included by the main module and the ones that are not - and this text refers to both of them (and any other type of submodule you can possibly think of, like dangling bugged ones - which aren't that hard to create - think multiple submodule revisions because someone forgot to clean up :D). I think this text makes hiding top level definitions impossible (except schema trees defined in submodules not included by main module, but why would you want to hide that?). Jernej > Lada > >> >> Lada >> >> >> Andy >> >> >>> In Yuma this would be a duplicate name error for 'X'. >>> Is that correct or is leaf a an int32 and no problem? >>> (Looks like a problem to me.) >>> >>> >>> >>> /martin >>> >>> Andy >>> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------020800070109090101010805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dne 22.2.2013 18:12, piše Ladislav Lhotka:
On Feb 22, 2013, at 6:03 PM, Andy Bierman <andy@yumaworks.com> wrote:



On Fri, Feb 22, 2013 at 8:50 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

On Feb 22, 2013, at 5:33 PM, Andy Bierman <andy@yumaworks.com> wrote:



On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:

On Feb 22, 2013, at 4:19 PM, Martin Bjorklund <mbj@tail-f.com> wrote:

But what about collisions?  Compare w/ #ifndef.

With transitive inclusions, collisions have to be avoided in any
case.

Exactly.  But with the current text, collisions are avoided, since it
is only the module that "incorporates" the contents of the
submodules.



IMO, for export purposes, submodules are conceptually flat -- they all contribute
to the module namespace.  The compiler has to detect any naming collisions for the
entire module namespace.

With your interpretation, how would the following corner-case be handled?

module A {
  include B;
  typedef X { type string; }
}

submodule B {
  include C;
  leaf a { type a:X; }
}

submodule C {
  typedef X { type int32; }
}


With scenario (3), leaf "a" would be int32, and for a module importing A, the X type would be an alias for string. With scenario (1), it is an error because B includes C but A doesn't.


IMO, any compiler should report an error because it has to parse module A
in order to get to submodule C.  It must include B and then C and then
must parse the duplicate typedef.

But my example seems to be legal YANG if submodules are treated as separate namespaces.
I don't think there is any text that says A MUST include C.
If it does there will be a conflict, but if C is only visible to B,
and the only typedef X visible to B is int32, the compiler must accept it,
and the typedef "X" has a hidden different version within the module.

Yes, and that is, I think, the essence of (3). It can be useful, for instance, if one wants to share some definitions among multiple submodules but doesn't want to expose them to external modules. This is actually how I stumbled upon this whole issue.

Sorry for reheating this up, but no matter how many times I read this entire discussion, I still have no idea what the proper way of implementing this is. Will there be modifications to RFC6020 text or not?

I don't think that the current text supports option (3) the way Andy and Ladislav describe it at all. I don't like the "what's visible to external modules" part when a module that consists of submodules is imported in another module. The text for import statement says: 
When a module is imported, the importing module may:
   o  use any grouping and typedef defined at the top level in the
      imported module or its submodules.

   o  use any extension, feature, and identity defined in the imported
      module or its submodules.

   o  use any node in the imported module's schema tree in "must",
      "path", and "when" statements, or as the target node in "augment"
      and "deviation" statements.
This seems to suggest that the importing module sees MORE than may be visible to the imported module which starts the submodule inclusion chain. That is: the importing module sees both "X" typedefs, but the including module only sees the string version --> instant ambiguity upon importing. Isn't this just utterly broken? (2) would at least detect the error, which is correct IMO.

The above text should say "in the imported module or it's included submodules" for this to work as described by Andy and Ladislav (?). Should be, since you decided that there are now two types of submodules - the ones included by the main module and the ones that are not - and this text refers to both of them (and any other type of submodule you can possibly think of, like dangling bugged ones - which aren't that hard to create - think multiple submodule revisions because someone forgot to clean up :D).

I think this text makes hiding top level definitions impossible (except schema trees defined in submodules not included by main module, but why would you want to hide that?).

Jernej

Lada


 
Lada


Andy
 


In Yuma this would be a duplicate name error for 'X'.
Is that correct or is leaf a an int32 and no problem?
(Looks like a problem to me.)



/martin

Andy


--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C






--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--------------020800070109090101010805-- From andy@yumaworks.com Fri Mar 29 09:41:24 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0796821F9406 for ; Fri, 29 Mar 2013 09:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.553 X-Spam-Level: X-Spam-Status: No, score=-1.553 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iM4PI7DJ52Iy for ; Fri, 29 Mar 2013 09:41:23 -0700 (PDT) Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA6921F944B for ; Fri, 29 Mar 2013 09:41:23 -0700 (PDT) Received: by mail-ia0-f180.google.com with SMTP id f27so538728iae.11 for ; Fri, 29 Mar 2013 09:41:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=aWbv3oHoZi3Ya0yY8sUQmnppK5vN6HD2oqt4IOPL/QE=; b=aQc6hXcYlXAa3EUXs+TcALm1Y0xqO97ETlFkRAJ+G/HM9uJym/TZNXL8WRy/cc9rXW NQcnhCj9PJq6XTe212Kt8p/B0rYGsaVzls21jw26mutSxt+x2Siun7NksV+m1XTjeRRI 1zP8fgiyADxs6m+ARAE0nA9QzGZYHea8EdPzMpp8RAQ8spASL+ktCEO//e0zG/Q0/I1z qB/EPguCR1UsvMY7mrofl2t/tsI1y2j/sRj8omvV62VYEtV0X3bhwCEbrg+6zT+Dn+gC 1RzkChqaDdPrpCl0//OsPVtvxy7KD49nI+OLHtPrVEnqnW2jDqG/BAY1V5Pv30Gk9eTz SHlQ== MIME-Version: 1.0 X-Received: by 10.50.153.198 with SMTP id vi6mr24786igb.112.1364575282720; Fri, 29 Mar 2013 09:41:22 -0700 (PDT) Received: by 10.231.34.68 with HTTP; Fri, 29 Mar 2013 09:41:22 -0700 (PDT) In-Reply-To: <5155B2A8.8050104@mg-soft.com> References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> <5155B2A8.8050104@mg-soft.com> Date: Fri, 29 Mar 2013 09:41:22 -0700 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkH5zXg1Oq+GRx4GFtC7pxukevYJduMN1hhMQbjdsGk1NO9Vlje61Ft+pe1WAvCIpjcHnmq Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 16:41:24 -0000 On Fri, Mar 29, 2013 at 8:26 AM, Jernej Tuljak wrote: ... > When a module is imported, the importing module may: > o use any grouping and typedef defined at the top level in the > imported module or its submodules. > > o use any extension, feature, and identity defined in the imported > module or its submodules. > > o use any node in the imported module's schema tree in "must", > "path", and "when" statements, or as the target node in "augment" > and "deviation" statements. > > This seems to suggest that the importing module sees MORE than may be > visible to the imported module which starts the submodule inclusion chain. > That is: the importing module sees both "X" typedefs, but the including > module only sees the string version --> instant ambiguity upon importing. > Isn't this just utterly broken? (2) would at least detect the error, which > is correct IMO. IMO the above text is correct. The include-stmt text not shown is related to the task of resolving prefixes when they are used within a sub-module, not related to exporting symbols out of the submodule. The above text says to me that all top-level symbols from the main module and all its submodules are available to the importing module. > > The above text should say "in the imported module or it's included > submodules" for this to work as described by Andy and Ladislav (?). Should > be, since you decided that there are now two types of submodules - the ones > included by the main module and the ones that are not - and this text refers > to both of them (and any other type of submodule you can possibly think of, > like dangling bugged ones - which aren't that hard to create - think > multiple submodule revisions because someone forgot to clean up :D). > > I think this text makes hiding top level definitions impossible (except > schema trees defined in submodules not included by main module, but why > would you want to hide that?). > > Jernej > Andy From lhotka@nic.cz Sat Mar 30 03:24:51 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DD721F87D2 for ; Sat, 30 Mar 2013 03:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.335 X-Spam-Level: X-Spam-Status: No, score=-0.335 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3pb0WWjkQr9 for ; Sat, 30 Mar 2013 03:24:51 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 42EED21F87D1 for ; Sat, 30 Mar 2013 03:24:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A16C95401C6 for ; Sat, 30 Mar 2013 11:24:45 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EX3jE-rrxhAV for ; Sat, 30 Mar 2013 11:24:36 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 93EDC54000E for ; Sat, 30 Mar 2013 11:24:31 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <5155B2A8.8050104@mg-soft.com> References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> <5155B2A8.8050104@mg-soft.com> User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Sat, 30 Mar 2013 11:24:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 10:24:52 -0000 Hi, for the time being, an easy fix seems to be to require that all submodules be explicitly included from the main module. This may even qualify as an erratum. Lada Jernej Tuljak writes: > Dne 22.2.2013 18:12, pis(e Ladislav Lhotka: >> On Feb 22, 2013, at 6:03 PM, Andy Bierman wrote: >> >>> >>> On Fri, Feb 22, 2013 at 8:50 AM, Ladislav Lhotka wrote: >>> >>> On Feb 22, 2013, at 5:33 PM, Andy Bierman wrote: >>> >>>> >>>> On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklund wrote: >>>> Ladislav Lhotka wrote: >>>>> On Feb 22, 2013, at 4:19 PM, Martin Bjorklund wrote: >>>>>> But what about collisions? Compare w/ #ifndef. >>>>> With transitive inclusions, collisions have to be avoided in any >>>>> case. >>>> Exactly. But with the current text, collisions are avoided, since it >>>> is only the module that "incorporates" the contents of the >>>> submodules. >>>> >>>> >>>> >>>> IMO, for export purposes, submodules are conceptually flat -- they all contribute >>>> to the module namespace. The compiler has to detect any naming collisions for the >>>> entire module namespace. >>>> >>>> With your interpretation, how would the following corner-case be handled? >>>> >>>> module A { >>>> include B; >>>> typedef X { type string; } >>>> } >>>> >>>> submodule B { >>>> include C; >>>> leaf a { type a:X; } >>>> } >>>> >>>> submodule C { >>>> typedef X { type int32; } >>>> } >>>> >>> With scenario (3), leaf "a" would be int32, and for a module importing A, the X type would be an alias for string. With scenario (1), it is an error because B includes C but A doesn't. >>> >>> >>> IMO, any compiler should report an error because it has to parse module A >>> in order to get to submodule C. It must include B and then C and then >>> must parse the duplicate typedef. >>> >>> But my example seems to be legal YANG if submodules are treated as separate namespaces. >>> I don't think there is any text that says A MUST include C. >>> If it does there will be a conflict, but if C is only visible to B, >>> and the only typedef X visible to B is int32, the compiler must accept it, >>> and the typedef "X" has a hidden different version within the module. >> Yes, and that is, I think, the essence of (3). It can be useful, for instance, if one wants to share some definitions among multiple submodules but doesn't want to expose them to external modules. This is actually how I stumbled upon this whole issue. > > Sorry for reheating this up, but no matter how many times I read this > entire discussion, I still have no idea what the proper way of > implementing this is. Will there be modifications to RFC6020 text or not? > > I don't think that the current text supports option (3) the way Andy and > Ladislav describe it at all. I don't like the "what's visible to > external modules" part when a module that consists of submodules is > imported in another module. The text for import statement says: > > When a module is imported, the importing module may: > o use any grouping and typedef defined at the top level in the > imported module or*its submodules*. > > o use any extension, feature, and identity defined in the imported > module or*its submodules*. > > o use any node in the imported module's schema tree in "must", > "path", and "when" statements, or as the target node in "augment" > and "deviation" statements. > > This seems to suggest that the importing module sees MORE than may be > visible to the imported module which starts the submodule inclusion > chain. That is: the importing module sees both "X" typedefs, but the > including module only sees the string version --> instant ambiguity upon > importing. Isn't this just utterly broken? (2) would at least detect the > error, which is correct IMO. > > The above text should say "in the imported module or *it's included > submodules*" for this to work as described by Andy and Ladislav (?). > Should be, since you decided that there are now two types of submodules > - the ones included by the main module and the ones that are not - and > this text refers to both of them (and any other type of submodule you > can possibly think of, like dangling bugged ones - which aren't that > hard to create - think multiple submodule revisions because someone > forgot to clean up :D). > > I think this text makes hiding top level definitions impossible (except > schema trees defined in submodules not included by main module, but why > would you want to hide that?). > > Jernej > >> Lada >> >>> >>> Lada >>> >>> >>> Andy >>> >>> >>>> In Yuma this would be a duplicate name error for 'X'. >>>> Is that correct or is leaf a an int32 and no problem? >>>> (Looks like a problem to me.) >>>> >>>> >>>> >>>> /martin >>>> >>>> Andy >>>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Sat Mar 30 07:54:46 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C85F21F888B for ; Sat, 30 Mar 2013 07:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.014 X-Spam-Level: X-Spam-Status: No, score=-1.014 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, J_CHICKENPOX_31=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlr7edhUK5+h for ; Sat, 30 Mar 2013 07:54:46 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id CAA2321F8881 for ; Sat, 30 Mar 2013 07:54:45 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id 9so1305583iec.4 for ; Sat, 30 Mar 2013 07:54:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=6L5orpapohacD/p+JSdfVN3n8Xweifl8pVnpyvo33RY=; b=bsqtiNHKxkjKuRvJdUYXmsb2UDAoKCBuSotNuPp0DX0xQGT8rL1d4hZ8TAAOrwUdyZ RvmuviKd7s9vEdMx1pUOM3LKODdSyk27NZ4PVzEBNhPumvZXUHe+iZKNsaV2tPzHIwPV gMK6umcmHS4khBxircq53HgdVTlKv54EAG0cu7yHK0hgs8FY9KrQ9utVm4pYwxmYqPh5 5KamoXNpNmAfsnslr81UPhppnHAJPLmN4UycZ7BvG65egKo0SAXdgevkaNlxtkxbdKIz y4EAhsRxyTiuulYZdp3785sThkWgmWyF4I1xFywA6GJRTzElJFpXOUmlp3AiotK78dHj yfyg== MIME-Version: 1.0 X-Received: by 10.50.7.69 with SMTP id h5mr1138693iga.69.1364655285079; Sat, 30 Mar 2013 07:54:45 -0700 (PDT) Received: by 10.231.34.68 with HTTP; Sat, 30 Mar 2013 07:54:44 -0700 (PDT) In-Reply-To: References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> <5155B2A8.8050104@mg-soft.com> Date: Sat, 30 Mar 2013 07:54:44 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmyM9td6S6ioFXjgBLAHZOUFj0KrJN/foy741aQ2beavXWRNaHV+zwfW/swQUKFaCy2KGc+ Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 14:54:46 -0000 On Sat, Mar 30, 2013 at 3:24 AM, Ladislav Lhotka wrote: > Hi, > > for the time being, an easy fix seems to be to require that all submodules be explicitly included from the main module. This may even qualify as an erratum. > I don't agree tat any fix is needed. I don't agree include-stmt and import-stmt are coupled in this way. > Lada > Andy > Jernej Tuljak writes: > >> Dne 22.2.2013 18:12, pis(e Ladislav Lhotka: >>> On Feb 22, 2013, at 6:03 PM, Andy Bierman wrote: >>> >>>> >>>> On Fri, Feb 22, 2013 at 8:50 AM, Ladislav Lhotka wrote: >>>> >>>> On Feb 22, 2013, at 5:33 PM, Andy Bierman wrote: >>>> >>>>> >>>>> On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklund wrote: >>>>> Ladislav Lhotka wrote: >>>>>> On Feb 22, 2013, at 4:19 PM, Martin Bjorklund wrote: >>>>>>> But what about collisions? Compare w/ #ifndef. >>>>>> With transitive inclusions, collisions have to be avoided in any >>>>>> case. >>>>> Exactly. But with the current text, collisions are avoided, since it >>>>> is only the module that "incorporates" the contents of the >>>>> submodules. >>>>> >>>>> >>>>> >>>>> IMO, for export purposes, submodules are conceptually flat -- they all contribute >>>>> to the module namespace. The compiler has to detect any naming collisions for the >>>>> entire module namespace. >>>>> >>>>> With your interpretation, how would the following corner-case be handled? >>>>> >>>>> module A { >>>>> include B; >>>>> typedef X { type string; } >>>>> } >>>>> >>>>> submodule B { >>>>> include C; >>>>> leaf a { type a:X; } >>>>> } >>>>> >>>>> submodule C { >>>>> typedef X { type int32; } >>>>> } >>>>> >>>> With scenario (3), leaf "a" would be int32, and for a module importing A, the X type would be an alias for string. With scenario (1), it is an error because B includes C but A doesn't. >>>> >>>> >>>> IMO, any compiler should report an error because it has to parse module A >>>> in order to get to submodule C. It must include B and then C and then >>>> must parse the duplicate typedef. >>>> >>>> But my example seems to be legal YANG if submodules are treated as separate namespaces. >>>> I don't think there is any text that says A MUST include C. >>>> If it does there will be a conflict, but if C is only visible to B, >>>> and the only typedef X visible to B is int32, the compiler must accept it, >>>> and the typedef "X" has a hidden different version within the module. >>> Yes, and that is, I think, the essence of (3). It can be useful, for instance, if one wants to share some definitions among multiple submodules but doesn't want to expose them to external modules. This is actually how I stumbled upon this whole issue. >> >> Sorry for reheating this up, but no matter how many times I read this >> entire discussion, I still have no idea what the proper way of >> implementing this is. Will there be modifications to RFC6020 text or not? >> >> I don't think that the current text supports option (3) the way Andy and >> Ladislav describe it at all. I don't like the "what's visible to >> external modules" part when a module that consists of submodules is >> imported in another module. The text for import statement says: >> >> When a module is imported, the importing module may: >> o use any grouping and typedef defined at the top level in the >> imported module or*its submodules*. >> >> o use any extension, feature, and identity defined in the imported >> module or*its submodules*. >> >> o use any node in the imported module's schema tree in "must", >> "path", and "when" statements, or as the target node in "augment" >> and "deviation" statements. >> >> This seems to suggest that the importing module sees MORE than may be >> visible to the imported module which starts the submodule inclusion >> chain. That is: the importing module sees both "X" typedefs, but the >> including module only sees the string version --> instant ambiguity upon >> importing. Isn't this just utterly broken? (2) would at least detect the >> error, which is correct IMO. >> >> The above text should say "in the imported module or *it's included >> submodules*" for this to work as described by Andy and Ladislav (?). >> Should be, since you decided that there are now two types of submodules >> - the ones included by the main module and the ones that are not - and >> this text refers to both of them (and any other type of submodule you >> can possibly think of, like dangling bugged ones - which aren't that >> hard to create - think multiple submodule revisions because someone >> forgot to clean up :D). >> >> I think this text makes hiding top level definitions impossible (except >> schema trees defined in submodules not included by main module, but why >> would you want to hide that?). >> >> Jernej >> >>> Lada >>> >>>> >>>> Lada >>>> >>>> >>>> Andy >>>> >>>> >>>>> In Yuma this would be a duplicate name error for 'X'. >>>>> Is that correct or is leaf a an int32 and no problem? >>>>> (Looks like a problem to me.) >>>>> >>>>> >>>>> >>>>> /martin >>>>> >>>>> Andy >>>>> >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >>>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From lhotka@nic.cz Sat Mar 30 11:03:06 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC49321F86E4 for ; Sat, 30 Mar 2013 11:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZUSsu-r78Wq for ; Sat, 30 Mar 2013 11:03:04 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E886D21F86E3 for ; Sat, 30 Mar 2013 11:03:03 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 1D59913F9B1; Sat, 30 Mar 2013 19:03:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1364666583; bh=3lBQKodLHiP5bNqDJVUR+3imhoh3WT+yc3IzkCuirng=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=cOR2YBqn2l/8UOxOsbvUQ8IK9NrFvpLGe1STvQq6bFHdmIrM2Bw4iadQ79uj199U0 xWbmfGF4AhTWAtIZZ4DWqfLklmW7sCtIcoSKhBgph4CA6cvxqRK6u/iEvTqBafozbQ w1SaXNJUn48SH+TiOjjKP5+F6NyesGeVJzFzSWLQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: Date: Sat, 30 Mar 2013 19:03:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> <5155B2A8.8050104@mg-soft.com> To: Andy Bierman X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 18:03:06 -0000 On Mar 30, 2013, at 3:54 PM, Andy Bierman wrote: > On Sat, Mar 30, 2013 at 3:24 AM, Ladislav Lhotka = wrote: >> Hi, >>=20 >> for the time being, an easy fix seems to be to require that all = submodules be explicitly included from the main module. This may even = qualify as an erratum. >>=20 >=20 > I don't agree tat any fix is needed. > I don't agree include-stmt and import-stmt are coupled in this way. Coupled? So what's your definition of "its submodules" that appears in = several places, in particular sec. 7.1.5? Lada >=20 >=20 >> Lada >>=20 >=20 > Andy >=20 >=20 >> Jernej Tuljak writes: >>=20 >>> Dne 22.2.2013 18:12, pis(e Ladislav Lhotka: >>>> On Feb 22, 2013, at 6:03 PM, Andy Bierman = wrote: >>>>=20 >>>>>=20 >>>>> On Fri, Feb 22, 2013 at 8:50 AM, Ladislav Lhotka = wrote: >>>>>=20 >>>>> On Feb 22, 2013, at 5:33 PM, Andy Bierman = wrote: >>>>>=20 >>>>>>=20 >>>>>> On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklund = wrote: >>>>>> Ladislav Lhotka wrote: >>>>>>> On Feb 22, 2013, at 4:19 PM, Martin Bjorklund = wrote: >>>>>>>> But what about collisions? Compare w/ #ifndef. >>>>>>> With transitive inclusions, collisions have to be avoided in any >>>>>>> case. >>>>>> Exactly. But with the current text, collisions are avoided, = since it >>>>>> is only the module that "incorporates" the contents of the >>>>>> submodules. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> IMO, for export purposes, submodules are conceptually flat -- = they all contribute >>>>>> to the module namespace. The compiler has to detect any naming = collisions for the >>>>>> entire module namespace. >>>>>>=20 >>>>>> With your interpretation, how would the following corner-case be = handled? >>>>>>=20 >>>>>> module A { >>>>>> include B; >>>>>> typedef X { type string; } >>>>>> } >>>>>>=20 >>>>>> submodule B { >>>>>> include C; >>>>>> leaf a { type a:X; } >>>>>> } >>>>>>=20 >>>>>> submodule C { >>>>>> typedef X { type int32; } >>>>>> } >>>>>>=20 >>>>> With scenario (3), leaf "a" would be int32, and for a module = importing A, the X type would be an alias for string. With scenario (1), = it is an error because B includes C but A doesn't. >>>>>=20 >>>>>=20 >>>>> IMO, any compiler should report an error because it has to parse = module A >>>>> in order to get to submodule C. It must include B and then C and = then >>>>> must parse the duplicate typedef. >>>>>=20 >>>>> But my example seems to be legal YANG if submodules are treated as = separate namespaces. >>>>> I don't think there is any text that says A MUST include C. >>>>> If it does there will be a conflict, but if C is only visible to = B, >>>>> and the only typedef X visible to B is int32, the compiler must = accept it, >>>>> and the typedef "X" has a hidden different version within the = module. >>>> Yes, and that is, I think, the essence of (3). It can be useful, = for instance, if one wants to share some definitions among multiple = submodules but doesn't want to expose them to external modules. This is = actually how I stumbled upon this whole issue. >>>=20 >>> Sorry for reheating this up, but no matter how many times I read = this >>> entire discussion, I still have no idea what the proper way of >>> implementing this is. Will there be modifications to RFC6020 text or = not? >>>=20 >>> I don't think that the current text supports option (3) the way Andy = and >>> Ladislav describe it at all. I don't like the "what's visible to >>> external modules" part when a module that consists of submodules is >>> imported in another module. The text for import statement says: >>>=20 >>> When a module is imported, the importing module may: >>> o use any grouping and typedef defined at the top level in the >>> imported module or*its submodules*. >>>=20 >>> o use any extension, feature, and identity defined in the = imported >>> module or*its submodules*. >>>=20 >>> o use any node in the imported module's schema tree in "must", >>> "path", and "when" statements, or as the target node in = "augment" >>> and "deviation" statements. >>>=20 >>> This seems to suggest that the importing module sees MORE than may = be >>> visible to the imported module which starts the submodule inclusion >>> chain. That is: the importing module sees both "X" typedefs, but the >>> including module only sees the string version --> instant ambiguity = upon >>> importing. Isn't this just utterly broken? (2) would at least detect = the >>> error, which is correct IMO. >>>=20 >>> The above text should say "in the imported module or *it's included >>> submodules*" for this to work as described by Andy and Ladislav (?). >>> Should be, since you decided that there are now two types of = submodules >>> - the ones included by the main module and the ones that are not - = and >>> this text refers to both of them (and any other type of submodule = you >>> can possibly think of, like dangling bugged ones - which aren't that >>> hard to create - think multiple submodule revisions because someone >>> forgot to clean up :D). >>>=20 >>> I think this text makes hiding top level definitions impossible = (except >>> schema trees defined in submodules not included by main module, but = why >>> would you want to hide that?). >>>=20 >>> Jernej >>>=20 >>>> Lada >>>>=20 >>>>>=20 >>>>> Lada >>>>>=20 >>>>>=20 >>>>> Andy >>>>>=20 >>>>>=20 >>>>>> In Yuma this would be a duplicate name error for 'X'. >>>>>> Is that correct or is leaf a an int32 and no problem? >>>>>> (Looks like a problem to me.) >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> /martin >>>>>>=20 >>>>>> Andy >>>>>>=20 >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Sat Mar 30 11:25:57 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD6F21F875C for ; Sat, 30 Mar 2013 11:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynAz7j92SRXv for ; Sat, 30 Mar 2013 11:25:57 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7D921F8758 for ; Sat, 30 Mar 2013 11:25:56 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id qd14so1389348ieb.14 for ; Sat, 30 Mar 2013 11:25:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=KfoFGyUI4YUmkQTwI18QvdY5DdzPzBMwE8aYGZ0hm/Q=; b=fNLOpUr7560Xn4TyaUcFdFi/L7ggFayTzZ19FLKhYyWW2K7Nnffrt1mhjnrrvc29yv M3WXztaZof4niV/PPAf6gwnx/2MN1qsYTpxV/GKlYJr1CTjWMhZICbXDDq7Sx+TmOLIv vwwrpfoD+CojnpAozEHznQqtNgUgjjgPmOz6yglWsVdufXSHeri41hvShAf1g4k2HSfg iaB5/qp3X/R6TykX1oSRN3EXPIp0cCZpq8640C9gvZeec603XdYnn/1E1lAv8dEsChIH oSt9G5aCUsPgADuBGsOtwdvNRCMtbuaMg1cUbItegaRrwW2ZG+dNuWzuaRbpijyN3T4V NKgQ== MIME-Version: 1.0 X-Received: by 10.50.153.198 with SMTP id vi6mr1241155igb.112.1364667956534; Sat, 30 Mar 2013 11:25:56 -0700 (PDT) Received: by 10.231.34.68 with HTTP; Sat, 30 Mar 2013 11:25:56 -0700 (PDT) In-Reply-To: References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> <5155B2A8.8050104@mg-soft.com> Date: Sat, 30 Mar 2013 11:25:56 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm8GYk8Nj2tKIoKb6dM2QOEzH/PtkwOTNooIxI/Cmi4yt+YxsrdZcx8WzWe2q50iXdkPYUi Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 18:25:58 -0000 On Sat, Mar 30, 2013 at 11:03 AM, Ladislav Lhotka wrote: > > On Mar 30, 2013, at 3:54 PM, Andy Bierman wrote: > >> On Sat, Mar 30, 2013 at 3:24 AM, Ladislav Lhotka wrote: >>> Hi, >>> >>> for the time being, an easy fix seems to be to require that all submodules be explicitly included from the main module. This may even qualify as an erratum. >>> >> >> I don't agree tat any fix is needed. >> I don't agree include-stmt and import-stmt are coupled in this way. > > Coupled? So what's your definition of "its submodules" that appears in several places, in particular sec. 7.1.5? > The "belongs-to" statement defines "its submodules": 7.1.6. The include Statement [para 1]..... Modules are only allowed to include submodules that belong to that module, as defined by the "belongs-to" statement (see Section 7.2.2). 7.2.2. The belongs-to Statement The "belongs-to" statement specifies the module to which the submodule belongs. The argument is an identifier that is the name of the module. There is only one XML namespace for the entire module. QNames within that namespace must be unique. There is no namespace per submodule in YANG. > Lada > Andy From lhotka@nic.cz Sun Mar 31 01:17:07 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBD021F8651 for ; Sun, 31 Mar 2013 01:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_05=-1.11, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nNnzwLK6jxu for ; Sun, 31 Mar 2013 01:17:06 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 051A621F8650 for ; Sun, 31 Mar 2013 01:17:05 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id EF92413FB60; Sun, 31 Mar 2013 10:17:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1364717824; bh=MAWZ/w7rlos3Rse9U6EOB6tWLyGdWzaTKObxp3gbzP0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=yCna+uZsBPb2yX98pyHLBNTlKLnRTCBWdN71ovjDRjUcYP/7kG9fklgCTGlV3acpo OgSfzUKpYy8gdLEIWtY/z391c2v/EYdcDdzK1tE+4Dw46R7PaePSP4q7L26EwALMio hnBD5WYt3xSxESt//zQRRThkxSSCasDoPISzH6vg= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: Date: Sun, 31 Mar 2013 10:17:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8A6EFB59-3B3D-45A9-B2E1-5CC7000716AD@nic.cz> References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> <5155B2A8.8050104@mg-soft.com> To: Andy Bierman X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 08:17:07 -0000 On Mar 30, 2013, at 7:25 PM, Andy Bierman wrote: > On Sat, Mar 30, 2013 at 11:03 AM, Ladislav Lhotka = wrote: >>=20 >> On Mar 30, 2013, at 3:54 PM, Andy Bierman wrote: >>=20 >>> On Sat, Mar 30, 2013 at 3:24 AM, Ladislav Lhotka = wrote: >>>> Hi, >>>>=20 >>>> for the time being, an easy fix seems to be to require that all = submodules be explicitly included from the main module. This may even = qualify as an erratum. >>>>=20 >>>=20 >>> I don't agree tat any fix is needed. >>> I don't agree include-stmt and import-stmt are coupled in this way. >>=20 >> Coupled? So what's your definition of "its submodules" that appears = in several places, in particular sec. 7.1.5? >>=20 >=20 > The "belongs-to" statement defines "its submodules": So somebody writes a submodule with=20 =20 belongs-to ietf-ip { prefix ip; } and it becomes a submodule of "ietf-ip" without ever being included = anywhere? This can't be, so something must be missing in this definition of "its = modules". Lada >=20 > 7.1.6. The include Statement >=20 > [para 1]..... Modules are only allowed to > include submodules that belong to that module, as defined by the > "belongs-to" statement (see Section 7.2.2). >=20 > 7.2.2. The belongs-to Statement >=20 > The "belongs-to" statement specifies the module to which the > submodule belongs. The argument is an identifier that is the name = of > the module. >=20 > There is only one XML namespace for the entire module. > QNames within that namespace must be unique. > There is no namespace per submodule in YANG. >=20 >> Lada >>=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Sun Mar 31 06:13:52 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EDE21F866E for ; Sun, 31 Mar 2013 06:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.245 X-Spam-Level: X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZiUElrdk+j2 for ; Sun, 31 Mar 2013 06:13:52 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5F24321F8651 for ; Sun, 31 Mar 2013 06:13:52 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id e14so1703805iej.30 for ; Sun, 31 Mar 2013 06:13:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=UvRMgVJbN/kpmXVIIc6yEvBXo69UBaQh9DdVz++2DbY=; b=Unqwf0B+YptdATLDLkiDMGKaeUEpEDCIR7juwCWSqMZmnKGwid6p1R3Yd8euF/QVMW 9YOQeUEATdp84CKdUrYDyZk2b7qqBNk9IeuvVWV+JFZ5y5yfI9proalqfRJwigugBebz hy6j+lwR8sdtHs4pgQpY57cT475MrgKw6wOG/a7urYV6SypzZXIa/1EExKLM8PLdZ5dC n4elGv4xEdMfdxYW5RLCjdtK1U/IrtXPbMRPmgVinawrM9lNQtvhtFSwZ27sDEdUWQm/ h9EasBtRuhDEmLCFYRbXWGEIXhbgLlNL50iaFKuAmfCSpjItRW9UJo57yo/mHsN8tfw7 o0xg== MIME-Version: 1.0 X-Received: by 10.50.219.168 with SMTP id pp8mr2122050igc.57.1364735631853; Sun, 31 Mar 2013 06:13:51 -0700 (PDT) Received: by 10.231.34.68 with HTTP; Sun, 31 Mar 2013 06:13:51 -0700 (PDT) In-Reply-To: <8A6EFB59-3B3D-45A9-B2E1-5CC7000716AD@nic.cz> References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> <5155B2A8.8050104@mg-soft.com> <8A6EFB59-3B3D-45A9-B2E1-5CC7000716AD@nic.cz> Date: Sun, 31 Mar 2013 06:13:51 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnANHyQPl65g22GzET8p9B5rh9xPuIuR+2z+10x/MM0NYPczT/1EJ2AwphtrEEOFstpb6Pq Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 13:13:53 -0000 On Sun, Mar 31, 2013 at 1:17 AM, Ladislav Lhotka wrote: > > On Mar 30, 2013, at 7:25 PM, Andy Bierman wrote: > >> On Sat, Mar 30, 2013 at 11:03 AM, Ladislav Lhotka wrote: >>> >>> On Mar 30, 2013, at 3:54 PM, Andy Bierman wrote: >>> >>>> On Sat, Mar 30, 2013 at 3:24 AM, Ladislav Lhotka wrote: >>>>> Hi, >>>>> >>>>> for the time being, an easy fix seems to be to require that all submodules be explicitly included from the main module. This may even qualify as an erratum. >>>>> >>>> >>>> I don't agree tat any fix is needed. >>>> I don't agree include-stmt and import-stmt are coupled in this way. >>> >>> Coupled? So what's your definition of "its submodules" that appears in several places, in particular sec. 7.1.5? >>> >> >> The "belongs-to" statement defines "its submodules": > > So somebody writes a submodule with > > belongs-to ietf-ip { prefix ip; } > > and it becomes a submodule of "ietf-ip" without ever being included anywhere? > > This can't be, so something must be missing in this definition of "its modules". The server supports and advertises a specific set of modules. The netconf-state schema list can identify the submodules. > > Lada > Andy >> 7.1.6. The include Statement >> >> [para 1]..... Modules are only allowed to >> include submodules that belong to that module, as defined by the >> "belongs-to" statement (see Section 7.2.2). >> >> 7.2.2. The belongs-to Statement >> >> The "belongs-to" statement specifies the module to which the >> submodule belongs. The argument is an identifier that is the name of >> the module. >> >> There is only one XML namespace for the entire module. >> QNames within that namespace must be unique. >> There is no namespace per submodule in YANG. >> >>> Lada >>> >> >> Andy > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From andy@yumaworks.com Sun Mar 31 06:31:00 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CC521F88B0 for ; Sun, 31 Mar 2013 06:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.259 X-Spam-Level: X-Spam-Status: No, score=-1.259 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxDBrBY8wMJL for ; Sun, 31 Mar 2013 06:30:59 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B702421F8895 for ; Sun, 31 Mar 2013 06:30:59 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id c11so1702840ieb.1 for ; Sun, 31 Mar 2013 06:30:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=lYNYGJmLT9Tti2VSoOnc/lWKglDuwybute2NdmmYHi8=; b=gz9fn1/sjkkGVPwQr6b8YQtClVa7zTFlIUgJwmlDAIQEiuLouAmqIlbGV+jcn7lT1O LcRuNycuOmZPB5xSE2qbW/xr3aUFlPxIKn6RrXJbNKpE8SHvIoYh7fNC3q1LXMMhTe+E XNbnpnlfSH437n6Owz5XBICGbZAaZKFzB4bjvYV0h50uXpNU9MbVAVG2irVsY+/g1sNa LAOsi9W2lRfMLcViiCj+M1PZ8wx7VgtYuOL/8IgQ12yph7KD0EskTWxA87xqAD6SKUgI o1n+cvFjUqBTIsKRRNymfe3r+7GSikmTnb28U5jclpdEkx8v6eGTqgRoQM5CQfMUYKoV CvdQ== MIME-Version: 1.0 X-Received: by 10.50.12.137 with SMTP id y9mr2216268igb.57.1364736658883; Sun, 31 Mar 2013 06:30:58 -0700 (PDT) Received: by 10.231.34.68 with HTTP; Sun, 31 Mar 2013 06:30:58 -0700 (PDT) In-Reply-To: <8A6EFB59-3B3D-45A9-B2E1-5CC7000716AD@nic.cz> References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> <5155B2A8.8050104@mg-soft.com> <8A6EFB59-3B3D-45A9-B2E1-5CC7000716AD@nic.cz> Date: Sun, 31 Mar 2013 06:30:58 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmYjWIfdGd8XROBkM+tEped3hCpa+yE/AFjVlSFAziGjPIpyZUQAUB37Bt1L1cNQwYU9xXQ Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 13:31:00 -0000 On Sun, Mar 31, 2013 at 1:17 AM, Ladislav Lhotka wrote: > > On Mar 30, 2013, at 7:25 PM, Andy Bierman wrote: > >> On Sat, Mar 30, 2013 at 11:03 AM, Ladislav Lhotka wrote: >>> >>> On Mar 30, 2013, at 3:54 PM, Andy Bierman wrote: >>> >>>> On Sat, Mar 30, 2013 at 3:24 AM, Ladislav Lhotka wrote: >>>>> Hi, >>>>> >>>>> for the time being, an easy fix seems to be to require that all submodules be explicitly included from the main module. This may even qualify as an erratum. >>>>> >>>> >>>> I don't agree tat any fix is needed. >>>> I don't agree include-stmt and import-stmt are coupled in this way. >>> >>> Coupled? So what's your definition of "its submodules" that appears in several places, in particular sec. 7.1.5? >>> >> >> The "belongs-to" statement defines "its submodules": > > So somebody writes a submodule with > > belongs-to ietf-ip { prefix ip; } > > and it becomes a submodule of "ietf-ip" without ever being included anywhere? > > This can't be, so something must be missing in this definition of "its modules". > You seem to keep ignoring the fact that a module has 1 namespace and there cannot be multiple symbols resolving to the same QName. I can't find any text that says a single module revision can export multiple versions of the same QName to another module. The include-stmt just says how to resolve prefixes within the module that is being parsed. The import-stmt says how to resolve prefixes from other modules. > Lada > Andy >> >> 7.1.6. The include Statement >> >> [para 1]..... Modules are only allowed to >> include submodules that belong to that module, as defined by the >> "belongs-to" statement (see Section 7.2.2). >> >> 7.2.2. The belongs-to Statement >> >> The "belongs-to" statement specifies the module to which the >> submodule belongs. The argument is an identifier that is the name of >> the module. >> >> There is only one XML namespace for the entire module. >> QNames within that namespace must be unique. >> There is no namespace per submodule in YANG. >> >>> Lada >>> >> >> Andy > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From lhotka@nic.cz Sun Mar 31 10:17:00 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FE221F85C4 for ; Sun, 31 Mar 2013 10:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.244 X-Spam-Level: X-Spam-Status: No, score=-1.244 tagged_above=-999 required=5 tests=[AWL=0.755, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6sfWOTT1PTE for ; Sun, 31 Mar 2013 10:16:57 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1871121F85A1 for ; Sun, 31 Mar 2013 10:16:50 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id DDFAD13FB60; Sun, 31 Mar 2013 19:16:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1364750208; bh=ftTVQoGjDzVl0vAPwS293TyHqFbnh3P8c/3VxWEIObE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Qhs2xV5AmKBCkBMbl6rnXKaPcrA/19fQ6RazBOZe2zL/OpiQpC58e41VBTK/OY0nv uV9zjPS4XS3YrvVooosSzEVzFPbmHA7Cb7jDQ5PUflMzIIV3hxZz+mmYOC6y4sITg6 Kedd3WLrqoC0g5eICeJxeL+YsFSnF4khJGcO1ig4= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: Date: Sun, 31 Mar 2013 19:16:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> <5155B2A8.8050104@mg-soft.com> <8A6EFB59-3B3D-45A9-B2E1-5CC7000716AD@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 17:17:00 -0000 On Mar 31, 2013, at 3:13 PM, Andy Bierman wrote: > On Sun, Mar 31, 2013 at 1:17 AM, Ladislav Lhotka = wrote: >>=20 >> On Mar 30, 2013, at 7:25 PM, Andy Bierman wrote: >>=20 >>> On Sat, Mar 30, 2013 at 11:03 AM, Ladislav Lhotka = wrote: >>>>=20 >>>> On Mar 30, 2013, at 3:54 PM, Andy Bierman = wrote: >>>>=20 >>>>> On Sat, Mar 30, 2013 at 3:24 AM, Ladislav Lhotka = wrote: >>>>>> Hi, >>>>>>=20 >>>>>> for the time being, an easy fix seems to be to require that all = submodules be explicitly included from the main module. This may even = qualify as an erratum. >>>>>>=20 >>>>>=20 >>>>> I don't agree tat any fix is needed. >>>>> I don't agree include-stmt and import-stmt are coupled in this = way. >>>>=20 >>>> Coupled? So what's your definition of "its submodules" that appears = in several places, in particular sec. 7.1.5? >>>>=20 >>>=20 >>> The "belongs-to" statement defines "its submodules": >>=20 >> So somebody writes a submodule with >>=20 >> belongs-to ietf-ip { prefix ip; } >>=20 >> and it becomes a submodule of "ietf-ip" without ever being included = anywhere? >>=20 >> This can't be, so something must be missing in this definition of = "its modules". >=20 > The server supports and advertises a specific set of modules. > The netconf-state schema list can identify the submodules. Huh, are you saying that YANG-based models cannot be used without = supporting ietf-netconf-monitoring? Lada >=20 >>=20 >> Lada >>=20 >=20 >=20 > Andy >=20 >=20 >>> 7.1.6. The include Statement >>>=20 >>> [para 1]..... Modules are only allowed to >>> include submodules that belong to that module, as defined by the >>> "belongs-to" statement (see Section 7.2.2). >>>=20 >>> 7.2.2. The belongs-to Statement >>>=20 >>> The "belongs-to" statement specifies the module to which the >>> submodule belongs. The argument is an identifier that is the name = of >>> the module. >>>=20 >>> There is only one XML namespace for the entire module. >>> QNames within that namespace must be unique. >>> There is no namespace per submodule in YANG. >>>=20 >>>> Lada >>>>=20 >>>=20 >>> Andy >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Sun Mar 31 10:38:54 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62D421F8525 for ; Sun, 31 Mar 2013 10:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.352 X-Spam-Level: X-Spam-Status: No, score=-1.352 tagged_above=-999 required=5 tests=[AWL=0.647, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 578GAmAsZbfc for ; Sun, 31 Mar 2013 10:38:54 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B6F6321F8517 for ; Sun, 31 Mar 2013 10:38:53 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 009B613FB60; Sun, 31 Mar 2013 19:38:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1364751533; bh=yRky7MLPibtPFTrzXECRCcTX+KHF21l6hSqH1YKcvYQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pGynDOglNVKnDwkxW+eLST5WdGSi2G+u6xlfTtwVcylrA8ULlLJsK7G1l5P25J7ga +4a42hihS0oVm+adBnvdE8oP8LAZnnOv1TC6OzQL9eQgc6rAjjrKCl1aQ292Y0AofX hQve9tGUq29Tzkazy5fQqHF0fNryZ50pjZKNSHf0= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: Date: Sun, 31 Mar 2013 19:38:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> <5155B2A8.8050104@mg-soft.com> <8A6EFB59-3B3D-45A9-B2E1-5CC7000716AD@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 17:38:54 -0000 On Mar 31, 2013, at 3:30 PM, Andy Bierman wrote: > On Sun, Mar 31, 2013 at 1:17 AM, Ladislav Lhotka = wrote: >>=20 >> On Mar 30, 2013, at 7:25 PM, Andy Bierman wrote: >>=20 >>> On Sat, Mar 30, 2013 at 11:03 AM, Ladislav Lhotka = wrote: >>>>=20 >>>> On Mar 30, 2013, at 3:54 PM, Andy Bierman = wrote: >>>>=20 >>>>> On Sat, Mar 30, 2013 at 3:24 AM, Ladislav Lhotka = wrote: >>>>>> Hi, >>>>>>=20 >>>>>> for the time being, an easy fix seems to be to require that all = submodules be explicitly included from the main module. This may even = qualify as an erratum. >>>>>>=20 >>>>>=20 >>>>> I don't agree tat any fix is needed. >>>>> I don't agree include-stmt and import-stmt are coupled in this = way. >>>>=20 >>>> Coupled? So what's your definition of "its submodules" that appears = in several places, in particular sec. 7.1.5? >>>>=20 >>>=20 >>> The "belongs-to" statement defines "its submodules": >>=20 >> So somebody writes a submodule with >>=20 >> belongs-to ietf-ip { prefix ip; } >>=20 >> and it becomes a submodule of "ietf-ip" without ever being included = anywhere? >>=20 >> This can't be, so something must be missing in this definition of = "its modules". >>=20 >=20 > You seem to keep ignoring the fact that a module has 1 namespace > and there cannot be multiple symbols resolving to the same QName. > I can't find any text that says a single module revision can export > multiple versions > of the same QName to another module. It is not about namespaces or QNames, just about figuring out the = (complete) schema, because submodules may contribute to it. I strongly = disagree with involving netconf-state schema, the client must be able to = learn the schema from hello and the text of YANG modules and submodules = it already has. For one, how could the client learn whether there are = any submodules of ietf-netconf-monitoring? Lada >=20 > The include-stmt just says how to resolve prefixes within the module > that is being parsed. The import-stmt says how to resolve prefixes > from other modules. >=20 >=20 >> Lada >>=20 >=20 > Andy >=20 >=20 >>>=20 >>> 7.1.6. The include Statement >>>=20 >>> [para 1]..... Modules are only allowed to >>> include submodules that belong to that module, as defined by the >>> "belongs-to" statement (see Section 7.2.2). >>>=20 >>> 7.2.2. The belongs-to Statement >>>=20 >>> The "belongs-to" statement specifies the module to which the >>> submodule belongs. The argument is an identifier that is the name = of >>> the module. >>>=20 >>> There is only one XML namespace for the entire module. >>> QNames within that namespace must be unique. >>> There is no namespace per submodule in YANG. >>>=20 >>>> Lada >>>>=20 >>>=20 >>> Andy >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Sun Mar 31 10:43:20 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B0D21F84E3 for ; Sun, 31 Mar 2013 10:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.269 X-Spam-Level: X-Spam-Status: No, score=-1.269 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGziFEcYigye for ; Sun, 31 Mar 2013 10:43:19 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3C50021F84B0 for ; Sun, 31 Mar 2013 10:43:18 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id 17so1745058iea.40 for ; Sun, 31 Mar 2013 10:43:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=JjtC29iEPIBEx8xsiRh5/VX5mW3LJKvhIg2an96+NEs=; b=osBXS1RonVKO/uN7qpVGRDoY7aBRZkuIl883MMmHQP/YN8dRTKcXBDFTuNWse09AwF RpXvL9YNrfnwXi2LyhYdmvpM+BuDkH1XRoiLd5F5XfiUaXyquPsV+YT10eo93e97GTBo Ndq3Z93fBDJAl+1/T8PavSQwY3Yw2MgyB5WzFl4sPJV3eAfvbWEiU1uRxpwBtr9W8IUF IvvH/LAqrfBorCT3MxPPNVNvHM1ryIvrLQp2O6YlXFxyTOfJMSf/t4Vq1YGn497HTsZc gmE8xHLqZzM1XUmeTz90HZKvue0DLSWnVf3SLl+okI2hyck12HC+fRU7XFnp0xMJrkaI aXAA== MIME-Version: 1.0 X-Received: by 10.50.12.137 with SMTP id y9mr2430767igb.57.1364751798359; Sun, 31 Mar 2013 10:43:18 -0700 (PDT) Received: by 10.231.34.68 with HTTP; Sun, 31 Mar 2013 10:43:18 -0700 (PDT) In-Reply-To: References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> <5155B2A8.8050104@mg-soft.com> <8A6EFB59-3B3D-45A9-B2E1-5CC7000716AD@nic.cz> Date: Sun, 31 Mar 2013 10:43:18 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlwFXDnP5k8K08Od6R8LP6oH+fX19VwqEaRX4eG73pEPL+/F+iU78D9QYjzaheFIQfDVnOF Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 17:43:20 -0000 On Sun, Mar 31, 2013 at 10:16 AM, Ladislav Lhotka wrote: > > On Mar 31, 2013, at 3:13 PM, Andy Bierman wrote: > >> On Sun, Mar 31, 2013 at 1:17 AM, Ladislav Lhotka wrote: >>> >>> On Mar 30, 2013, at 7:25 PM, Andy Bierman wrote: >>> >>>> On Sat, Mar 30, 2013 at 11:03 AM, Ladislav Lhotka wrote: >>>>> >>>>> On Mar 30, 2013, at 3:54 PM, Andy Bierman wrote: >>>>> >>>>>> On Sat, Mar 30, 2013 at 3:24 AM, Ladislav Lhotka wrote: >>>>>>> Hi, >>>>>>> >>>>>>> for the time being, an easy fix seems to be to require that all submodules be explicitly included from the main module. This may even qualify as an erratum. >>>>>>> >>>>>> >>>>>> I don't agree tat any fix is needed. >>>>>> I don't agree include-stmt and import-stmt are coupled in this way. >>>>> >>>>> Coupled? So what's your definition of "its submodules" that appears in several places, in particular sec. 7.1.5? >>>>> >>>> >>>> The "belongs-to" statement defines "its submodules": >>> >>> So somebody writes a submodule with >>> >>> belongs-to ietf-ip { prefix ip; } >>> >>> and it becomes a submodule of "ietf-ip" without ever being included anywhere? >>> >>> This can't be, so something must be missing in this definition of "its modules". >> >> The server supports and advertises a specific set of modules. >> The netconf-state schema list can identify the submodules. > > Huh, are you saying that YANG-based models cannot be used without supporting ietf-netconf-monitoring? > Any protocol that uses YANG has to let each peer know the YANG module implementation details of the other peer in order to automatically derive the exact set of YANG files used. There is only 1 module namespace exported to other modules. Consider this simple example that shows why: module A { ... import B { prefix b; } augment /b:top { leaf a { type b:b-type; } } } module B { include B1; include B2; } module B1 { belongs-to B { prefix b; } include B1-1; } module B1-1 { belongs-to B { prefix b; } list top { key i; leaf i { type int8; } } typedef b-type { type string; } } module B2 { belongs-to B { prefix b; } include B2-1; } module B2-1 { belongs-to B { prefix b; } container top; typedef b-type { type int32; } } Is this legal YANG according to your interpretation? IMO, no because this would cause duplicate QNames in the module B namespace. Nothing in the syntax in module A violates any text related to importing symbols. So which object is 'top'? A container or a list? Which type is 'b-type'? A string or an int32? IMO the correct "bug fix" is to clarify that top-level symbols in the same namespace (typedefs, groupings, nodes, etc.) MUST NOT be defined more than once in any module, even if submodules are used. > Lada > Andy >> >>> >>> Lada >>> >> >> >> Andy >> >> >>>> 7.1.6. The include Statement >>>> >>>> [para 1]..... Modules are only allowed to >>>> include submodules that belong to that module, as defined by the >>>> "belongs-to" statement (see Section 7.2.2). >>>> >>>> 7.2.2. The belongs-to Statement >>>> >>>> The "belongs-to" statement specifies the module to which the >>>> submodule belongs. The argument is an identifier that is the name of >>>> the module. >>>> >>>> There is only one XML namespace for the entire module. >>>> QNames within that namespace must be unique. >>>> There is no namespace per submodule in YANG. >>>> >>>>> Lada >>>>> >>>> >>>> Andy >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From andy@yumaworks.com Sun Mar 31 11:08:52 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC16721F87B9 for ; Sun, 31 Mar 2013 11:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kw2wOm+NHWb0 for ; Sun, 31 Mar 2013 11:08:52 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id F0BEA21F8788 for ; Sun, 31 Mar 2013 11:08:51 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id e14so1799214iej.2 for ; Sun, 31 Mar 2013 11:08:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=ru46/r7e1i2jYjlLkW+hg8lZ+tfxNvNp/akRZYID9f0=; b=XsTN76smhKAN8xurF0jMFtZGa+OOixQVwOvVVvezIfSh3AOiX89AaIrcENJ7dBKYts jT3+Nsaj9ZbWO9Cl+hxayPAiYPhjfXdyqNHRz7q1k74BJavHGVtEsmgyFx07xz/E1wgB 5R4HObjQCVpKrYIdehn55gG+BozIgVBlpeXudvwUEHANC6GQLEYV+Jf3s181UprjXFd0 jaF5wR70UaiqnjyLkyGf2/N2HFIqa1IR9Gl3VT/fcsBzqBGN3Z4Yziy7/dSGQEc4BXEi mpRZZfl16oK5f/LFlezrffsa9J/duCsUKz3uB7kUq98KR6US4DPhA6ePGKahRnDpaEuc glEQ== MIME-Version: 1.0 X-Received: by 10.50.78.202 with SMTP id d10mr2416824igx.69.1364753331583; Sun, 31 Mar 2013 11:08:51 -0700 (PDT) Received: by 10.231.34.68 with HTTP; Sun, 31 Mar 2013 11:08:51 -0700 (PDT) In-Reply-To: References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> <5155B2A8.8050104@mg-soft.com> <8A6EFB59-3B3D-45A9-B2E1-5CC7000716AD@nic.cz> Date: Sun, 31 Mar 2013 11:08:51 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkxVbtwIB8s2rUUGVoW50mqaxk0ktRk9uFs3xfe/QnODzQf0KbTMNJpgQtAu+7xjmcfwsUt Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 18:08:52 -0000 On Sun, Mar 31, 2013 at 10:38 AM, Ladislav Lhotka wrote: > > On Mar 31, 2013, at 3:30 PM, Andy Bierman wrote: > >> On Sun, Mar 31, 2013 at 1:17 AM, Ladislav Lhotka wrote: >>> >>> On Mar 30, 2013, at 7:25 PM, Andy Bierman wrote: >>> >>>> On Sat, Mar 30, 2013 at 11:03 AM, Ladislav Lhotka wrot= e: >>>>> >>>>> On Mar 30, 2013, at 3:54 PM, Andy Bierman wrote: >>>>> >>>>>> On Sat, Mar 30, 2013 at 3:24 AM, Ladislav Lhotka wro= te: >>>>>>> Hi, >>>>>>> >>>>>>> for the time being, an easy fix seems to be to require that all sub= modules be explicitly included from the main module. This may even qualify = as an erratum. >>>>>>> >>>>>> >>>>>> I don't agree tat any fix is needed. >>>>>> I don't agree include-stmt and import-stmt are coupled in this way. >>>>> >>>>> Coupled? So what's your definition of "its submodules" that appears i= n several places, in particular sec. 7.1.5? >>>>> >>>> >>>> The "belongs-to" statement defines "its submodules": >>> >>> So somebody writes a submodule with >>> >>> belongs-to ietf-ip { prefix ip; } >>> >>> and it becomes a submodule of "ietf-ip" without ever being included any= where? >>> >>> This can't be, so something must be missing in this definition of "its = modules". >>> >> >> You seem to keep ignoring the fact that a module has 1 namespace >> and there cannot be multiple symbols resolving to the same QName. >> I can't find any text that says a single module revision can export >> multiple versions >> of the same QName to another module. > > It is not about namespaces or QNames, just about figuring out the (comple= te) schema, because submodules may contribute to it. I strongly disagree wi= th involving netconf-state schema, the client must be able to learn the sch= ema from hello and the text of YANG modules and submodules it already has. = For one, how could the client learn whether there are any submodules of iet= f-netconf-monitoring? > The fact is, you cannot rely the information in the YANG modules to determine the set of files that were used to construct the schema tree in use by the server. 1) module namspaces are assumed to be globally unique, not module names. Import "foo" does not reliably identify anything. The URI for the YANG module is needed to map namespace to module-name. 2) Since submodules are not advertised as YANG module capabilities, the cannot be used to map sub-module names to the namespace-stmt value. 3) Since import-by-revision and include-by-revision are optional to use, the import or include statements cannot be used to reliably determine which revision of the specified module or submodule to use. The URI can usually be used to resolve import, but nothing except the 'schema' list contains this information for submodu= les. (Making them mandatory to use would illuminate how fragile they are.) > Lada > Andy > >> >> The include-stmt just says how to resolve prefixes within the module >> that is being parsed. The import-stmt says how to resolve prefixes >> from other modules. >> >> >>> Lada >>> >> >> Andy >> >> >>>> >>>> 7.1.6. The include Statement >>>> >>>> [para 1]..... Modules are only allowed to >>>> include submodules that belong to that module, as defined by the >>>> "belongs-to" statement (see Section 7.2.2). >>>> >>>> 7.2.2. The belongs-to Statement >>>> >>>> The "belongs-to" statement specifies the module to which the >>>> submodule belongs. The argument is an identifier that is the name of >>>> the module. >>>> >>>> There is only one XML namespace for the entire module. >>>> QNames within that namespace must be unique. >>>> There is no namespace per submodule in YANG. >>>> >>>>> Lada >>>>> >>>> >>>> Andy >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > >