From j.schoenwaelder@jacobs-university.de Sun Apr 1 07:07:40 2012 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 DB46311E8083 for ; Sun, 1 Apr 2012 07:07:40 -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 InWfMiTzNGsd for ; Sun, 1 Apr 2012 07:07:40 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3B81911E8081 for ; Sun, 1 Apr 2012 07:07:37 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24D4620C32; Sun, 1 Apr 2012 16:07:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BLl0mUZ9Oq3R; Sun, 1 Apr 2012 16:07:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B217220C2F; Sun, 1 Apr 2012 16:07:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6F4C11E27EFF; Sun, 1 Apr 2012 16:07:35 +0200 (CEST) Date: Sun, 1 Apr 2012 16:07:34 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120401140734.GA72707@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] draft ietf 83 meeting minutes 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, 01 Apr 2012 14:07:41 -0000 Hi, I just uploaded a draft of the Paris meeting minutes: http://www.ietf.org/proceedings/83/minutes/minutes-83-netmod.txt Please send any corrections to me or this list. /js -- 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 Mon Apr 2 04:33:50 2012 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 F0BA221F8948 for ; Mon, 2 Apr 2012 04:33: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 gTb4-f1Zm+e7 for ; Mon, 2 Apr 2012 04:33:48 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA4921F8945 for ; Mon, 2 Apr 2012 04:33:48 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 21C5D13F7B8 for ; Mon, 2 Apr 2012 13:33:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1333366427; bh=4XZ/rhpMUrWbeZIY92n02N4GaxS3GjQi6/O53whbemk=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=uzWTUIw9jyEi1CEZx11GrDO9jv8qMB9kGrjqRqiOSaOHQVkFPcGyEyHEKSsaJ07Hf KlT4NcCTbn+mT5C6qQQ1DTv06F7UXKzuMioQOVvVkB28IoC31vsPqQ0bKOi7CXqI/H IiQKyy/O//P28TDEoeFkS1SPG/lBg5fwo8rUjZvc= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Apr 2012 13:33:46 +0200 References: <20120402111722.9761.30651.idtracker@ietfa.amsl.com> To: netmod@ietf.org Message-Id: <5129457E-B660-4956-B773-8D001EBE45C9@nic.cz> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [netmod] Fwd: New Version Notification for draft-lhotka-yang-json-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, 02 Apr 2012 11:33:50 -0000 Hi, this I-D is a consequence of the RESTafarian discussion during the side = meeting in Paris. It essentially allows for mapping YANG data models to = JSON text instead of XML - with limitations, of course. Comments are welcome. Lada=20 Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-lhotka-yang-json-00.txt > Date: April 2, 2012 1:17:22 PM GMT+02:00 > To: lhotka@nic.cz >=20 > A new version of I-D, draft-lhotka-yang-json-00.txt has been = successfully submitted by Ladislav Lhotka and posted to the IETF = repository. >=20 > Filename: draft-lhotka-yang-json > Revision: 00 > Title: Modeling JSON Text with YANG > Creation date: 2012-04-02 > WG ID: Individual Submission > Number of pages: 12 >=20 > Abstract: > This document defines rules for mapping data models expressed in = YANG > to JSON text. It does so by specifying a procedure for translating > the subset of YANG-compatible XML documents to JSON text, and vice > versa. >=20 >=20 >=20 >=20 > The IETF Secretariat -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Apr 2 07:13:37 2012 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 7617821F858A for ; Mon, 2 Apr 2012 07:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCjY4Omv6Mva for ; Mon, 2 Apr 2012 07:13:37 -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 EEF1621F8565 for ; Mon, 2 Apr 2012 07:13:35 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id CD52F1200D50; Mon, 2 Apr 2012 16:13:33 +0200 (CEST) Date: Mon, 02 Apr 2012 16:13:33 +0200 (CEST) Message-Id: <20120402.161333.1154244105910951530.mbj@tail-f.com> To: netmod@ietf.org, bclaise@cisco.com From: Martin Bjorklund X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] Problem in draft-ietf-netmod-smi-yang-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, 02 Apr 2012 14:13:37 -0000 Hi, I just discovered a problem with draft-ietf-netmod-smi-yang-04. I believe this document has been sent to the IESG. The document specifies how to translate an OCTET STRING w/ DISPLAY-HINT to a YANG 'string'. But look at this example: InetAddressIPv4 ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d" STATUS current DESCRIPTION "Represents an IPv4 network address: Octets Contents Encoding 1-4 IPv4 address network-byte order The corresponding InetAddressType value is ipv4(1). This textual convention SHOULD NOT be used directly in object definitions, as it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair." SYNTAX OCTET STRING (SIZE (4)) becomes: typedef InetAddressIPv4 { type string { length "4"; ... } ... } But the length of an ipv4 address is not 4 characters!! Conclusion: if the type is octet string, and it has a display-hint, we must not translate the length restriction to yang. /martin From j.schoenwaelder@jacobs-university.de Mon Apr 2 07:32:47 2012 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 3FCEF21F8575 for ; Mon, 2 Apr 2012 07:32: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 obuKn5uTsFsF for ; Mon, 2 Apr 2012 07:32: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 5F86221F857D for ; Mon, 2 Apr 2012 07:32:46 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C55220BE4; Mon, 2 Apr 2012 16:32:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Ik3zJqS9FXHX; Mon, 2 Apr 2012 16:32:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D7D620BE0; Mon, 2 Apr 2012 16:32:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 19F5C1E2C0FB; Mon, 2 Apr 2012 16:32:43 +0200 (CEST) Date: Mon, 2 Apr 2012 16:32:43 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120402143243.GA5497@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org, bclaise@cisco.com References: <20120402.161333.1154244105910951530.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120402.161333.1154244105910951530.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Problem in draft-ietf-netmod-smi-yang-04 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, 02 Apr 2012 14:32:47 -0000 On Mon, Apr 02, 2012 at 04:13:33PM +0200, Martin Bjorklund wrote: > Hi, > > I just discovered a problem with draft-ietf-netmod-smi-yang-04. I > believe this document has been sent to the IESG. [...] > Conclusion: if the type is octet string, and it has a display-hint, we > must not translate the length restriction to yang. I agree that this needs clarification. However, I like to see text that says in some wording (to be determined) "must not translate to incorrect length restrictions". For certain frequently occuring display hint / size restriction patterns, e.g. DISPLAY-HINT "255a" ... SYNTAX OCTET STRING (SIZE (0..255)) a valid length statement can easily be generated. There are cases that require a bit more thinking to derive valid lower and upper bounds. I think we should not forbit implementations to be smart here, just not require 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 mbj@tail-f.com Mon Apr 2 07:38:51 2012 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 79D7321F85B8 for ; Mon, 2 Apr 2012 07:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63sEREFFzTnx for ; Mon, 2 Apr 2012 07:38:51 -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 EAED921F85B7 for ; Mon, 2 Apr 2012 07:38:50 -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 3A1731200D04; Mon, 2 Apr 2012 16:38:50 +0200 (CEST) Date: Mon, 02 Apr 2012 16:38:49 +0200 (CEST) Message-Id: <20120402.163849.2240107493146844082.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120402143243.GA5497@elstar.local> References: <20120402.161333.1154244105910951530.mbj@tail-f.com> <20120402143243.GA5497@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] Problem in draft-ietf-netmod-smi-yang-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, 02 Apr 2012 14:38:51 -0000 Juergen Schoenwaelder wrote: > On Mon, Apr 02, 2012 at 04:13:33PM +0200, Martin Bjorklund wrote: > > Hi, > > > > I just discovered a problem with draft-ietf-netmod-smi-yang-04. I > > believe this document has been sent to the IESG. > > [...] > > > Conclusion: if the type is octet string, and it has a display-hint, we > > must not translate the length restriction to yang. > > I agree that this needs clarification. However, I like to see text > that says in some wording (to be determined) "must not translate to > incorrect length restrictions". For certain frequently occuring > display hint / size restriction patterns, e.g. > > DISPLAY-HINT "255a" > ... > SYNTAX OCTET STRING (SIZE (0..255)) > > a valid length statement can easily be generated. There are cases that > require a bit more thinking to derive valid lower and upper bounds. I > think we should not forbit implementations to be smart here, just not > require it. This is fine with me. /martin From j.schoenwaelder@jacobs-university.de Mon Apr 2 07:56:58 2012 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 E82FF21F850B for ; Mon, 2 Apr 2012 07:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.650, 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 ubztrvx+siZ2 for ; Mon, 2 Apr 2012 07:56:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2849221F84F4 for ; Mon, 2 Apr 2012 07:56:57 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4CF0520C24; Mon, 2 Apr 2012 16:56:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PKorEuEe3iZB; Mon, 2 Apr 2012 16:56:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E5F9320C05; Mon, 2 Apr 2012 16:56:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4FC581E2C384; Mon, 2 Apr 2012 16:56:56 +0200 (CEST) Date: Mon, 2 Apr 2012 16:56:55 +0200 From: Juergen Schoenwaelder To: "Lange, Jeffrey K (GE Energy)" Message-ID: <20120402145655.GB9996@elstar.local> Mail-Followup-To: "Lange, Jeffrey K (GE Energy)" , netmod@ietf.org References: <20120330102706.GA65422@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) Cc: netmod@ietf.org Subject: Re: [netmod] common yang data types - 6021bis 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, 02 Apr 2012 14:56:59 -0000 On Fri, Mar 30, 2012 at 09:45:49AM -0400, Lange, Jeffrey K (GE Energy) wrote: > This isn't directly related to 6021 data types, more of an addition > to the ietf-inet-types , however one datatype that I found myself > implementing that would be nice to have as a standard type would be > a ip/prefix type that isn't limited to just specifying the prefix, > There is currently the ipv4-prefix and ipv6-prefix which has the > exact syntax that I'm looking for however the stipulation that all > lower bits past the prefix length means that I have to define my own > data type to allow someone to apply an IP address using the notation > "dead:beef::1/64" Just to be sure I understand you correctly: You propose to have two additional typedefs defined that take and ip address plus a prefix, say ipv4-address-with-prefix / ipv6-address-with-prefix. 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 jeffrey.K.lange@ge.com Mon Apr 2 10:14:23 2012 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 0A77C21F8664 for ; Mon, 2 Apr 2012 10:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwr2WkdHKyG0 for ; Mon, 2 Apr 2012 10:14:21 -0700 (PDT) Received: from exprod5og105.obsmtp.com (exprod5og105.obsmtp.com [64.18.0.180]) by ietfa.amsl.com (Postfix) with ESMTP id 2872E21F865C for ; Mon, 2 Apr 2012 10:14:20 -0700 (PDT) Received: from cinmlip11.e2k.ad.ge.com ([12.71.149.1]) (using TLSv1) by exprod5ob105.postini.com ([64.18.4.12]) with SMTP ID DSNKT3nebJQJUNvo8/uNPjWScjQ61GTbHNvZ@postini.com; Mon, 02 Apr 2012 10:14:21 PDT Received: from unknown (HELO cinmlef12.e2k.ad.ge.com) ([3.159.213.59]) by cinmlip11.e2k.ad.ge.com with ESMTP; 02 Apr 2012 13:14:19 -0400 Received: from LOUMLVEM02.e2k.ad.ge.com ([3.159.160.35]) by cinmlef12.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 13:14:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Apr 2012 13:14:17 -0400 Message-ID: In-Reply-To: <20120402145655.GB9996@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] common yang data types - 6021bis thread-index: Ac0Q4N9DGgcD2X9IQluQz6F/G7miUwADgoKw References: <20120330102706.GA65422@elstar.local> <20120402145655.GB9996@elstar.local> From: "Lange, Jeffrey K (GE Energy)" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 02 Apr 2012 17:14:18.0968 (UTC) FILETIME=[0A038580:01CD10F4] Cc: netmod@ietf.org Subject: Re: [netmod] common yang data types - 6021bis 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, 02 Apr 2012 17:14:23 -0000 Yes, that is correct.. and just to be clear, the string pattern would = be exactly the same as ipv4-prefix and ipv6-prefix, it becomes more of a = semantic difference. Ipv6-prefix: dead:beef::0/64 //OK dead:beef::1/64 //BAD ipv6-address-with-prefix: dead:beef::0/64 //OK dead:beef::1/64 //OK I guess another way to look at it is to loosen up the wording on the = ipv6-prefix/ipv4-prefix types to remove the requirement that the bits = past the prefix length must be zero so that the same type can be used in = different scenarios. Jeff Lange Lead Software Engineer GE Digital Energy - MDS =A0 T:=A0+1 585 242 8375 F: +1 585 241 5590 E:=A0Jeffrey.K.Lange@ge.com=20 www.GEDigitalEnergy.com =A0 175 Science Parkway Rochester, NY, 14620, USA -----Original Message----- From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, April 02, 2012 10:57 AM To: Lange, Jeffrey K (GE Energy) Cc: netmod@ietf.org Subject: Re: [netmod] common yang data types - 6021bis On Fri, Mar 30, 2012 at 09:45:49AM -0400, Lange, Jeffrey K (GE Energy) = wrote: > This isn't directly related to 6021 data types, more of an addition to = > the ietf-inet-types , however one datatype that I found myself=20 > implementing that would be nice to have as a standard type would be a=20 > ip/prefix type that isn't limited to just specifying the prefix, There = > is currently the ipv4-prefix and ipv6-prefix which has the exact=20 > syntax that I'm looking for however the stipulation that all lower=20 > bits past the prefix length means that I have to define my own data=20 > type to allow someone to apply an IP address using the notation=20 > "dead:beef::1/64" Just to be sure I understand you correctly: You propose to have two = additional typedefs defined that take and ip address plus a prefix, say = ipv4-address-with-prefix / ipv6-address-with-prefix. Correct? /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 Mon Apr 2 10:22:36 2012 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 BD40021F8518 for ; Mon, 2 Apr 2012 10:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.816 X-Spam-Level: X-Spam-Status: No, score=-102.816 tagged_above=-999 required=5 tests=[AWL=0.433, 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 a6yw6UGsGO5d for ; Mon, 2 Apr 2012 10:22:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 01B1121F850F for ; Mon, 2 Apr 2012 10:22:36 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F9CE20C2A; Mon, 2 Apr 2012 19:22:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SDoguwp0wBbc; Mon, 2 Apr 2012 19:22:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F93220C07; Mon, 2 Apr 2012 19:22:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 488371E2C5FF; Mon, 2 Apr 2012 19:22:34 +0200 (CEST) Date: Mon, 2 Apr 2012 19:22:34 +0200 From: Juergen Schoenwaelder To: "Lange, Jeffrey K (GE Energy)" Message-ID: <20120402172234.GA10708@elstar.local> Mail-Followup-To: "Lange, Jeffrey K (GE Energy)" , netmod@ietf.org References: <20120330102706.GA65422@elstar.local> <20120402145655.GB9996@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) Cc: netmod@ietf.org Subject: Re: [netmod] common yang data types - 6021bis 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, 02 Apr 2012 17:22:36 -0000 On Mon, Apr 02, 2012 at 01:14:17PM -0400, Lange, Jeffrey K (GE Energy) wrote: > Yes, that is correct.. and just to be clear, the string pattern would be exactly the same as ipv4-prefix and ipv6-prefix, it becomes more of a semantic difference. > > Ipv6-prefix: > dead:beef::0/64 //OK > dead:beef::1/64 //BAD > > ipv6-address-with-prefix: > dead:beef::0/64 //OK > dead:beef::1/64 //OK > > I guess another way to look at it is to loosen up the wording on the ipv6-prefix/ipv4-prefix types to remove the requirement that the bits past the prefix length must be zero so that the same type can be used in different scenarios. Well, changing a published definition usually is not such a good idea. If ipv*-prefix is used to denote a prefix, then the lower bits do not matter and we tend to pay attention to normalized representations. /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@netconfcentral.org Tue Apr 3 04:03:38 2012 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 EF79121F85B5 for ; Tue, 3 Apr 2012 04:03:38 -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 4dF8UHKjRw4w for ; Tue, 3 Apr 2012 04:03:38 -0700 (PDT) Received: from smtpauth23.prod.mesa1.secureserver.net (smtpauth23.prod.mesa1.secureserver.net [64.202.165.47]) by ietfa.amsl.com (Postfix) with SMTP id 797D721F8570 for ; Tue, 3 Apr 2012 04:03:38 -0700 (PDT) Received: (qmail 18645 invoked from network); 3 Apr 2012 11:03:37 -0000 Received: from unknown (75.84.164.152) by smtpauth23.prod.mesa1.secureserver.net (64.202.165.47) with ESMTP; 03 Apr 2012 11:03:37 -0000 Message-ID: <4F7AD909.9010407@netconfcentral.org> Date: Tue, 03 Apr 2012 04:03:37 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] Should deviations be deprecated and a real conformance statement replace it? 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, 03 Apr 2012 11:03:39 -0000 Hi, At the time they were done, I was very opposed to YANG deviations. I think the YANG conformance model is way too simplistic, and the total refusal to use deviations in actual deployments only makes it worse. SMIv2 has the ability for 1 module to create new and customized conformance statements, for data in that module or other modules. The concept of "the subset of the FOO-MIB required by the BAR-MIB" is well understood in SNMP, but appears to be an unsolvable mystery to the NETCONF WG. Perhaps deviation-stmts are way too complicated for something that doesn't get used. They also convey the completely wrong message "This module is incomplete". The use case above is not supported. Implementing them in yuma has been a total waste of time. YANG features are not suitable for this purpose. They are transparent to the language unless corresponding if-feature statements are used. (Just like a #define in C has no affect unless it is used in a conditional statement.) Cloning a module so if-feature-stmts could be added is not a good practice. Conformance requirements can also change over time. (e.g. add IPv6 features). New use cases and new consensus about optionality can occur. There can actually be 1 conformance statement per use-case, not per module. NETCONF for Constrained Devices is a conformance issue. We need a way to specify particular subsets of ietf-netconf.yang that align with CM use cases: - conformance for read-only server (get-config) - conformance for full CRUD but only all at once (copy-config) - conformance for full CRUD but partial edits allowed (edit-config) IMO, NETCONF Light is the wrong approach. It is a spot solution for 1 module to the general problem of module compliance. Andy From mbj@tail-f.com Tue Apr 3 05:27:38 2012 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 E24AB21F874C for ; Tue, 3 Apr 2012 05:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.581 X-Spam-Level: X-Spam-Status: No, score=-1.581 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiFilLIHwu0z for ; Tue, 3 Apr 2012 05:27:38 -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 5FD1721F8619 for ; Tue, 3 Apr 2012 05:27:38 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 6036012008F7; Tue, 3 Apr 2012 14:27:36 +0200 (CEST) Date: Tue, 03 Apr 2012 14:27:36 +0200 (CEST) Message-Id: <20120403.142736.1908318793655906558.mbj@tail-f.com> To: andy@netconfcentral.org From: Martin Bjorklund In-Reply-To: <4F7AD909.9010407@netconfcentral.org> References: <4F7AD909.9010407@netconfcentral.org> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] Should deviations be deprecated and a real conformance statement replace it? 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, 03 Apr 2012 12:27:39 -0000 Hi, Andy Bierman wrote: > At the time they were done, I was very opposed to YANG deviations. > I think the YANG conformance model is way too simplistic, and > the total refusal to use deviations in actual deployments > only makes it worse. > > SMIv2 has the ability for 1 module to create new and customized > conformance statements, for data in that module or other modules. > The concept of "the subset of the FOO-MIB required by the BAR-MIB" > is well understood in SNMP, but appears to be an unsolvable mystery > to the NETCONF WG. If you compare YANG and SMIv2, deviations should be compared with AGENT-CAPABILITIES. It was well recognized when we designed YANG that AGENT-CAPABILITIES were not widely used. Nevertheless, the WG felt that it is better to clearly specify how implementations differ from a standard, than to simply ignore the problem. It is true that SMIv2 has a more flexible mechanism to specify conformance levels, with its MODULE-COMPLIANCE macro. In YANG, we have if-feature. > Perhaps deviation-stmts are way too complicated for something that > doesn't get used. As long as there are few complicated standard models published, it should be no surprise that deviations are not used. Most devices use vendor-specific models, and normally you don't deviate from your own model. > They also convey the completely wrong message "This module is > incomplete". > The use case above is not supported. Implementing them in yuma has > been a total waste of time. > > YANG features are not suitable for this purpose. I assume you now are talking about using features like the netconf-light module use them? If so I agree with you - it is a misuse to use features like this. /martin From andy@netconfcentral.org Tue Apr 3 05:59:41 2012 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 A20BA21F86FF for ; Tue, 3 Apr 2012 05:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mjsC02EPL9l for ; Tue, 3 Apr 2012 05:59:41 -0700 (PDT) Received: from smtpauth20.prod.mesa1.secureserver.net (smtpauth20.prod.mesa1.secureserver.net [64.202.165.36]) by ietfa.amsl.com (Postfix) with SMTP id 22F6D21F86BB for ; Tue, 3 Apr 2012 05:59:41 -0700 (PDT) Received: (qmail 30685 invoked from network); 3 Apr 2012 12:59:40 -0000 Received: from unknown (75.84.164.152) by smtpauth20.prod.mesa1.secureserver.net (64.202.165.36) with ESMTP; 03 Apr 2012 12:59:40 -0000 Message-ID: <4F7AF43C.6020306@netconfcentral.org> Date: Tue, 03 Apr 2012 05:59:40 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Martin Bjorklund References: <4F7AD909.9010407@netconfcentral.org> <20120403.142736.1908318793655906558.mbj@tail-f.com> In-Reply-To: <20120403.142736.1908318793655906558.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Should deviations be deprecated and a real conformance statement replace it? 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, 03 Apr 2012 12:59:41 -0000 On 04/03/2012 05:27 AM, Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> At the time they were done, I was very opposed to YANG deviations. >> I think the YANG conformance model is way too simplistic, and >> the total refusal to use deviations in actual deployments >> only makes it worse. >> >> SMIv2 has the ability for 1 module to create new and customized >> conformance statements, for data in that module or other modules. >> The concept of "the subset of the FOO-MIB required by the BAR-MIB" >> is well understood in SNMP, but appears to be an unsolvable mystery >> to the NETCONF WG. > > If you compare YANG and SMIv2, deviations should be compared with > AGENT-CAPABILITIES. It was well recognized when we designed YANG that > AGENT-CAPABILITIES were not widely used. Nevertheless, the WG felt > that it is better to clearly specify how implementations differ from a > standard, than to simply ignore the problem. > You are right -- they are ACs, but advertised in-band in the . That was supposed to be a feature, not a reason to never use them. > It is true that SMIv2 has a more flexible mechanism to specify > conformance levels, with its MODULE-COMPLIANCE macro. In YANG, we > have if-feature. > YANG features are good for a small number of use-cases within a module. Once you get lots of features, interactions between features, and refined use-cases, they turn the module into a bowl of boolean spaghetti. >> Perhaps deviation-stmts are way too complicated for something that >> doesn't get used. > > As long as there are few complicated standard models published, it > should be no surprise that deviations are not used. Most devices use > vendor-specific models, and normally you don't deviate from your own > model. > > >> They also convey the completely wrong message "This module is >> incomplete". >> The use case above is not supported. Implementing them in yuma has >> been a total waste of time. >> >> YANG features are not suitable for this purpose. > > I assume you now are talking about using features like the > netconf-light module use them? If so I agree with you - it is a > misuse to use features like this. > yes > > /martin > > Andy From thomas.morin@orange.com Tue Apr 3 07:57:03 2012 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 D76EE11E80A6; Tue, 3 Apr 2012 07:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 FhNEDXw7gRvs; Tue, 3 Apr 2012 07:57:02 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id C426411E809D; Tue, 3 Apr 2012 07:57:01 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E7CC4E302B6; Tue, 3 Apr 2012 16:58:38 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id DE596E30290; Tue, 3 Apr 2012 16:58:38 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 16:57:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.193.21.179 ([10.193.21.179]) by ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) via Exchange Front-End Server owa.rd.francetelecom.fr ([10.192.128.53]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 Apr 2012 14:56:59 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 Content-class: urn:content-classes:message Date: Tue, 3 Apr 2012 16:57:29 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RtgDir review: draft-ietf-netmod-routing-cfg Thread-Index: Ac0RqgVn6yk6dPPtT+u0hJkdRctO1A== References: From: To: , , , X-OriginalArrivalTime: 03 Apr 2012 14:57:00.0260 (UTC) FILETIME=[05C63240:01CD11AA] X-Mailman-Approved-At: Tue, 03 Apr 2012 09:33:16 -0700 Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-routing-cfg 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, 03 Apr 2012 14:57:04 -0000 SGkgTGFkaXNsYXYsDQoNCihhIGZldyBjb21tZW50cyBiZWxvdykNCg0KMjAxMi0wMy0yMywgTGFk aXNsYXYgTGhvdGthOg0KPj4NCj4+IEl0IGlzIGFsc28gaW1wb3J0YW50IHRvIG5vdGUgdGhhdCB0 aGUgdXNlZnVsbmVzcyBvZiB0aGVzZSBzcGVjcyBpcw0KPj4gY29uZGl0aW9uZWQgKGEpIGJ5IHRo ZSBkZXZlbG9wbWVudCBvZiBZYW5nIG1vZHVsZXMgZm9yIGVhY2gNCj4+IHJlbGV2YW50IHJvdXRp bmcgcHJvdG9jb2wgKHdoaWNoIHNob3VsZCBiZSBmYWlybHkgZG9hYmxlIGFzc3VtaW5nDQo+PiB0 aGlzIGJhc2UgbW9kdWxlIGlzIGdlbmVyaWMgZW5vdWdoKSBhbmQgKGIpIGNvbmRpdGlvbmVkIGJ5 IHRoZQ0KPj4gZGV2ZWxvcG1lbnQgb2YgYWRkaXRpb25hbCBZYW5nIG1vZHVsZXMgYWxsb3dpbmcg dGhlIGRlc2NyaXB0aW9uIG9mDQo+PiBub24tdHJpdmlhbCBpbXBvcnQvZXhwb3J0IGZpbHRlcnMg YmV0d2VlbiByb3V0aW5nIHByb3RvY29scyBhbmQNCj4+IHJvdXRpbmcgdGFibGVzICh0aGlzIHBh cnQgYmVpbmcgcG9zc2libHkgaGFyZGVyIHRvIGFjaGlldmUsIHNpbmNlDQo+PiBpdCBtZWFucyBm aW5kaW5nIGEgY29tbW9uIGxhbmd1YWdlIGFibGUgdG8gZXhwcmVzcyB0aGUgdmFyaWV0eSBvZg0K Pj4gQUNMcy9wb2xpY2llcyB0aGF0IGNhbiBiZSBleHByZXNzZWQgb24gZGlmZmVyZW50IHJvdXRl ciBPU2VzDQo+PiB0b2RheSkuDQo+DQo+IEFic29sdXRlbHkuIFRoaXMgaXMgYSB1c3VhbCBkaWxl bW1hOiB3ZSBjYW4gZWl0aGVyIHRyeSB0byBkZXZlbG9wIGENCj4gZnVsbC1mbGVkZ2VkIHJvdXRl IGZpbHRlcmluZyBmcmFtZXdvcmsgYW5kIGV4cGVjdC9mb3JjZSBldmVyeWJvZHkgdG8NCj4gdXNl IGl0LCBvciBvcGVuIHRoZSBzcGFjZSBmb3IgbXVsdGlwbGUgY29tcGV0aW5nIGZyYW1ld29ya3Mu IFRoZQ0KPiBkcmFmdCBhbmQgdGhlIHJvdXRpbmcgbW9kdWxlIHRha2UgdGhlIGxhdHRlciBhcHBy b2FjaCwgYmVjYXVzZSB0aGUNCj4gbG9naWNzIG9mIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBk aWZmZXIgZnJvbSBlYWNoIG90aGVyDQo+IGNvbnNpZGVyYWJseSwgc28gaXQgaXMgbm90IHZlcnkg bGlrZWx5IHRvIGZpbmQgdGhlaXIgY29tbW9uDQo+IGRlbm9taW5hdG9yLiBJIHBsYW4gdG8gaW1w bGVtZW50IHRoZSByb3V0ZSBmaWx0ZXJpbmcgZnJhbWV3b3JrIG9mIHRoZQ0KPiBCSVJEIHJvdXRp bmcgZGFlbW9uIHdoaWNoIGl0IGlzIG1haW50YWluZWQgYnkgbXkgY29tcGFueS4NCg0KSXQgd291 bGQgYmUgbmljZSB0byBzZWUgbW9yZSB2ZW5kb3JzIGpvaW4gYW5kIHByb3Bvc2UgWWFuZyBtb2R1 bGVzIGZvciANCmZpbHRlcmluZy9yZWRpc3RyaWJ1dGlvbiA7IGV2ZW4gaWYgcmVzdHJpY3RlZCB0 byB0aGVpciBvd24gZmlsdGVyaW5nIA0Kc2VtYW50aWNzLCB0aGF0IHdvdWxkIGJlIGEgc3RhcnQu DQoNCg0KDQoNCj4+IENvbW1lbnRzOg0KPj4NCj4+IC0tLSBOb3RlIFdlbGwgLi4uDQo+Pg0KPj4g SSdtIGhvcGluZyB0aGlzIHJldmlldyB3aWxsIGJlIHJlbGV2YW50IGFuZCB1c2VmdWwuIEJ1dCwg a2VlcGluZyBpbg0KPj4gbWluZCB0aGF0IGRvaW5nIHRoaXMgcmV2aWV3IHdhcyBteSBmaXJzdCBl eHBvc3VyZSBhdCBZYW5nLCBzb21lDQo+PiBjb21tZW50cyBJJ20gbWFraW5nIGNvdWxkIHBvc3Np Ymx5IGJlIGNvbXBsZXRlbHkgb2ZmIHRyYWNrLCBhbmQNCj4+IHdoYXQgSSB0aGluayBJIHVuZGVy c3Rvb2QgY291bGQgYXMgd2VsbCBiZSwgcGFydGx5IG9yIGZ1bGx5LCB3cm9uZy4NCj4+IElmL3do ZW4gdGhpcyBoYXBwZW5zIHRvIGJlIHRoZSBjYXNlLCBJIGFwb2xvZ2l6ZTsganVzdCBiZSBmcmFu ayBhbmQNCj4+IGhvbmVzdCBhbmQgZXZlbnR1YWxseSB0ZWxsIG1lIHRvIGdvIGJhY2sgaG9tZSBh bmQgcmVhZCBhIGZldyBvdGhlcg0KPj4gc3BlY3MgYmVmb3JlIEkgY29tZSBiYWNrLi4uIDstKQ0K Pg0KPiBObywgSSBkb24ndCB0aGluayBpdCBpcyBuZWNlc3NhcnkuIDpeKSBBbmR5IEJpZXJtYW4g b25jZSBkZXNjcmliZWQNCj4gdGhlIHByb2JsZW0gd2UgYXJlIGZhY2luZyBoZXJlOg0KPg0KPiAi VGhlIGRvbWFpbiBleHBlcnRzIGRvbid0IHJlYWxseSBrbm93IHRoZSBkYXRhIG1vZGVsaW5nIHN0 dWZmLCBhbmQNCj4gdGhlIGRhdGEgbW9kZWxpbmcgZXhwZXJ0cyBkb24ndCByZWFsbHkga25vdyB0 aGUgZG9tYWluIHN0dWZmLiINCj4NCj4gSSBjZXJ0YWlubHkgaG9wZSB3ZSBjYW4gb2J0YWluIHNv dW5kIHJlc3VsdHMgdGhyb3VnaCBjb29wZXJhdGlvbg0KPiBiZXR3ZWVuIGJvdGggY2xhc3NlcyBv ZiBleHBlcnRzLg0KDQoNCjstKQ0KDQoNCj4NCj4+DQo+PiBUaGVyZSB3YXMgb25lIHNwZWNpZmlj IGRpZmZpY3VsdHkgZm9yIGRvaW5nIHRoaXMgcmV2aWV3OiBmb3INCj4+IHNvbWVvbmUgbGFja2lu ZyBYUGF0aCBmbHVlbmN5LCBpdCBpcyBoYXJkIHRvIHVuZGVyc3RhbmQgc29tZQ0KPj4gZGV0YWls cyBvZiB0aGUgWWFuZCBtb2R1bGVzLiBGb3IgaW5zdGFuY2UsIHRoZXJlIGlzIGEgY29tcGxleA0K Pj4gY29uZGl0aW9uIGZvciByb3V0aW5nLXByb3RvY29sL2Nvbm5lY3RlZC1yb3V0aW5nLXRhYmxl cywgYW5kIGl0DQo+PiB3b3VsZCBoYXZlIHJlbWFpbmVkIHRvdGFsbHkgb2JzY3VyZSB0byBtZSB3 aXRob3V0IHRoZSBlcnJvci1tZXNzYWdlDQo+PiB0aGF0IGlzIGFsc28gcHJvdmlkZWQgOyB0aGUg Y29ycmVzcG9uZGluZyBjb25zdHJhaW50IHdhcyBhbHNvDQo+PiBleHBsYWluZWQgaW4gdGhlIElu dHJvIG9mIHNlY3Rpb24gNCwgc28gdGhpcyBwYXJ0aWN1bGFyIGNhc2Ugd2FzIG9rDQo+PiAoc2Vl IG1vcmUgcHJlY2lzZSBjb21tZW50IGJlbG93KS4gQmV5b25kIHRoaXMgZXhhbXBsZSwgdGhlIHJl YWwNCj4+IGlzc3VlIGlzIHRoYXQgSSBjYW4ndCBrbm93IGlmIHRoZXJlIGlzIGFueSBvdGhlciBz aW1pbGFyIFhQYXRoDQo+PiBjb25zdHJhaW50IG9yIG90aGVyIGRldGFpbCB0aGF0IEkgbWlnaHQg aGF2ZSBtaXNzZWQuDQo+Pg0KPg0KPiBSRkMgNjA4NyByZXF1aXJlcyBhbGwgU3RhbmRhcmRzIFRy YWNrIG1vZHVsZXMgdG8gZGVzY3JpYmUgdGhlIHB1cnBvc2UNCj4gb2YgYWxsICdtdXN0JyBzdGF0 ZW1lbnRzIGluICdkZXNjcmlwdGlvbicuIEFjdHVhbGx5LCBzdWNoIGENCj4gZGVzY3JpcHRpb24g b2Z0ZW4gc2VlbXMgc3VwZXJmbHVvdXMgaWYgdGhlcmUgaXMgYW4gJ2Vycm9yLW1lc3NhZ2UnDQo+ IHN0YXRlbWVudC4NCg0KRWl0aGVyIHdheSwgaXQncyBzYW5lIHRvIGhhdmUgc29tZSB0ZXh0dWFs IGRlc2NyaXB0aW9uLg0KDQo+IEF0IGFueSByYXRlLCB0aGUgcHVycG9zZSBvZiBzdWNoIHN0YXRl bWVudCBzaG91bGQgYmUgcmVhc29uYWJseSBjbGVhcg0KPiBldmVuIHdpdGhvdXQgZGVjaXBoZXJp bmcgdGhlIFhQYXRoIGV4cHJlc3Npb25zLiBQbGVhc2UgbGV0IG1lIGtub3cgaWYNCj4gaXQgaXMg bm90IHRoZSBjYXNlIGFuZCBJIHdpbGwgdHJ5IHRvIGltcHJvdmUgdGhlIGRlc2NyaXB0aW9ucyBh bmQvb3INCj4gZXJyb3IgbWVzc2FnZXMuDQoNCkkgZGlkIG5vdCBkbyBhIGZ1bGwgcmV2aWV3IG9u IHRoaXMgYXNwZWN0IHlldCwgYnV0IGlmIHlvdSBkbyBpbmRlZWQgDQphcHBseSB0aGUgcnVsZSBh Ym92ZSwgdGhlbiBJIGV4cGVjdCB0aGlzIHdpbGwgYmUgZ29vZCBlbm91Z2guDQoNCg0KDQo+Pg0K Pj4gLS0gRG9jdW1lbnQgb3JnYW5pemF0aW9uDQo+Pg0KPj4gVGhlIGludGVyZmFjZSBwYXJhbWV0 ZXJzIGZvciBJUHY2IE5laWdoYm9yIERpc2NvdmVyeSB3b3VsZCBJIHRoaW5rDQo+PiBkZXNlcnZl IGJlaW5nIG1vdmVkIGluIGEgY29tcGFuaW9uIFlhbmcgbW9kdWxlLCB1bmxlc3MgdGhlcmUgaXMg YQ0KPj4gc3Ryb25nIHJlYXNvbiAoc3VjaCBhcyBhIGRlcGVuZGVuY3kpIHdoeSBpdCB3b3VsZCBi ZSBuZWVkZWQgdG8gYmUNCj4+IGtlcHQgaGVyZS4NCj4NCj4gT3RoZXIgSVB2NiBORCBwYXJhbWV0 ZXJzIGFyZSBkZWZpbmVkIGJ5IHRoZSAiaWV0Zi1pcCIgbW9kdWxlLiBJdCBtYXkNCj4gaW5kZWVk IGJlIHdvcnRoIHJlY29uc2lkZXJpbmcgdGhlIHN0cnVjdHVyZSBvZiB0aGUgImNvcmUiIG1vZHVs ZXMuDQoNCkFncmVlZC4NCg0KDQoNCg0KDQoNCg0KPg0KPj4NCj4+DQo+PiAtLS0gIEluZm9ybWF0 aW9uIG9uIHJvdXRlcw0KPj4NCj4+IFRoZSBZYW5nIG1vZHVsZSBsZXQncyB0aGUgb3BlcmF0b3Ig cmVhZCB0aGUgcm91dGluZyB0YWJsZXMuIEl0DQo+PiBsb29rcyBsaWtlIGEgdmVyeSB2YWxpZCBh bmQgdXNlZnVsIHRoaW5nIChhbmQgbm90IG5ldywgc2VlIFJGQzEyMTMNCj4+IE1JQikuDQo+Pg0K Pj4gSG93ZXZlciwgSSdtIHdvbmRlcmluZyBhYm91dCB0aGUgZm9sbG93aW5nIHBvaW50czoNCj4+ DQo+PiAtIHVzdWFsbHksIGEgcm91dGluZyB0YWJsZSBtYXkgaGF2ZSBtdWx0aXBsZSByb3V0ZXMg Zm9yIGEgc2FpZA0KPj4gZGVzdGluYXRpb24gYWRkcmVzcywgc29tZSBiZWluZyBwb3NzaWJseSBs ZXNzIHNwZWNpZmljIHRoYW4gb3RoZXJzLA0KPj4gb3IgaW5hY3RpdmUgZHVlIHRvIHZhcmlvdXMg cmVhc29ucyA6IGl0IGRpZCBub3QgaWRlbnRpZnkgaG93IHRoZXNlDQo+PiBzcGVjaWZpY2F0aW9u IGFsbG93IHRoZSBvcGVyYXRvciB0byBzZWUgYWxsIHJvdXRlcyBvZiBhIHJvdXRpbmcNCj4+IHRh YmxlIGZvciBhIHNhaWQgcHJlZml4LCBvciBhbGwgdGhlIG1vc3Qgc3BlY2lmaWMgcm91dGVzIGlu Y2x1ZGluZw0KPj4gdGhlIGluYWN0aXZlIG9uZXMsIG9yIGFsbCB0aGUgbW9zdCBzcGVjaWZpYyBh Y3RpdmVzIHJvdXRlcyB3aGVuDQo+PiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIChyZXF1aXJlZCBJ IHRoaW5rIGZvciBFQ01QIHN1cHBvcnQpLCBldGMuID8NCj4+IGl0IHNlZW1zIGl0IHdvdWxkIGJl IHdvcnRoIHRvIGV4dGVuZCB0aGUgZ2V0LXJvdXRlIFJQQyB0byBhbGxvdw0KPj4gZXhwcmVzc2lu ZyBhbGwgdGhlc2Uga2luZCBvZiBxdWVzdGlvbnMNCj4NCj4gVGhlICdnZXQtcm91dGUnIG1ldGhv ZCBkb2Vzbid0IHRyeSB0byBiZSB0ZXJyaWJseSBnZW5lcmFsIG9yDQo+IGV4dGVuc2libGUsIGl0 IGlzIG1haW5seSBpbnRlbmRlZCBhcyBhIHJlbWluZGVyIHRvIHJvdXRpbmcgZXhwZXJ0cw0KPiB0 aGF0IFlBTkcgYWxzbyBhbGxvd3MgZm9yIGRlZmluaW5nIG5ldyBSUEMgbWV0aG9kcy4gSSB0aGlu ayBpdCB3aWxsDQo+IGJlIGVhc2llciB0byBkZWNpZGUgd2hhdCBtZXRob2RzIGFyZSBuZWVkZWQg YXMgc29vbiBhcyB0aGVyZSBhcmUgZGF0YQ0KPiBtb2RlbHMgZm9yIHRoZSBtYWpvciByb3V0aW5n IHByb3RvY29scywgc3VjaCBhcyBPU1BGIG9yIEJHUC4NCg0KWW91IG1pZ2h0IHdhbnQgdG8gZmlu ZCBhIGJhbGFuY2UgYmV0d2VlbiBkb2luZyB0aGluZ3MgaW4gdGhlc2UgDQpzcGVjaWZpY2F0aW9u cyBhbmQgcHVudGluZyB0byBmdXR1cmUgd29yayBhbmQgbmV3IGV4dGVuc2lvbnMuDQoNCkl0IHNl ZW1zIHRvIG1lIHRoYXQsIGF0IHRoZSB2ZXJ5IGxlYXN0LCB0aGUgZ2V0LXJwYyBzaG91bGQgYWxs b3cgdG8gDQpyZXR1cm4gbW9yZSB0aGFuIG9uZSByb3V0ZSAoYWxsIGFjdGl2ZSBvbmVzKSBzbyBh cyB0byBiZSBjb21wYXRpYmxlIHdpdGggDQpFQ01QLiAgRmlsdGVyaW5nIGJldHdlZW4gYWN0aXZl IGFuZCBpbmFjdGl2ZSByb3V0ZXMgd291bGQgYmUgSSB0aGluayANCmZhaXJseSBnZW5lcmljIGFu ZCByZWxldmFudCB0byBhZGQgaW4gdGhlc2Ugc3BlY3MuDQoNCg0KDQo+PiAtIGFzc3VtaW5nIHRo YXQgaW4gc29tZSBjYXNlcyBkdW1waW5nIHdob2xlIHJvdXRpbmcgdGFibGVzIHdvdWxkDQo+PiBu b3QgYmUgZWZmaWNpZW50LCB3aWxsIHRoZXJlIGJlIGFuIGVmZmljaWVudCB3YXkgdG8gZ2V0IGFn Z3JlZ2F0ZQ0KPj4gaW5mb3JtYXRpb24gb24gYSByb3V0aW5nIHRhYmxlIDsgc3VjaCBhcyAiaG93 IG1hbnkgcm91dGVzIGluIHRoZQ0KPj4gcm91dGluZyB0YWJsZSIgPyBvciAiaG93IG1hbnkgaW5h Y3RpdmUgcm91dGVzIGluIHRoZSByb3V0aW5nIHRhYmxlIg0KPj4gPyAgImhvdyBtYW55IHJvdXRl cyBmb3IgcHJlZml4IHgueS56IiA/DQo+DQo+IFl1cCwgdGhpcyBzb3VuZHMgbGlrZSBhIHVzZWZ1 bCB0aGluZyB0byBoYXZlLiBQZXJoYXBzIGl0IG1pZ2h0IG1ha2UNCj4gc2Vuc2UgdG8gYWxzbyBo YXZlIGEgZ2VuZXJpYyBSUEMgcmV0dXJuaW5nIHRoZSBudW1iZXIgb2YgZW50cmllcyBpbiBhDQo+ IGxpc3Qgb3IgbGVhZi1saXN0Lg0KDQpBZ3JlZWQuDQoNCg0KPj4gLSB0aGUgdGVybSAiZGVzdGlu YXRpb24tYWRkcmVzcyIgY2hvc2VuIHRvIGRlc2lnbmF0ZSB0aGUgcGllY2Ugb2YNCj4+IGluZm9y bWF0aW9uIGJhc2VkIG9uIHdoaWNoIHRoZSBnZXQtcm91dGUgUlBDIHdvcmtzLCBpcyBwb3NzaWJs eSBub3QNCj4+IHN1aXRhYmxlIGZvciBhbGwgcm91dGluZyBwcm90b2NvbHMuIFRoZSBleGFtcGxl cyB0aGF0IEkgd291bGQgc2VlDQo+PiBhcmUgKGEpIE1QLUJHUCwgd2hlcmUgdGhlIHJvdXRpbmcg aW5mb3JtYXRpb24gKE5MUkkpIGNhbiBiZSBtb3N0bHkNCj4+IGFueXRoaW5nIChkZXBlbmRzIG9u IHRoZSBTQUZJKSwgYW5kIChiKSBtdWx0aWNhc3QsIHdoZXJlIHRoZQ0KPj4gcm91dGluZyBpbmZv cm1hdGlvbiBvbiB3aGljaCB0aGUgUElNIHByb3RvY29scyB3b3JrIGNhbiBiZSBhDQo+PiAoc291 cmNlLGdyb3VwKSB0dXBsZSwgcG9zc2libHkgYXVnbWVudGVkIHdpdGggZmxhZ3MNCj4NCj4gWWVz LCBzZWUgYWJvdmUuIERvIHlvdSBoYXZlIGFuIGlkZWEgaG93IHRvIGRlZmluZSBhIGdlbmVyYWwg bWV0aG9kDQo+IHdpdGhvdXQgaGF2aW5nIHRoZSBkYXRhIG1vZGVscyBmb3IgTVAtQkdQIG9yIG11 bHRpY2FzdCByb3V0aW5nPw0KDQpXZWxsLCB0aGUgYWJvdmUgY29tbWVudCB3YXMgbW9yZSBhYm91 dCB0aGUgdGVybSBjaG9zZW4gdGhhbiBhYm91dCBkYXRhIA0KbW9kZWxpbmcuIFdoeSBub3QganVz dCBjYWxsICJtYXRjaC1kYXRhIiB0aGUgcGllY2Ugb2YgaW5mb3JtYXRpb24gaW4gdGhlIA0Kcm91 dGVzIG9uIHdoaWNoIHRoZSBnZXQtcnBjIHdpbGwgdHJ5IHRvIG1hdGNoID8NCg0KDQo+PiAtIChy ZWxhdGVkIHRvIHRoZSBwcmV2aW91cyBwb2ludDopIDogSSdtIHVuY2xlYXIgaWYgdGhlc2Ugc3Bl Y3MNCj4+IGFsbG93IGEgZ2V0LXJvdXRlIHRvIG1hdGNoIG9uIGRpZmZlcmVudCBwb3J0aW9ucyBv ciBhdHRyaWJ1dGVzIG9mIGENCj4+IHJvdXRlcyAgKGVnLiBnZXQgcm91dGUgZm9yIHByZWZpeCBY IGFkdmVydGlzZWQgYnkgcGVlciBYLCBvciBoYXZpbmcNCj4+IGJlZW4gcmVhZHZlcnRpc2VkIGJ5 IEFTIFkuLi4pLi4uIEFzIEkgdW5kZXJzdGFuZCwgdGhlcmUgY2FuIGJlIHNvbWUNCj4+IEFGTi9T QUZJIHNwZWNpZmljIGV4dGVuc2lvbnMsIGJ1dCBubyBwZXItcHJvdG9jb2wgZXh0ZW5zaW9ucy4g SXMNCj4+IHRoaXMgYSBjb3JyZWN0IHVuZGVyc3RhbmRpbmcgPyBJZiBub3QsIHdvdWxkbid0IGl0 IG1ha2Ugc2Vuc2UgdG8NCj4+IG1ha2UgaXQgbW9yZSBleHRlbnNpYmxlID8NCj4NCj4gVGhlcmUg Y2FuIGJlIHBlci1wcm90b2NvbCBleHRlbnNpb25zLCB0b28sIGl0IGlzIGFsc28gZGVtb25zdHJh dGVkIGluDQo+IHRoZSBSSVAgZXhhbXBsZS4NCg0KDQpJIHVuZGVyc3RhbmQgaG93IHRoZSBSSVAg ZXhhbXBsZSBkb2VzIGV4dGVuZCB0aGUgaW5mb3JtYXRpb24gKnJldHVybmVkKiANCmJ5IGdldC1y b3V0ZS4gQnV0IEkgZG9uJ3QgZ2V0IGhvdyBhIHByb3RvY29sIGNhbiBleHRlbmQgdGhlIGluZm9y bWF0aW9uIA0Kb24gd2hpY2ggZ2V0LXJwYyBtYXRjaGVzID8gRm9yIGluc3RhbmNlLCBjYW4gSSBn ZXQtcm91dGUgdG8gZmluZCB0aGUgDQpyb3V0ZSBmb3Igd2hpY2ggdGFnID0gNDIgPyAodGhlb3Jl dGljYWwgZXhhbXBsZSwgSSdtIG5vdCBzYXlpbmcgdGhlcmUncyANCmEgdXNlIGZvciB0aGlzKQ0K DQoNCg0KPj4gLSB3aHkgcmVzdHJpY3QgdGhlIGdldC1yb3V0ZSBSUEMgdG8gb25seSBxdWVyeSB0 aGUgc3BlY2lhbC9kZWZhdWx0DQo+PiAiRklCIiByb3V0aW5nIHRhYmxlID8gaXQgd291bGQgc2Vl bSB1c2VmdWwgdG8gYmUgYWJsZSB0byBxdWVyeSBhbnkNCj4+IHJvdXRpbmcgdGFibGUuDQo+DQo+ IFRoaXMgY291bGQgYmUgZG9uZSBidXQgaXQgd291bGQgYnJpbmcgbmV3IGlzc3VlcyB0byBjb25z aWRlciAtDQo+IG11bHRpcGxlIGNhbmRpZGF0ZSByb3V0ZXMgZXRjLiBUaGUgJ2dldC1yb3V0ZScg bWV0aG9kIGlzIHN1cHBvc2VkIHRvDQo+IGFuc3dlciB0aGUgc2ltcGxlIHF1ZXN0aW9uOiAiV2hp Y2ggcm91dGUgd2lsbCBiZSB1c2VkIGZvciBmb3J3YXJkaW5nDQo+IHBhY2tldHMgdG8gZGVzdGlu YXRpb24gVy5YLlkuWj8iDQoNClR3byB0aGluZ3M6DQoNCi0gdGhlcmUgaXMgYSBzdHJvbmcsIGFu ZCBwb3NzaWJseSBkZWJhdGFibGUsIGh5cG90aGVzaXMgaGVyZTogdGhhdCB0aGUgDQpvcGVyYXRv cnMgdGhhdCByZWxpZXMgb24gTmV0Y29uZi9ZYW5nIHdpbGwgdXNlIHRoaXMgbW9kdWxlIHdpdGgg YXMgdGhlIA0Kb25seSBuZWVkIHRoZSBuZWVkIHRvIGtub3cgYWJvdXQgZm9yd2FyZGluZy4NCg0K LSB0aGUgIm11bHRpcGxlIGNhbmRpZGF0ZSByb3V0ZSIgaXNzdWUgaXMsIEkgdGhpbmssIHNvbWV0 aGluZyB0aGF0IG5lZWRzIA0KdG8gYmUgdGFrZW4gY2FyZSBvZiwgZXZlbiBmb3IgdGhlIEZJQiA7 IGlmIG9ubHkgYXMgdG8gdGFrZSBjYXJlIG9mIEVDTVAsIA0KYnV0IGFsc28gZm9yIHVzZS1jYXNl cyBzdWNoIGFzIElQRlJSICh3aGVyZSBtdWx0aXBsZSBuZXh0LWhvcHMgYXJlIGluIA0KdGhlIEZJ QiBmb3IgYSBzYWlkIHByZWZpeCwgc29tZSBvZiB0aGVtIHdpbGwgYmVjb21lIGFjdGl2ZSBvbmx5 IHdoZW4gYSANCmNlcnRhaW4gZmFpbHVyZSBhcmlzZSkNCg0KDQoNCj4+IC0tLSBSZWRpc3RyaWJ1 dGluZyByb3V0ZXMgZGlyZWN0bHkgYmV0d2VlbiByb3V0aW5nIHByb3RvY29scw0KPj4NCj4+IFRo ZXNlIHNwZWNpZmljYXRpb25zIG9ubHkgYWxsb3cgdGhlIGV4Y2hhbmdlIG9mIHJvdXRlcyBmcm9t IGENCj4+IHJvdXRpbmcgcHJvdG9jb2wgb3Igcm91dGluZyB0YWJsZSB0byBhIHJvdXRpbmcgdGFi bGUsIGJ1dCBub3QgZnJvbQ0KPj4gYSByb3V0aW5nIHByb3RvY29sIHRvIGFub3RoZXIgcm91dGlu ZyBwcm90b2NvbHMuIEhvd2V2ZXIsIHRoZQ0KPj4gbGF0dGVyIGlzIHNvbWV0aGluZyB1c2VkIGEg bG90IGluIHByYWN0aWNlIChlLmcuIGNvbnRyb2xsaW5nDQo+PiByZWRpc3RyaWJ1dGlvbiBiZXR3 ZWVuIHR3byBJR1AgYXJlYXMpLiBPZiBjb3Vyc2UsIGJ5IHVzaW5nIGFuDQo+PiBpbnRlcm1lZGlh dGUgcm91dGluZyB0YWJsZSB5b3UgY291bGQgYWNoaWV2ZSB0aGUgc2FtZSByZXN1bHQsIGJ1dA0K Pj4gZG9lc24ndCBpdCBsb29rIGxpa2UgZXh0cmEgb3ZlcmhlYWQgPw0KPg0KPiBTb21lIGltcGxl bWVudGF0aW9ucyAoSU9TLCBmb3IgZXhhbXBsZSkgcmVkaXN0cmlidXRlIHJvdXRlcyBiZXR3ZWVu DQo+IHByb3RvY29scyB3aGlsZSBvdGhlcnMgKEpVTk9TLCBCSVJEKSB1c2UgYW4gaW50ZXJtZWRp YXRlIHJvdXRpbmcNCj4gdGFibGUuIEJ1dCBhcyB5b3Ugc2F5LCB0aGUgZm9ybWVyIGFwcHJvYWNo IG1heSBiZSBlbXVsYXRlZCB3aXRoIHRoZQ0KPiBsYXR0ZXIuIEluIHRoZSBtb3N0IHR5cGljYWwg Y2FzZSB3aGVuIHR3byBwcm90b2NvbHMgYXJlIGNvbm5lY3RlZCB0bw0KPiB0aGUgc2FtZSAoZS5n LiBtYWluKSByb3V0aW5nIHRhYmxlLCBlYWNoIHByb3RvY29sIGNhbiB1c2UgYSBmaWx0ZXIgdG8N Cj4gcHVsbCB0aGUgcm91dGVzIG9yaWdpbmF0aW5nIGZyb20gdGhlIG90aGVyIHByb3RvY29sLg0K DQoNCkl0cyBvZnRlbiBiZXR0ZXIgd2hlbiBzaW1wbGUgdGhpbmdzIGNvdWxkIGJlIGRvYWJsZSBp biBhIHNpbXBsZSB3YXkuDQoNCldoYXQgYXJlIHRoZSBkcmF3YmFja3Mgb2YgYWxsb3dpbmcgcm91 dGVzIHRvIGJlIGV4Y2hhbmdlZCBkaXJlY3RseSANCmJldHdlZW4gcm91dGluZyBwcm90b2NvbHMg Pw0KDQooc2FpZCBvdGhlcndpc2U6IG5vdCBhbGxvd2luZyBkaXJlY3QgaW1wb3J0L2V4cG9ydCBi ZXR3ZWVuIHJvdXRpbmcgDQpwcm90b2NvbHMgbG9va3MgbGlrZSBhbiBhcmJpdHJhcnkgcmVzdHJp Y3Rpb247IHdoYXQgaXMgdGhlIGRyaXZlciBmb3IgDQppbnRyb2R1Y2luZyB0aGlzIGFyYml0cmFy eSByZXN0cmljdGlvbiA/IGlzIHRoaXMgcmVzdHJpY3Rpb24gd29ydGggdGhlIA0Kb3BlcmF0aW9u YWwgY29zdCAobW9yZSB3b3JrIHRvIGRvIHRvIGRvIHByb3RvY29sLXRvLXByb3RvY29sIA0KcmVk aXN0cmlidXRpb24sIG1vcmUgcm91dGluZyB0YWJsZSB0byBpbnN0YW50aWF0ZSkgID8NCg0KDQo+ PiAtLS0gTW9kaWZ5IHJvdXRlcyBiZWluZyByZWRpc3RyaWJ1dGVkDQo+Pg0KPj4gVGhlcmUgZG9l cyBub3Qgc2VlbSB0byBiZSBhbnkgd2F5IHRocm91Z2ggd2hpY2ggYSByb3V0ZSBtYXkgYmUNCj4+ IG1vZGlmaWVkL2F1Z21lbnRlZCBieSBhIGZpbHRlciB3aGVuIGV4cG9ydGVkIGZyb20gYSByb3V0 aW5nIHRhYmxlDQo+PiBvciBwcm90b2NvbCB0byBhbm90aGVyLiBJdCBzZWVtcyB0byBtZSB0aGF0 IHRoaXMgaXMgc29tZXRoaW5nIHRoYXQNCj4+IGlzIHVzZWQgYSBsb3QgaW4gcHJhY3RpY2UuDQo+ DQo+IE9mIGNvdXJzZSwgdGhpcyBpcyBqdXN0IGFub3RoZXIgdGFzayBmb3IgdGhlIGZ1dHVyZSBy b3V0ZSBmaWx0ZXJpbmcNCj4gZnJhbWV3b3JrKHMpLg0KDQpPaywgdGhlbiB0aGUgdGV4dCBpbiBw YXJhZ3JhcGggwqcxIG9mIHNlY3Rpb24gNC41IGlzIGdvb2QgZW5vdWdoDQoNCiAgICAgUm91dGUg ZmlsdGVycyBtYXkgYWxzbyBtYW5pcHVsYXRlIHJvdXRlcywgaS5lLiwgYWRkLCBkZWxldGUsIG9y IG1vZGlmeQ0KICAgICB0aGVpciBwcm9wZXJ0aWVzLg0KDQoNCg0KPj4gLS0tICBBcHBsaWNhYmls aXR5IHRvIFJGQzQzNjQNCj4+DQo+PiBBbGxvd2luZyBtdWx0aXBsZSAicm91dGVycyIgaXMgYSBn b29kIHN0YXJ0aW5nIHBvaW50IGZvciB1c2luZw0KPj4gdGhlc2Ugc3BlY3MgaW4gdGhlIGNvbnRl eHQgb2YgUkZDNDM2NCAoTVBMUy9CR1AgSVAgVlBOcykuIEhvd2V2ZXIsDQo+PiBpZiBJIHVuZGVy c3RhbmQgY29ycmVjdGx5IFlhbmcgc3ludGF4LCB0aGUgd2F5IHRoZSBmaWx0ZXJzIGFyZQ0KPj4g ZGVmaW5lZCB3b3VsZCBub3Qgd29yayBpbiB0aGUgY29udGV4dCBvZiBSRkM0MzY0LCB3aGVyZSBh IEJHUA0KPj4gcm91dGluZyBpbnN0YW5jZSBpbiB0aGUgbWFzdGVyICJyb3V0ZXIiIGV4cG9ydHMg c2VsZWN0ZWQgcm91dGVzIGluDQo+PiBlYWNoIG9mIHRoZSByb3V0aW5nIHRhYmxlIG9mIGVhY2gg VlBOIChWUkYpLiAgVGhlIFZSRiBhbHNvIGV4cG9ydA0KPj4gcm91dGVzIHRvIHRoZSBtYXN0ZXIg aW5zdGFuY2UuDQo+DQo+IFRoZSBkcmFmdCBzYXlzOiAiQWx0aG91Z2ggaXQgaXQgbm90IGVuZm9y Y2VkIGJ5IHRoZSBkYXRhIG1vZGVsLA0KPiBkaWZmZXJlbnQgcm91dGVyIGluc3RhbmNlcyBub3Jt YWxseSBkbyBub3QgaW50ZXJuYWxseSBzaGFyZSBhbnkNCj4gZGF0YS4iIFNvIHRoaXMgbWF5IGJl IGEgdXNlIGNhc2UgZm9yIHNoYXJpbmcgZGF0YSBhbW9uZyBkaWZmZXJlbnQNCj4gcm91dGVyIGlu c3RhbmNlcy4gVGhlcmUgaXMgbm90aGluZyBpbiB0aGUgZGF0YSBtb2RlbCAob3IgWUFORykNCj4g cHJldmVudGluZyB0aGlzLiBJIHdpbGwgYWxzbyByZWxheCB0aGUgY2l0ZWQgc2VudGVuY2UsIGlu IHRoZQ0KPiBmb2xsb3dpbmcgc2Vuc2U6ICJJbXBsZW1lbnRhdGlvbnMgbWF5IHNwZWNpZnkgdGhl IHJ1bGVzIGZvciBzaGFyaW5nDQo+IGRhdGEgYW1vbmcgcm91dGVyIGluc3RhbmNlcy4iDQoNClRo aXMgaXMgZ29vZCwgYnV0IG5vdCBlbm91Z2ggKHNlZSBiZWxvdykuDQoNCj4+IFRoZSB0d28gb2Jz dGFjbGVzIEkgd291bGQgc2VlIChJIG1pZ2h0IGJlIHdyb25nKSBhcmUgdGhlDQo+PiBmb2xsb3dp bmc6IC0gbm8gd2F5IHRvIG1vZGlmeSByb3V0ZXMgd2hpbGUgdGhleSBhcmUNCj4+IGltcG9ydGVk L2V4cG9ydGVkIDogdGhlIFJGQzQzNjQgdXNlLWNhc2Ugd291bGQgcmVxdWlyZSB0aGUgYWJpbGl0 eQ0KPj4gdG8gKGF0IGxlYXN0KSBhZGQvc3RyaXAgYXR0cmlidXRlcyB0by9mcm9tIHRoZSByb3V0 ZXMNCj4NCj4gRWFjaCBpbXBvcnQvZXhwb3J0IGlzIHN1YmplY3QgdG8gYSByb3V0ZSBmaWx0ZXIs IHdoaWNoIHNob3VsZCBiZSBhYmxlDQo+IHRvIHBlcmZvcm0gc3VjaCBtYW5pcHVsYXRpb25zLg0K DQpPay4NCg0KPj4gLSBubyB3YXkgdG8gcmVkaXN0cmlidXRlIHJvdXRlcyBiZXR3ZWVuIHJvdXRp bmcgdGFibGVzIG9mIGRpZmZlcmVudA0KPj4gInJvdXRlcnMiICh3aGF0IGxldCBtZSB0aGluayB0 aGlzIGNvbnN0cmFpbnQgZXhpc3RzIGlzIChhKSB0aGUNCj4+IGluYWJpbGl0eSB0byBuYW1lIGEg cm91dGVyIHdoZW4gZGVzaWduYXRpbmcgYSByb3V0aW5nLXRhYmxlIHRvDQo+PiBpbXBvcnQvZXhw b3J0IGZyb20vdG8sIGFuZCAoYikgdGhlIFhQYXRocyBmb3INCj4+IGNvbm5lY3RlZC1yb3V0aW5n LXRhYmxlcy9yb3V0aW5nLXRhYmxlL25hbWUgYW5kDQo+PiByZWNpcGllbnQtcm91dGluZy10YWJs ZXMgcmVjaXBpZW50LW5hbWUsIHdoaWNoIHNlZW1zIHRvIG5vdCBiZSBhYmxlDQo+PiB0byBwb2lu dCBoaWdoZXIgaW4gdGhlIGhpZXJhcmNoeSB0aGFuIHRoZSAncm91dGVyJyBvbiB3aGljaCB0aGV5 DQo+PiBhcmUgZGVmaW5lZCApDQo+DQo+IFRydWUsIHRoZSBjb25uZWN0ZWQgcm91dGluZyB0YWJs ZSBjdXJyZW50bHkgbXVzdCBiZSB3aXRoaW4gdGhlIHNhbWUNCj4gcm91dGVyIGluc3RhbmNlLiBT byB0aGlzIGNvbnN0cmFpbnQgc2hvdWxkIGJlIHJlbW92ZWQsIGFuZA0KPiBpbXBsZW1lbnRhdGlv bnMgdGhhdCBuZWVkIHN1Y2ggYW4gaXNvbGF0aW9uIHdpbGwgaGF2ZSB0byBzdGF0ZSBpdA0KPiBl eHBsaWNpdGx5Lg0KDQpBZ3JlZWQuDQoNCg0KPj4gLSB0aGUgY29uc3RyYWludCB0aGF0IGZvciBh IHNhaWQgcm91dGluZyBwcm90b2NvbHMgIkZvciBlYWNoDQo+PiBBRk4vU0FGSSBwYWlyIHRoZXJl IG1heSBiZSBhdCBtb3N0IG9uZSBjb25uZWN0ZWQgcm91dGluZyB0YWJsZS4iIC4NCj4+IEluIHRo ZSBSRkM0MzY0IGNhc2UsIHRoZSBnbG9iYWwgQkdQIHJvdXRpbmcgcHJvY2VzcyB3b3VsZCBwdXNo DQo+PiByb3V0ZXMgdG8gbXVsdGlwbGUgVlJGcy4NCj4NCj4gVGhpcyBpcyBtb3N0IGxpa2VseSBu b3QgYSBwcm9ibGVtIGJlY2F1c2UgYW55IG51bWJlciBvZiByZWNpcGllbnQNCj4gcm91dGluZyB0 YWJsZXMgY2FuIGJlIGNvbmZpZ3VyZWQgdG8gcmVjZWl2ZSAoZmlsdGVyZWQpIHJvdXRlcyBmcm9t DQo+IHRoZSBzaW5nbGUgcm91dGluZyB0YWJsZSB3aGljaCBpcyBjb25uZWN0ZWQgdG8gYSByb3V0 aW5nIHByb3RvY29sLA0KPiBjZi4gdGhlICJyZWNpcGllbnQtcm91dGluZy10YWJsZXMiIGxpc3Qu DQoNClVuZGVyc3Rvb2QsIHRoZXJlIGlzIGEgd2F5IHRvIG1ha2UgaXQgd29yaywgYnV0IHNlZSBk aXNjdXNzIGFib3ZlLCBpdCANCnNlZW1zIHRvIG1lIGFzIHBvc3NpYmx5IHVzZWxlc3Mgb3Zlcmhl YWQgdG8gYWx3YXkgbmVlZCBhbiBpbnRlcm1lZGlhdGUgDQpyb3V0aW5nIHRhYmxlIGluIHN1Y2gg Y2FzZXMuDQoNCg0KDQo+Pg0KPj4gLS0tIEVuYWJsaW5nL2Rpc2FibGluZyBhbiBpbnRlcmZhY2UN Cj4+DQo+PiBTb21ldGhpbmcgZG9uZSB2ZXJ5IG9mdGVuIG9uIGEgcm91dGVyIGNvbnNpc3RzIGlu IHB1dHRpbmcgYW4NCj4+IGludGVyZmFjZSAic2h1dGRvd24iIG9yICJpbmFjdGl2ZSIsIHByZXNl cnZpbmcgaXRzIGNvbmZpZ3VyYXRpb24NCj4+IGJ1dCBtYWtpbmcgaXQgaWdub3JlZCBieSB0aGUg cm91dGVyIGFuZCBrZWVwaW5nIHRoZSBsaW5rIGRvd24uDQo+PiBUaGVzZSBzcGVjaWZpY2F0aW9u cyBkb24ndCBzZWVtIHRvIHByb3ZpZGUgdGhpcy4gIElzIHRoaXMgc29tZXRoaW5nDQo+PiBhbHJl YWR5LCBvciBleHBlY3RlZCB0byBiZSwgcHJvdmlkZWQgYnkgYW5vdGhlciBZYW5nIGV4dGVuc2lv biA/DQo+DQo+IFRoZSAiaWV0Zi1pbnRlcmZhY2VzIiBtb2R1bGUgaGFzIHRoaXMgImVuYWJsZWQi IHN3aXRjaCwgdGhhdCB3aWxsDQo+IHNlcnZlciB0aGlzIHB1cnBvc2UuIFdlIGFyZSBhbHNvIGRp c2N1c3Npbmcgd2hlcmUgdG8gcHV0IHRoZQ0KPiAiaXMtcm91dGVyIiB0b2dnbGUgdGhhdCBlbmFi bGVzL2Rpc2FibGVzIGZvcndhcmRpbmcgb24gYW4gaW50ZXJmYWNlLg0KPg0KDQpPay4NCg0KDQo+ Pg0KPj4gSWYgc28sIGhvdyB3b3VsZCB0aGUgdHdvIGludGVyYWN0LCBpZiBmb3IgaW5zdGFuY2Us IGFuIGludGVyZmFjZSBpcw0KPj4gc2h1dGRvd24gaW4gdGhpcyBvdGhlciBtb2R1bGUgYnV0IHVz ZWQgaW4gdGhlIHJvdXRpbmcgbW9kdWxlID8NCj4NCj4gR29vZCBwb2ludCwgdGhpcyBoYXMgdG8g YmUgc3BlY2lmaWVkIGluIHRoZSBkcmFmdC4NCj4NCg0KT2ssIHdlIGFncmVlLg0KDQoNCj4+DQo+ PiAtLS0gRW5hYmxpbmcvRGlzYWJsaW5nIGEgcHJvdG9jb2wgb24gYW4gaW50ZXJmYWNlLCBvciBt b2RpZnlpbmcNCj4+IHByb3RvY29sIHBlci1pbnRlcmZhY2UgcGFyYW1ldGVycw0KPj4NCj4+IFNv bWV0aGluZyBkb25lIHZlcnkgb2Z0ZW4gb24gYSByb3V0ZXIgY29uc2lzdHMgaW4NCj4+IGVuYWJs aW5nL2Rpc2FibGluZyBhIHNhaWQgcHJvdG9jb2wgb24gYSBzYWlkIGludGVyZmFjZSwgb3IgbW9y ZQ0KPj4gZ2VuZXJhbGx5IG1vZGlmeWluZyBwYXJhbWV0ZXJzIGZvciBhIHNhaWQgcHJvdG9jb2wg b24gYSBzYWlkDQo+PiBpbnRlcmZhY2UgKHR5cGljYWwgZXhhbXBsZSBiZWluZyB0aGUgbWV0cmlj KS4gIEFzIEkgdW5kZXJzdGFuZCB0aGlzDQo+PiB3b3VsZCBiZSBhbGxvd2VkIGJ5IHRoZXNlIHNw ZWNzIGJ5IGhhdmluZyBhIG1vZHVsZSBleHRlbmRpbmcNCj4+IHByb3RvY29sIFggYXVnbWVudCBy b3V0aW5nL3JvdXRlci9pbnRlcmZhY2Ugd2l0aCBpdHMgb3duDQo+PiBwYXJhbWV0ZXJzLiAgSG93 ZXZlciwgSSdtIHdvbmRlcmluZyBpZiB0aGVzZSBwZXItcHJvdG9jb2wNCj4+IHBlci1pbnRlcmZh Y2UgcGFyYW1ldGVycyB3b3VsZG4ndCBiZSBiZXR0ZXIgcGxhY2VkIHVuZGVyIGVhY2gNCj4+IHJv dXRpbmcvcm91dGVyL3JvdXRpbmctcHJvdG9jb2xbWF0uDQo+DQo+IEl0IGlzIHVwIHRvIHRoZSBk ZXNpZ25lciBvZiB0aGUgcHJvdG9jb2wgZGF0YSBtb2RlbCwgYm90aCBvcHRpb25zIGFyZQ0KPiBw b3NzaWJsZS4gTWF5YmUgd2Ugc2hvdWxkIGdpdmUgc29tZSBndWlkZWxpbmVzLg0KPg0KPj4gVGhl IHJlYXNvbnMgSSBzZWUgYXJlIHRoZSBmb2xsb3dpbmc6ICogaW4gc29tZSBjYXNlcyBhIHNhaWQg cm91dGVyDQo+PiBtYXkgcnVuIG11bHRpcGxlIGluc3RhbmNlcyBvZiBhIHNhaWQgcHJvdG9jb2wg dHlwZSwgaW4gcGFyYWxsZWwsDQo+PiBhbmQgeW91IG1heSBuZWVkIHRvIGhhdmUgYSB3YXkgdG8g ZGlmZmVyZW50aWF0ZSBlbmFibGluZyBpbnN0YW5jZSBBDQo+PiBvZiBwcm90b2NvbCBYIGZyb20g aW5zdGFuY2UgQiBvZiBwcm90b2NvbCBYICogeW91IGNvdWxkIGV2ZW4gZmluZA0KPj4gdXNlIGNh c2VzIHdoZXJlIGEgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIGEgc2FpZCBwcm90b2NvbCB0eXBlIHJ1 biBpbg0KPj4gcGFyYWxsZWwgb24gYSBzYWlkIGludGVyZmFjZSAoZWcuIG11bHRpIGluc3RhbmNl IElTSVMpICogbXkNCj4+IHVuZGVyc3RhbmRpbmcgb2YgdGhlIFlhbmcgbW9kdWxlIGlzIHRoYXQg dGhlIGN1cnJlbnQgc3RydWN0dXJlDQo+PiB3b3VsZCBub3QgYWxsb3cgYXVnbWVudGluZyBhIHNh aWQgaW50ZXJmYWNlIG11bHRpcGxlIHRpbWVzIGZvciBhDQo+PiBzYW1lIHBhcmFtZXRlciBvZiBh IHNhaWQgcHJvdG9jb2wgdHlwZS4NCj4NCj4gSWYgc29tZXRoaW5nIGxpa2UgdGhpcyBpcyBuZWNl c3NhcnksIG9uZSBjYW4gYXVnbWVudCBhbiBpbnRlcmZhY2UNCj4gY29uZmlndXJhdGlvbiB3aXRo IGEgbGlzdCB3aGVyZSBlYWNoIGVudHJ5IGNvcnJlc3BvbmRzIHRvIG9uZQ0KPiBpbnN0YW5jZSBv ZiB0aGUgcm91dGluZyBwcm90b2NvbC4NCg0KSGVyZSwgYWdhaW4sIHRoYXQgd291bGQgd29yaywg YnV0IGl0IGRvZXNuJ3QgbG9vayB0byBtZSBhcyB0aGUgc2ltcGxlc3QgDQphcHByb2FjaC4NCg0K VGhhbmtzLA0KDQotVGhvbWFzDQoNCg0K From j.schoenwaelder@jacobs-university.de Wed Apr 4 09:32:23 2012 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 3AF1421F879F for ; Wed, 4 Apr 2012 09:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.272, 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 ibF5HMBwo0Rm for ; Wed, 4 Apr 2012 09:32: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 A631121F879B for ; Wed, 4 Apr 2012 09:32:22 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 05E7D20C46; Wed, 4 Apr 2012 18:32:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id F2q8XEN9qetL; Wed, 4 Apr 2012 18:32:21 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 80F0B20C37; Wed, 4 Apr 2012 18:32:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 06FD81E2EAE3; Wed, 4 Apr 2012 18:32:23 +0200 (CEST) Date: Wed, 4 Apr 2012 18:32:22 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120404163222.GB14879@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@netconfcentral.org, netmod@ietf.org References: <4F7AD909.9010407@netconfcentral.org> <20120403.142736.1908318793655906558.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120403.142736.1908318793655906558.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Should deviations be deprecated and a real conformance statement replace it? 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, 04 Apr 2012 16:32:23 -0000 On Tue, Apr 03, 2012 at 02:27:36PM +0200, Martin Bjorklund wrote: > I assume you now are talking about using features like the > netconf-light module use them? If so I agree with you - it is a > misuse to use features like this. Would an augment if-feature address your concerns? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Apr 4 12:41:51 2012 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 24CEE21F8615 for ; Wed, 4 Apr 2012 12:41:51 -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 FEIBk2nqAuo0 for ; Wed, 4 Apr 2012 12:41: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 8053A21F8613 for ; Wed, 4 Apr 2012 12:41:50 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 570B31200D88; Wed, 4 Apr 2012 21:41:48 +0200 (CEST) Date: Wed, 04 Apr 2012 21:41:47 +0200 (CEST) Message-Id: <20120404.214147.53927527.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120404163222.GB14879@elstar.local> References: <4F7AD909.9010407@netconfcentral.org> <20120403.142736.1908318793655906558.mbj@tail-f.com> <20120404163222.GB14879@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] Should deviations be deprecated and a real conformance statement replace it? 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, 04 Apr 2012 19:41:51 -0000 Juergen Schoenwaelder wrote: > On Tue, Apr 03, 2012 at 02:27:36PM +0200, Martin Bjorklund wrote: > > > I assume you now are talking about using features like the > > netconf-light module use them? If so I agree with you - it is a > > misuse to use features like this. > > Would an augment if-feature address your concerns? No you can't add an if-feature to an existing node through augmentation. If you have an if-feature statement in an augmentation, it affects the *augmented* nodes. Since this would be a new protocol, I'd simply define a new URI with query parameters in text, and send something like: urn:...:constrained-netconf?locking,subtree-filtering /martin From lhotka@cesnet.cz Tue Apr 10 04:10:54 2012 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 D3D2D21F87DA; Tue, 10 Apr 2012 04:10:54 -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 138c-FFPVQtp; Tue, 10 Apr 2012 04:10:49 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 69B6A21F87CC; Tue, 10 Apr 2012 04:10:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 7365E540DE3; Tue, 10 Apr 2012 13:10:47 +0200 (CEST) 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 S4TryRw5neEf; Tue, 10 Apr 2012 13:10:35 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 5E1405400FB; Tue, 10 Apr 2012 13:10:35 +0200 (CEST) From: Ladislav Lhotka To: thomas.morin@orange.com, rtg-ads@tools.ietf.org, rtg-dir@ietf.org, draft-ietf-netmod-routing-cfg.all@tools.ietf.org, netmod@ietf.org In-Reply-To: References: User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: thomas.morin@orange.com, rtg-ads@tools.ietf.org, rtg-dir@ietf.org, draft-ietf-netmod-routing-cfg.all@tools.ietf.org, netmod@ietf.org Date: Tue, 10 Apr 2012 13:10:34 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-routing-cfg 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, 10 Apr 2012 11:10:55 -0000 On Tue, 3 Apr 2012 16:57:29 +0200, wrote: ... > >> > >> --- Information on routes > >> > >> The Yang module let's the operator read the routing tables. It > >> looks like a very valid and useful thing (and not new, see RFC1213 > >> MIB). > >> > >> However, I'm wondering about the following points: > >> > >> - usually, a routing table may have multiple routes for a said > >> destination address, some being possibly less specific than others, > >> or inactive due to various reasons : it did not identify how these > >> specification allow the operator to see all routes of a routing > >> table for a said prefix, or all the most specific routes including > >> the inactive ones, or all the most specific actives routes when > >> there is more than one (required I think for ECMP support), etc. ? > >> it seems it would be worth to extend the get-route RPC to allow > >> expressing all these kind of questions > > > > The 'get-route' method doesn't try to be terribly general or > > extensible, it is mainly intended as a reminder to routing experts > > that YANG also allows for defining new RPC methods. I think it will > > be easier to decide what methods are needed as soon as there are data > > models for the major routing protocols, such as OSPF or BGP. >=20 > You might want to find a balance between doing things in these=20 > specifications and punting to future work and new extensions. Actually, there is also the generic "get" operation in NETCONF which allows= for querying state data and specifying various filters. This might be suff= icient for getting information from routing tables. On the other hand, we had a discussion with Martin Bj=C3=B6rklund in Paris = whether it is reasonable to expose routing tables as state data. The downsi= de is that if a client issues (perhaps inadvertently) a "get" without any f= ilters, the reply may contain the full BGP table and be therefore darn long= . I am not sure which alternative is better but if we decide not to expose = routing tables as state data, it will indeed be necessary to replicate the = functionality of "get" (including filters) for obtaining routes. =20=20=20 >=20 > It seems to me that, at the very least, the get-rpc should allow to=20 > return more than one route (all active ones) so as to be compatible with Yes, this is a good point. =20 > ECMP. Filtering between active and inactive routes would be I think=20 > fairly generic and relevant to add in these specs. Hmm, but the decision is based on parameters that are not defined in the ro= uting module - metrics, preferences etc. How can we specify the algorithm w= ithout knowing these? Also, in Paris I got another comment related to this, namely that some impl= ementations don't use a special forwarding table. It's true that e.g. Linux= selects the active route form a routing table on the fly (and uses a route= cache). So I am now considering the option of removing the forwarding tabl= e (FIB) from the spec. In that case the "get-route" would be an implementat= ion-independent way of learning the active route(s). ... >=20 >=20 > >> - (related to the previous point:) : I'm unclear if these specs > >> allow a get-route to match on different portions or attributes of a > >> routes (eg. get route for prefix X advertised by peer X, or having > >> been readvertised by AS Y...)... As I understand, there can be some > >> AFN/SAFI specific extensions, but no per-protocol extensions. Is > >> this a correct understanding ? If not, wouldn't it make sense to > >> make it more extensible ? > > > > There can be per-protocol extensions, too, it is also demonstrated in > > the RIP example. >=20 >=20 > I understand how the RIP example does extend the information *returned*=20 > by get-route. But I don't get how a protocol can extend the information=20 > on which get-rpc matches ? For instance, can I get-route to find the=20 > route for which tag =3D 42 ? (theoretical example, I'm not saying there's= =20 > a use for this) >=20 The "get-route" does not provide this possibility but it can be done using = the generic "get" operation with subtree filters. >=20 >=20 > >> - why restrict the get-route RPC to only query the special/default > >> "FIB" routing table ? it would seem useful to be able to query any > >> routing table. > > > > This could be done but it would bring new issues to consider - > > multiple candidate routes etc. The 'get-route' method is supposed to > > answer the simple question: "Which route will be used for forwarding > > packets to destination W.X.Y.Z?" >=20 > Two things: >=20 > - there is a strong, and possibly debatable, hypothesis here: that the=20 > operators that relies on Netconf/Yang will use this module with as the=20 > only need the need to know about forwarding. I am not sure I understand this point but I definitely assume that other (p= rotocol-specific) means for querying the routing system will be defined in = other modules. >=20 > - the "multiple candidate route" issue is, I think, something that needs= =20 > to be taken care of, even for the FIB ; if only as to take care of ECMP,= =20 > but also for use-cases such as IPFRR (where multiple next-hops are in=20 > the FIB for a said prefix, some of them will become active only when a=20 > certain failure arise) Yes, I agree. >=20 >=20 >=20 > >> --- Redistributing routes directly between routing protocols > >> > >> These specifications only allow the exchange of routes from a > >> routing protocol or routing table to a routing table, but not from > >> a routing protocol to another routing protocols. However, the > >> latter is something used a lot in practice (e.g. controlling > >> redistribution between two IGP areas). Of course, by using an > >> intermediate routing table you could achieve the same result, but > >> doesn't it look like extra overhead ? > > > > Some implementations (IOS, for example) redistribute routes between > > protocols while others (JUNOS, BIRD) use an intermediate routing > > table. But as you say, the former approach may be emulated with the > > latter. In the most typical case when two protocols are connected to > > the same (e.g. main) routing table, each protocol can use a filter to > > pull the routes originating from the other protocol. >=20 >=20 > Its often better when simple things could be doable in a simple way. >=20 > What are the drawbacks of allowing routes to be exchanged directly=20 > between routing protocols ? >=20 > (said otherwise: not allowing direct import/export between routing=20 > protocols looks like an arbitrary restriction; what is the driver for=20 > introducing this arbitrary restriction ? is this restriction worth the=20 > operational cost (more work to do to do protocol-to-protocol=20 > redistribution, more routing table to instantiate) ? Two reasons: 1. Allowing the exchanges between both routing tables and protocols would m= ake the system even=20 more complicated. 2. Routing protocols will mostly be defined elsewhere, so it seems to me it= is better to keep=20 their interface to the protocol-independent part as simple as possible. And it needn't really be any more complicated: an implementation may decide= to reserve a routing table exclusively for each routing instance and in th= is case there will be effectively no difference between the two cases. Yes,= there is some overhead, but some implementations use this approach (a sing= le routing table connected to each protocol instance) and I see no way how = this can be emulated if the only option was to exchange routes between prot= ocols.=20=20 Client sofware can certainly let the user pretend the exchange happens betw= een routing protocols. ... =20 > >> - the constraint that for a said routing protocols "For each > >> AFN/SAFI pair there may be at most one connected routing table." . > >> In the RFC4364 case, the global BGP routing process would push > >> routes to multiple VRFs. > > > > This is most likely not a problem because any number of recipient > > routing tables can be configured to receive (filtered) routes from > > the single routing table which is connected to a routing protocol, > > cf. the "recipient-routing-tables" list. >=20 > Understood, there is a way to make it work, but see discuss above, it=20 > seems to me as possibly useless overhead to alway need an intermediate=20 > routing table in such cases. I don't think it's a viable approach to provide all existing alternatives d= irectly in the same data model (I am old enough to remember the original PL= /1 programming language). The important point is that it is doable. Thanks, Lada --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Apr 10 04:19:58 2012 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 C72B021F861A; Tue, 10 Apr 2012 04:19:58 -0700 (PDT) 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 0KTs-HIZ-2kI; Tue, 10 Apr 2012 04:19:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A8F0D21F8610; Tue, 10 Apr 2012 04:19:57 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F1EC620C21; Tue, 10 Apr 2012 13:19:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ucymrjOhjFBL; Tue, 10 Apr 2012 13:19:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A3EA20C20; Tue, 10 Apr 2012 13:19:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B7D5A1E5C163; Tue, 10 Apr 2012 13:19:56 +0200 (CEST) Date: Tue, 10 Apr 2012 13:19:56 +0200 From: Juergen Schoenwaelder To: thomas.morin@orange.com, rtg-ads@tools.ietf.org, rtg-dir@ietf.org, draft-ietf-netmod-routing-cfg.all@tools.ietf.org, netmod@ietf.org Message-ID: <20120410111956.GA24800@elstar.local> Mail-Followup-To: thomas.morin@orange.com, rtg-ads@tools.ietf.org, rtg-dir@ietf.org, draft-ietf-netmod-routing-cfg.all@tools.ietf.org, netmod@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-routing-cfg 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: Tue, 10 Apr 2012 11:19:58 -0000 On Tue, Apr 10, 2012 at 01:10:34PM +0200, Ladislav Lhotka wrote: > On Tue, 3 Apr 2012 16:57:29 +0200, wrote: > > ... > > > >> > > >> --- Information on routes > > >> > > >> The Yang module let's the operator read the routing tables. It > > >> looks like a very valid and useful thing (and not new, see RFC1213 > > >> MIB). > > >> > > >> However, I'm wondering about the following points: > > >> > > >> - usually, a routing table may have multiple routes for a said > > >> destination address, some being possibly less specific than others, > > >> or inactive due to various reasons : it did not identify how these > > >> specification allow the operator to see all routes of a routing > > >> table for a said prefix, or all the most specific routes including > > >> the inactive ones, or all the most specific actives routes when > > >> there is more than one (required I think for ECMP support), etc. ? > > >> it seems it would be worth to extend the get-route RPC to allow > > >> expressing all these kind of questions > > > > > > The 'get-route' method doesn't try to be terribly general or > > > extensible, it is mainly intended as a reminder to routing experts > > > that YANG also allows for defining new RPC methods. I think it will > > > be easier to decide what methods are needed as soon as there are data > > > models for the major routing protocols, such as OSPF or BGP. > > > > You might want to find a balance between doing things in these > > specifications and punting to future work and new extensions. > > Actually, there is also the generic "get" operation in NETCONF which allows for querying state data and specifying various filters. This might be sufficient for getting information from routing tables. > > On the other hand, we had a discussion with Martin Björklund in Paris whether it is reasonable to expose routing tables as state data. The downside is that if a client issues (perhaps inadvertently) a "get" without any filters, the reply may contain the full BGP table and be therefore darn long. I am not sure which alternative is better but if we decide not to expose routing tables as state data, it will indeed be necessary to replicate the functionality of "get" (including filters) for obtaining routes. If NETCONF's is considered unusable in practice since it can return huge amounts of data if not used carefully, then IMHO needs to be fixed or deprecated. I think it is backwards to not model operational state because an unfiltered operation may not be a good idea. That said, how to best model operational state seems to remain a somewhat unresolved issue. /js (as contributor) -- 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 Tue Apr 10 04:53:28 2012 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 18FD321F85B5 for ; Tue, 10 Apr 2012 04:53:28 -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 xfwkZ6OQ1UK2 for ; Tue, 10 Apr 2012 04:53: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 1391C21F85AA for ; Tue, 10 Apr 2012 04:53:27 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 34AA413F868; Tue, 10 Apr 2012 13:53:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334058806; bh=y4wuiTgpeqJ0Slx21QfvyX0QDPUET41h8olNqIhwo6c=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Shvn/m6gVNJJBe8eT4+LyBYhkvwqU+L7anQcT1cDPVNvF0lQTPoo6YgET/6sfsTpU ve/leXAKDOjBSN6er8fxJmxyg9Mb+giYaja8qTxiOuUIzdMao4d556FOIZcN2gU5Ae iezU8We4KJvhetrGhWAnuUjWLntY6lBXiWVCttaA= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: <20120410111956.GA24800@elstar.local> Date: Tue, 10 Apr 2012 13:53:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7C25FEA3-2B75-4084-A834-D373FC8D7C63@nic.cz> References: <20120410111956.GA24800@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-routing-cfg 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, 10 Apr 2012 11:53:28 -0000 On Apr 10, 2012, at 1:19 PM, Juergen Schoenwaelder wrote: > On Tue, Apr 10, 2012 at 01:10:34PM +0200, Ladislav Lhotka wrote: >> On Tue, 3 Apr 2012 16:57:29 +0200, wrote: >>=20 >> ... >>=20 >>>>>=20 >>>>> --- Information on routes >>>>>=20 >>>>> The Yang module let's the operator read the routing tables. It >>>>> looks like a very valid and useful thing (and not new, see RFC1213 >>>>> MIB). >>>>>=20 >>>>> However, I'm wondering about the following points: >>>>>=20 >>>>> - usually, a routing table may have multiple routes for a said >>>>> destination address, some being possibly less specific than = others, >>>>> or inactive due to various reasons : it did not identify how these >>>>> specification allow the operator to see all routes of a routing >>>>> table for a said prefix, or all the most specific routes including >>>>> the inactive ones, or all the most specific actives routes when >>>>> there is more than one (required I think for ECMP support), etc. ? >>>>> it seems it would be worth to extend the get-route RPC to allow >>>>> expressing all these kind of questions >>>>=20 >>>> The 'get-route' method doesn't try to be terribly general or >>>> extensible, it is mainly intended as a reminder to routing experts >>>> that YANG also allows for defining new RPC methods. I think it will >>>> be easier to decide what methods are needed as soon as there are = data >>>> models for the major routing protocols, such as OSPF or BGP. >>>=20 >>> You might want to find a balance between doing things in these=20 >>> specifications and punting to future work and new extensions. >>=20 >> Actually, there is also the generic "get" operation in NETCONF which = allows for querying state data and specifying various filters. This = might be sufficient for getting information from routing tables. >>=20 >> On the other hand, we had a discussion with Martin Bj=F6rklund in = Paris whether it is reasonable to expose routing tables as state data. = The downside is that if a client issues (perhaps inadvertently) a "get" = without any filters, the reply may contain the full BGP table and be = therefore darn long. I am not sure which alternative is better but if we = decide not to expose routing tables as state data, it will indeed be = necessary to replicate the functionality of "get" (including filters) = for obtaining routes. >=20 > If NETCONF's is considered unusable in practice since it can > return huge amounts of data if not used carefully, then IMHO > needs to be fixed or deprecated. I think it is backwards to not model > operational state because an unfiltered operation may not be a > good idea. That said, how to best model operational state seems to I agree with this. > remain a somewhat unresolved issue. Interestingly, from a "RESTful" point of view the distinction between = configuration and state data seems largely artificial (leaving aside = statistics). For a device, an IP address is a piece of data (resource) = that has to be specified somehow and it doesn't matter whether it is = done through manual configuration, DHCP or otherwise. What's really relevant is a representation of device's state and a = specification of the parts of the state that may be modified via NETCONF = - in fact, the latter may also be an implementation-specific decision. = In other words, config true or false is just a matter of access rules. Lada >=20 > /js (as contributor) >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Apr 10 05:03:39 2012 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 4178021F85CC for ; Tue, 10 Apr 2012 05:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJv-LVsDpuMh for ; Tue, 10 Apr 2012 05:03:38 -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 B228521F85CD for ; Tue, 10 Apr 2012 05:03:38 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 135851200D59; Tue, 10 Apr 2012 14:03:36 +0200 (CEST) Date: Tue, 10 Apr 2012 14:03:35 +0200 (CEST) Message-Id: <20120410.140335.229183983909079586.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <7C25FEA3-2B75-4084-A834-D373FC8D7C63@nic.cz> References: <20120410111956.GA24800@elstar.local> <7C25FEA3-2B75-4084-A834-D373FC8D7C63@nic.cz> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] RtgDir review: draft-ietf-netmod-routing-cfg 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, 10 Apr 2012 12:03:39 -0000 Ladislav Lhotka wrote: > > On Apr 10, 2012, at 1:19 PM, Juergen Schoenwaelder wrote: > > If NETCONF's is considered unusable in practice since it can > > return huge amounts of data if not used carefully, then IMHO > > needs to be fixed or deprecated. I think it is backwards to not model > > operational state because an unfiltered operation may not be a > > good idea. That said, how to best model operational state seems to > > I agree with this. +1 > > remain a somewhat unresolved issue. > > Interestingly, from a "RESTful" point of view the distinction between > configuration and state data seems largely artificial (leaving aside > statistics). For a device, an IP address is a piece of data (resource) > that has to be specified somehow and it doesn't matter whether it is > done through manual configuration, DHCP or otherwise. > > What's really relevant is a representation of device's state and a > specification of the parts of the state that may be modified via > NETCONF - in fact, the latter may also be an implementation-specific > decision. In other words, config true or false is just a matter of > access rules. I don't think I agree with this. You can easily have two separate resources on the device; the operationally used ip address and the configured ip address. Both are in this case part of the device's "state". /martin From j.schoenwaelder@jacobs-university.de Tue Apr 10 05:45:04 2012 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 2902321F85C0 for ; Tue, 10 Apr 2012 05:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.113 X-Spam-Level: X-Spam-Status: No, score=-103.113 tagged_above=-999 required=5 tests=[AWL=0.136, 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 JwSyamvB+KGi for ; Tue, 10 Apr 2012 05:45:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCC521F8589 for ; Tue, 10 Apr 2012 05:45:03 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E0FD20C11; Tue, 10 Apr 2012 14:45:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mvt5RiCRtYkO; Tue, 10 Apr 2012 14:45:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F20EE20C12; Tue, 10 Apr 2012 14:45:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DEBF91E5C2DA; Tue, 10 Apr 2012 14:45:02 +0200 (CEST) Date: Tue, 10 Apr 2012 14:45:02 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120410124502.GA24964@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org References: <20120410111956.GA24800@elstar.local> <7C25FEA3-2B75-4084-A834-D373FC8D7C63@nic.cz> <20120410.140335.229183983909079586.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120410.140335.229183983909079586.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-routing-cfg 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: Tue, 10 Apr 2012 12:45:04 -0000 On Tue, Apr 10, 2012 at 02:03:35PM +0200, Martin Bjorklund wrote: > > > > Interestingly, from a "RESTful" point of view the distinction between > > configuration and state data seems largely artificial (leaving aside > > statistics). For a device, an IP address is a piece of data (resource) > > that has to be specified somehow and it doesn't matter whether it is > > done through manual configuration, DHCP or otherwise. > > > > What's really relevant is a representation of device's state and a > > specification of the parts of the state that may be modified via > > NETCONF - in fact, the latter may also be an implementation-specific > > decision. In other words, config true or false is just a matter of > > access rules. > > I don't think I agree with this. You can easily have two separate > resources on the device; the operationally used ip address and the > configured ip address. Both are in this case part of the device's > "state". I agree with Martin. /js -- 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 Tue Apr 10 06:12:45 2012 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 8886C21F8643 for ; Tue, 10 Apr 2012 06:12: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=[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 X4cbD0EbYiLY for ; Tue, 10 Apr 2012 06:12:45 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DA1E321F863F for ; Tue, 10 Apr 2012 06:12:44 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 1E7ED13F868; Tue, 10 Apr 2012 15:12:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334063564; bh=1TJZmXy68qoeNpdUjJntGIstKdx3H55vbIDs289TP/Y=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=c/SR3CCheusYugH/HnOtprNl1F8x9HirYXJ8P3cCcpK39TO9upAorSSQwRl+S9nj0 CiqUDvoDW46BWqIqObi21xpmFpkgXTgKgpX7gKWF17TvP3yRpOZMYpJLkUifwhFY01 jY4j+HcE8KC0+7oJtv9RN07aGjwsoGavvbVSWcdM= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120410.140335.229183983909079586.mbj@tail-f.com> Date: Tue, 10 Apr 2012 15:12:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <446C31D2-B4A0-4465-BA6E-AB9C42267026@nic.cz> References: <20120410111956.GA24800@elstar.local> <7C25FEA3-2B75-4084-A834-D373FC8D7C63@nic.cz> <20120410.140335.229183983909079586.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-routing-cfg 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, 10 Apr 2012 13:12:45 -0000 On Apr 10, 2012, at 2:03 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On Apr 10, 2012, at 1:19 PM, Juergen Schoenwaelder wrote: >>> If NETCONF's is considered unusable in practice since it can >>> return huge amounts of data if not used carefully, then IMHO >>> needs to be fixed or deprecated. I think it is backwards to not = model >>> operational state because an unfiltered operation may not be a >>> good idea. That said, how to best model operational state seems to >>=20 >> I agree with this. >=20 > +1 >=20 >>> remain a somewhat unresolved issue. >>=20 >> Interestingly, from a "RESTful" point of view the distinction between >> configuration and state data seems largely artificial (leaving aside >> statistics). For a device, an IP address is a piece of data = (resource) >> that has to be specified somehow and it doesn't matter whether it is >> done through manual configuration, DHCP or otherwise. >>=20 >> What's really relevant is a representation of device's state and a >> specification of the parts of the state that may be modified via >> NETCONF - in fact, the latter may also be an implementation-specific >> decision. In other words, config true or false is just a matter of >> access rules. >=20 > I don't think I agree with this. You can easily have two separate I thought you wouldn't. :-) > resources on the device; the operationally used ip address and the > configured ip address. Both are in this case part of the device's > "state". What it means is that you may offer a value through NETCONF but it may = or may not be taken into account. So the access rule is: you are allowed = to specify a value for this resource but it may not be applied.=20 I see your point - there is the "true" state on the one hand and a = blueprint for it submitted by NETCONF on the other. But still, I think = that a representation of the device state (no matter where it comes = from) is a good starting point. Lada =20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Tue Apr 10 08:06:36 2012 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 6E55211E8102 for ; Tue, 10 Apr 2012 08:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, 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 m5J5Na4ykH2M for ; Tue, 10 Apr 2012 08:06:35 -0700 (PDT) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id C595511E80CF for ; Tue, 10 Apr 2012 08:06:35 -0700 (PDT) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3AF6YJO001818 for ; Tue, 10 Apr 2012 11:06:34 -0400 Authentication-Results: cm-omr1 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:54705] helo=[192.168.0.9]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id E5/6D-23914-97C448F4; Tue, 10 Apr 2012 11:06:34 -0400 Message-ID: <4F844C7E.8030706@netconfcentral.org> Date: Tue, 10 Apr 2012 08:06:38 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ladislav Lhotka References: <20120410111956.GA24800@elstar.local> <7C25FEA3-2B75-4084-A834-D373FC8D7C63@nic.cz> <20120410.140335.229183983909079586.mbj@tail-f.com> <446C31D2-B4A0-4465-BA6E-AB9C42267026@nic.cz> In-Reply-To: <446C31D2-B4A0-4465-BA6E-AB9C42267026@nic.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-routing-cfg 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, 10 Apr 2012 15:06:36 -0000 On 04/10/2012 06:12 AM, Ladislav Lhotka wrote: > > On Apr 10, 2012, at 2:03 PM, Martin Bjorklund wrote: > >> Ladislav Lhotka wrote: >>> >>> On Apr 10, 2012, at 1:19 PM, Juergen Schoenwaelder wrote: >>>> If NETCONF's is considered unusable in practice since it can >>>> return huge amounts of data if not used carefully, then IMHO >>>> needs to be fixed or deprecated. I think it is backwards to not model >>>> operational state because an unfiltered operation may not be a >>>> good idea. That said, how to best model operational state seems to >>> >>> I agree with this. >> IMO, both and are problematic for large lists. NMS developers have asked me many times for "iterators" in NETCONF. Some implementations prefer to give 'startEntry' and 'maxEntries' parameters in addition to the target object, and make N requests, instead of getting every possible entry streamed at them in 1 request. Sometimes the developer just wants to discover the list instances (get just keys) and not retrieve every sub-tree. (Filters get too complicated for this task.) The issue is not config=true/false, but rather how to deal with retrieval of large lists. Andy >> +1 >> >>>> remain a somewhat unresolved issue. >>> >>> Interestingly, from a "RESTful" point of view the distinction between >>> configuration and state data seems largely artificial (leaving aside >>> statistics). For a device, an IP address is a piece of data (resource) >>> that has to be specified somehow and it doesn't matter whether it is >>> done through manual configuration, DHCP or otherwise. >>> >>> What's really relevant is a representation of device's state and a >>> specification of the parts of the state that may be modified via >>> NETCONF - in fact, the latter may also be an implementation-specific >>> decision. In other words, config true or false is just a matter of >>> access rules. >> >> I don't think I agree with this. You can easily have two separate > > I thought you wouldn't. :-) > >> resources on the device; the operationally used ip address and the >> configured ip address. Both are in this case part of the device's >> "state". > > What it means is that you may offer a value through NETCONF but it may or may not be taken into account. So the access rule is: you are allowed to specify a value for this resource but it may not be applied. > > I see your point - there is the "true" state on the one hand and a blueprint for it submitted by NETCONF on the other. But still, I think that a representation of the device state (no matter where it comes from) is a good starting point. > > Lada > > >> >> >> /martin > > -- > 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 Tue Apr 10 08:58:07 2012 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 A72F821F8554 for ; Tue, 10 Apr 2012 08:58: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 Mmu0ceTENpeV for ; Tue, 10 Apr 2012 08:58: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 AAA4D21F8596 for ; Tue, 10 Apr 2012 08:58:06 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id DEAC313F626; Tue, 10 Apr 2012 17:58:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334073486; bh=3rCa774UIpnlOkzS7tuuNn5O37s56D4qYygRF4asmd4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=tIjScDhB3Ty5PWkkORdSWFZCksmNRdOVqYu3SRT86xUCJj7M7bB1z3Rb2A0rRc61l Nf6hxAhbtLUtJVtTqqeJY3m/thsrNPeeCoGjfbmizXYFhTDSNOccMKRm+EepXGhCPa DLZVjktwKdeTbqO9++hhJfWIWJcj5dn05i56mDTA= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: <4F844C7E.8030706@netconfcentral.org> Date: Tue, 10 Apr 2012 17:58:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120410111956.GA24800@elstar.local> <7C25FEA3-2B75-4084-A834-D373FC8D7C63@nic.cz> <20120410.140335.229183983909079586.mbj@tail-f.com> <446C31D2-B4A0-4465-BA6E-AB9C42267026@nic.cz> <4F844C7E.8030706@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-routing-cfg 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, 10 Apr 2012 15:58:07 -0000 On Apr 10, 2012, at 5:06 PM, Andy Bierman wrote: > On 04/10/2012 06:12 AM, Ladislav Lhotka wrote: >>=20 >> On Apr 10, 2012, at 2:03 PM, Martin Bjorklund wrote: >>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>> On Apr 10, 2012, at 1:19 PM, Juergen Schoenwaelder wrote: >>>>> If NETCONF's is considered unusable in practice since it can >>>>> return huge amounts of data if not used carefully, then IMHO >>>>> needs to be fixed or deprecated. I think it is backwards to not = model >>>>> operational state because an unfiltered operation may not be = a >>>>> good idea. That said, how to best model operational state seems = to >>>>=20 >>>> I agree with this. >>>=20 >=20 >=20 > IMO, both and are problematic for large lists. > NMS developers have asked me many times for "iterators" in NETCONF. > Some implementations prefer to give 'startEntry' and 'maxEntries' But this cannot work for and since they return an XML = document. =20 > parameters in addition to the target object, and make N requests, = instead of > getting every possible entry streamed at them in 1 request. Sometimes > the developer just wants to discover the list instances (get just = keys) > and not retrieve every sub-tree. (Filters get too complicated for this = task.) This looks like a good reason for defining special methods for querying = routing tables.=20 >=20 > The issue is not config=3Dtrue/false, but rather how to deal with = retrieval > of large lists. Sure, although extremely long lists, which could be real showstoppers = for and , are more likely to be found in state data. Lada >=20 >=20 >=20 > Andy >=20 >=20 >>> +1 >>>=20 >>>>> remain a somewhat unresolved issue. >>>>=20 >>>> Interestingly, from a "RESTful" point of view the distinction = between >>>> configuration and state data seems largely artificial (leaving = aside >>>> statistics). For a device, an IP address is a piece of data = (resource) >>>> that has to be specified somehow and it doesn't matter whether it = is >>>> done through manual configuration, DHCP or otherwise. >>>>=20 >>>> What's really relevant is a representation of device's state and a >>>> specification of the parts of the state that may be modified via >>>> NETCONF - in fact, the latter may also be an = implementation-specific >>>> decision. In other words, config true or false is just a matter of >>>> access rules. >>>=20 >>> I don't think I agree with this. You can easily have two separate >>=20 >> I thought you wouldn't. :-) >>=20 >>> resources on the device; the operationally used ip address and the >>> configured ip address. Both are in this case part of the device's >>> "state". >>=20 >> What it means is that you may offer a value through NETCONF but it = may or may not be taken into account. So the access rule is: you are = allowed to specify a value for this resource but it may not be applied. >>=20 >> I see your point - there is the "true" state on the one hand and a = blueprint for it submitted by NETCONF on the other. But still, I think = that a representation of the device state (no matter where it comes = from) is a good starting point. >>=20 >> Lada >>=20 >>=20 >>>=20 >>>=20 >>> /martin >>=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 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Tue Apr 10 09:14:23 2012 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 8D2EF11E8111 for ; Tue, 10 Apr 2012 09:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=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 yiH43fFLFNBR for ; Tue, 10 Apr 2012 09:14:23 -0700 (PDT) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id 009FE11E80BE for ; Tue, 10 Apr 2012 09:14:22 -0700 (PDT) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3AGEMw3014773 for ; Tue, 10 Apr 2012 12:14:22 -0400 Authentication-Results: cm-omr11 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:55039] helo=[192.168.0.9]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id EA/EA-27126-D5C548F4; Tue, 10 Apr 2012 12:14:21 -0400 Message-ID: <4F845C61.6090602@netconfcentral.org> Date: Tue, 10 Apr 2012 09:14:25 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ladislav Lhotka References: <20120410111956.GA24800@elstar.local> <7C25FEA3-2B75-4084-A834-D373FC8D7C63@nic.cz> <20120410.140335.229183983909079586.mbj@tail-f.com> <446C31D2-B4A0-4465-BA6E-AB9C42267026@nic.cz> <4F844C7E.8030706@netconfcentral.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-routing-cfg 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, 10 Apr 2012 16:14:23 -0000 On 04/10/2012 08:58 AM, Ladislav Lhotka wrote: > > On Apr 10, 2012, at 5:06 PM, Andy Bierman wrote: > >> On 04/10/2012 06:12 AM, Ladislav Lhotka wrote: >>> >>> On Apr 10, 2012, at 2:03 PM, Martin Bjorklund wrote: >>> >>>> Ladislav Lhotka wrote: >>>>> >>>>> On Apr 10, 2012, at 1:19 PM, Juergen Schoenwaelder wrote: >>>>>> If NETCONF's is considered unusable in practice since it can >>>>>> return huge amounts of data if not used carefully, then IMHO >>>>>> needs to be fixed or deprecated. I think it is backwards to not model >>>>>> operational state because an unfiltered operation may not be a >>>>>> good idea. That said, how to best model operational state seems to >>>>> >>>>> I agree with this. >>>> >> >> >> IMO, both and are problematic for large lists. >> NMS developers have asked me many times for "iterators" in NETCONF. >> Some implementations prefer to give 'startEntry' and 'maxEntries' > > But this cannot work for and since they return an XML document. > They just use the top-element and return data as usual. I agree a new operation would probably be needed for this functionality. >> parameters in addition to the target object, and make N requests, instead of >> getting every possible entry streamed at them in 1 request. Sometimes >> the developer just wants to discover the list instances (get just keys) >> and not retrieve every sub-tree. (Filters get too complicated for this task.) > > This looks like a good reason for defining special methods for querying routing tables. > yes -- I think several vendors are not using config=false, but are instead defining RPC 'show' commands to sort of mirror the CLI. I think NMS developers realize it will be awhile before the CLI way of doing things is not tightly coupled to the programmatic API. Since YANG has the 'rpc-stmt', it doesn't matter that much which way it's done. >> >> The issue is not config=true/false, but rather how to deal with retrieval >> of large lists. > > Sure, although extremely long lists, which could be real showstoppers for and, are more likely to be found in state data. > I think even this data model will have large config=true lists on some implementations. The issue is the size of the XML document returned in the . Some applications would prefer to keep that to a reasonable size. Maybe it's just an implementation detail, but that's what developers think about. > Lada > Andy From mbj@tail-f.com Tue Apr 10 13:22:17 2012 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 BFA7F11E8139 for ; Tue, 10 Apr 2012 13:22:17 -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 c3Cooug9taUB for ; Tue, 10 Apr 2012 13:22:17 -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 96BD811E8137 for ; Tue, 10 Apr 2012 13:22:16 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id E0A2912008FC; Tue, 10 Apr 2012 22:22:14 +0200 (CEST) Date: Tue, 10 Apr 2012 22:22:13 +0200 (CEST) Message-Id: <20120410.222213.432297067.mbj@tail-f.com> To: andy@netconfcentral.org From: Martin Bjorklund In-Reply-To: <4F844C7E.8030706@netconfcentral.org> References: <20120410.140335.229183983909079586.mbj@tail-f.com> <446C31D2-B4A0-4465-BA6E-AB9C42267026@nic.cz> <4F844C7E.8030706@netconfcentral.org> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] RtgDir review: draft-ietf-netmod-routing-cfg 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, 10 Apr 2012 20:22:17 -0000 Andy Bierman wrote: > IMO, both and are problematic for large lists. > NMS developers have asked me many times for "iterators" in NETCONF. > Some implementations prefer to give 'startEntry' and 'maxEntries' > parameters in addition to the target object, and make N requests, instead of > getting every possible entry streamed at them in 1 request. Agreed. > Sometimes > the developer just wants to discover the list instances (get just keys) > and not retrieve every sub-tree. (Filters get too complicated for this task.) We use subtree filters for this; it is pretty trivial to construct such a filter. /martin From david.kessens@nsn.com Mon Apr 16 01:46:16 2012 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 E21FC21F8734 for ; Mon, 16 Apr 2012 01:46: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 XIkPQpGBJu4C for ; Mon, 16 Apr 2012 01:46:16 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 25AE221F8733 for ; Mon, 16 Apr 2012 01:46:15 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q3G8kDgO032534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 16 Apr 2012 10:46:13 +0200 Received: from localhost.localdomain ([10.138.48.245]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q3G8kAPk012771 for ; Mon, 16 Apr 2012 10:46:12 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.5/8.14.5) with ESMTP id q3G8k9uw010788 for ; Mon, 16 Apr 2012 01:46:09 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.5/8.14.5/Submit) id q3G8k8qP010787 for netmod@ietf.org; Mon, 16 Apr 2012 01:46:08 -0700 Date: Mon, 16 Apr 2012 01:46:07 -0700 From: David Kessens To: netmod@ietf.org Message-ID: <20120416084607.GB9989@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: 441 X-purgate-ID: 151667::1334565973-00003570-C128B7B3/0-0/0-0 Subject: [netmod] Adoption of: draft-bjorklund-netmod-snmp-cfg-02 (respond by 20120420) 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, 16 Apr 2012 08:46:17 -0000 Hi, During the netmod session at last IETF, there was no opposition to adopt: http://tools.ietf.org/id/draft-bjorklund-netmod-snmp-cfg-02.txt as a working group document. I would hereby like to give the working group a final chance to object against this proposal. Please respond to the mailing list by 20120420 if you don't agree that we adopt this document as a working group document. Thanks, David Kessens --- From randy_presuhn@mindspring.com Mon Apr 16 10:32:53 2012 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 619E511E809D for ; Mon, 16 Apr 2012 10:32:53 -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 umMXyAOtOvWh for ; Mon, 16 Apr 2012 10:32:49 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id D432411E809C for ; Mon, 16 Apr 2012 10:32:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=iwWesPD5iiCC5iIq4hnveesaJBZr8d9ReIddM8O+WoiS/9OwKd8kQNeWrAWq+0gs; 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.187.237.246] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SJpnE-0004aS-1m for netmod@ietf.org; Mon, 16 Apr 2012 13:32:49 -0400 Message-ID: <002f01cd1bf7$18f9ab60$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20120416084607.GB9989@nsn.com> Date: Mon, 16 Apr 2012 10:33:54 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f888dfd4aaa3a2a84d6c5e99976aba10b83350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.237.246 Subject: Re: [netmod] Adoption of: draft-bjorklund-netmod-snmp-cfg-02 (respondby 20120420) 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, 16 Apr 2012 17:32:53 -0000 Hi - While I suppose it's inevitable that this work will happen, I am nonetheless horrified by the way the I-D proposes that keys (and worse still, "passwords") be handled. This approach completely undermines the design of USM for preventing the compromise of one managed device causing the keys for another device to be revealed. The configuration management of keying material needs to be carefully separated from the rest, and needs to be done in a way that does not undercut the security of *all* managed devices in an administrative domain. Randy ----- Original Message ----- > From: "David Kessens" > To: > Sent: Monday, April 16, 2012 1:46 AM > Subject: [netmod] Adoption of: draft-bjorklund-netmod-snmp-cfg-02 (respondby 20120420) > > > Hi, > > During the netmod session at last IETF, there was no opposition to adopt: > > http://tools.ietf.org/id/draft-bjorklund-netmod-snmp-cfg-02.txt > > as a working group document. > > I would hereby like to give the working group a final chance to object > against this proposal. > > Please respond to the mailing list by 20120420 if you don't agree that we > adopt this document as a working group document. > > Thanks, > > David Kessens > --- > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Mon Apr 16 11:28:36 2012 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 BCBE521F8724 for ; Mon, 16 Apr 2012 11:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RF0JL2nbT9Ds for ; Mon, 16 Apr 2012 11:28:36 -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 C7BFB21F85EA for ; Mon, 16 Apr 2012 11:28:35 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 93A0D12008BF; Mon, 16 Apr 2012 20:28:33 +0200 (CEST) Date: Mon, 16 Apr 2012 20:28:32 +0200 (CEST) Message-Id: <20120416.202832.486818825.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <002f01cd1bf7$18f9ab60$6b01a8c0@oemcomputer> References: <20120416084607.GB9989@nsn.com> <002f01cd1bf7$18f9ab60$6b01a8c0@oemcomputer> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] Adoption of: draft-bjorklund-netmod-snmp-cfg-02 (respondby 20120420) 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, 16 Apr 2012 18:28:36 -0000 Hi, "Randy Presuhn" wrote: > Hi - > > While I suppose it's inevitable that this work will happen, I am > nonetheless horrified by the way the I-D proposes that keys > (and worse still, "passwords") be handled. This approach > completely undermines the design of USM for preventing > the compromise of one managed device causing the keys > for another device to be revealed. The configuration management > of keying material needs to be carefully separated from the > rest, and needs to be done in a way that does not undercut > the security of *all* managed devices in an administrative domain. The current draft specifies that only the localized key is ever stored in the config data store. I don't understand how that would undercut the security of all managed devices in an administrative domain. Nevertheless, it would be great to discuss alternative solutions to the problem (configuring keys). We have a proprietary solution for storing "sensitive information" like this, and that is to store locally encrypted values. However, this requires the encryption key to be stored somehow, and it cannot be part of the config itself. Thus, an extra step is needed in order to replace a device with a backup cofig; first somehow (off line typically) enter the same passphrase as was used for the old device, then copy-config the backup. /martin From randy_presuhn@mindspring.com Mon Apr 16 11:55:45 2012 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 3E75D11E809D for ; Mon, 16 Apr 2012 11:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.092 X-Spam-Level: X-Spam-Status: No, score=-100.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, 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 QVZhQ9aaZNIN for ; Mon, 16 Apr 2012 11:55:44 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9D93321F85B6 for ; Mon, 16 Apr 2012 11:55:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=SmgeyVGjHS66Wtnekok4/N9t/td4v36i1rpCLW2uLgy1dW7RZyZSmFABTjKSASTn; 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.187.237.246] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SJr5T-0000OJ-DH for netmod@ietf.org; Mon, 16 Apr 2012 14:55:43 -0400 Message-ID: <000401cd1c02$aedace60$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20120416084607.GB9989@nsn.com><002f01cd1bf7$18f9ab60$6b01a8c0@oemcomputer> <20120416.202832.486818825.mbj@tail-f.com> Date: Mon, 16 Apr 2012 11:56:49 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f88b99e300c5c6fdcf19776b971966cde5a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.237.246 Subject: Re: [netmod] Adoption of: draft-bjorklund-netmod-snmp-cfg-02 (respondby 20120420) 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, 16 Apr 2012 18:55:45 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Monday, April 16, 2012 11:28 AM > Subject: Re: [netmod] Adoption of: draft-bjorklund-netmod-snmp-cfg-02 (respondby 20120420) ... > The current draft specifies that only the localized key is ever stored > in the config data store. I don't understand how that would > undercut the security of all managed devices in an administrative > domain. Allowing a password (rather than a (localized) key) to be delivered to a (potentially compromised) managed device undercuts the security of all managed devices in the administrative domain. One of the reasons for using localized keys is to prevent the managed devices from being able to have a way to figure out the keys of other devices. I should allow a device to see a password only if I am willing to entrust the security of my entire network to that device. > Nevertheless, it would be great to discuss alternative solutions to > the problem (configuring keys). > > We have a proprietary solution for storing "sensitive information" > like this, and that is to store locally encrypted values. However, > this requires the encryption key to be stored somehow, and it cannot > be part of the config itself. Thus, an extra step is needed in order > to replace a device with a backup cofig; first somehow (off line > typically) enter the same passphrase as was used for the old device, > then copy-config the backup. Another security property of USM that the proposal loses is that with USM, even if the key update occurs in the clear, an evesdropper won't know what the new key is unless the evesdropper already knew the old key. I'm sure the folks who do key storage will have lots of ideas about how to implement something on the neconf client side, but the point is that the netconf server, if that is understood as the managed device, should never be given a password rather than a (localized) key. Randy From mbj@tail-f.com Mon Apr 16 13:21:26 2012 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 648A411E80E6 for ; Mon, 16 Apr 2012 13:21:26 -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 KisFS0aoGebL for ; Mon, 16 Apr 2012 13:21:26 -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 991AD11E808C for ; Mon, 16 Apr 2012 13:21:25 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 6C4181200D55; Mon, 16 Apr 2012 22:21:24 +0200 (CEST) Date: Mon, 16 Apr 2012 22:21:22 +0200 (CEST) Message-Id: <20120416.222122.489615035.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <000401cd1c02$aedace60$6b01a8c0@oemcomputer> References: <002f01cd1bf7$18f9ab60$6b01a8c0@oemcomputer> <20120416.202832.486818825.mbj@tail-f.com> <000401cd1c02$aedace60$6b01a8c0@oemcomputer> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] Adoption of: draft-bjorklund-netmod-snmp-cfg-02 (respondby 20120420) 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, 16 Apr 2012 20:21:26 -0000 "Randy Presuhn" wrote: > > From: "Martin Bjorklund" > I should allow a device to see a password only if I am willing to entrust > the security of my entire network to that device. > > > Nevertheless, it would be great to discuss alternative solutions to > > the problem (configuring keys). How would you solve this problem? I think the problem is not limited to USM keys, but keys/passwords in general. /martin From kwatsen@juniper.net Mon Apr 16 15:32:02 2012 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 DD7E721F85AC for ; Mon, 16 Apr 2012 15:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYOikKgSCnKm for ; Mon, 16 Apr 2012 15:32:02 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 458B521F85A7 for ; Mon, 16 Apr 2012 15:32:02 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT4yd3jSSj3VJjemjq9ls9tGu5TOAw6nr@postini.com; Mon, 16 Apr 2012 15:32:02 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 16 Apr 2012 15:31:56 -0700 From: Kent Watsen To: Andy Bierman , Ladislav Lhotka Date: Mon, 16 Apr 2012 15:31:54 -0700 Thread-Topic: [netmod] RtgDir review: draft-ietf-netmod-routing-cfg Thread-Index: Ac0XK4g2phG0eF32SZGLHGIi3GthSwE9PM0g Message-ID: <84600D05C20FF943918238042D7670FD48C1297892@EMBX01-HQ.jnpr.net> References: <20120410111956.GA24800@elstar.local> <7C25FEA3-2B75-4084-A834-D373FC8D7C63@nic.cz> <20120410.140335.229183983909079586.mbj@tail-f.com> <446C31D2-B4A0-4465-BA6E-AB9C42267026@nic.cz> <4F844C7E.8030706@netconfcentral.org> In-Reply-To: <4F844C7E.8030706@netconfcentral.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-routing-cfg 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, 16 Apr 2012 22:32:03 -0000 Andy Bierman wrote: > Sometimes > the developer just wants to discover the list instances (get just keys) > and not retrieve every sub-tree. (Filters get too complicated for this ta= sk.) Wouldn't Xpath filters support this case? From kwatsen@juniper.net Mon Apr 16 16:16:29 2012 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 6ABC011E80D1 for ; Mon, 16 Apr 2012 16:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5jetcB5gv35 for ; Mon, 16 Apr 2012 16:16:29 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id BDA8F11E807F for ; Mon, 16 Apr 2012 16:16:28 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKT4yoSILn750YvC+7mqWOIqsTckWR+1k3@postini.com; Mon, 16 Apr 2012 16:16:28 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 16 Apr 2012 16:16:17 -0700 From: Kent Watsen To: t.petch , Ladislav Lhotka , Andrew McGregor Date: Mon, 16 Apr 2012 16:16:14 -0700 Thread-Topic: logical-systems (was: review of draft-ietf-netmod-routing-cfg-02) Thread-Index: Ac0OYTxUPjITGI1bRoqAG2xvFUHGPwNv4w7g Message-ID: <84600D05C20FF943918238042D7670FD48C129791B@EMBX01-HQ.jnpr.net> References: <20120329.084030.108113872.mbj@tail-f.com><201203291134.q2TBYcIZ061366@idle.juniper.net> <20120329.141159.492740978.mbj@tail-f.com> <00fc01cd0e45$49e83760$4001a8c0@gateway.2wire.net> <004701cd0e58$a935d200$4001a8c0@gateway.2wire.net> In-Reply-To: <004701cd0e58$a935d200$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: [netmod] logical-systems (was: review of draft-ietf-netmod-routing-cfg-02) 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, 16 Apr 2012 23:16:29 -0000 I can't believe I missed the discussion about logical-routers, but it seems= not too late and I have some pretty defined thoughts about it. First off, note that the trend is to virtualize the entire system, not just= the "routing" part of it. For instance, I've seen virtualization implemen= ted on firewalls, routers, and switches. Sometimes, a small subset of the = data-model is virtualized (routing), but more often it's the entire shebang= . Defining an explicit tree in the data-model for the virtualized systems is = not ideal - bigger schema file, harder to understand, difficult to keep in = sync. The best implementation I ever saw was from NetScreen's ScreenOS pro= duct - they had a single data-model with per-node attributes indicating if = the node was "host-only" or "lsys-only" (lsys=3D=3D"logical system"), all o= ther nodes were considered shared by default. Also, it's a mistake to assume the host-system's configuration is a superse= t including the lsys configs. I've see some implementations where fetching= configuration on the host-system did not return any lsys-specfic configura= tion; you had to explicitly ask the logical-system for its configuration. To define a unified solution to span all these variations, we used a global= attribute to specify the xpath to where lsys-configs might be rooted in th= e host-system's config. If not specified, then it meant that they weren't = part of host-system's config. We did the same with rpcs, defined a mechanism to indicate when RPCs were a= vailable - host-only, lsys-only, or both (the default). =20 We also defined the notion of a "context". If SSH'd to a logical-system, y= ou would be in the logical-system's context. If SSH'd to the host-system, = you would be in the host-system's context, by default, but then could use s= pecial RPCs to enter a lsys's contexts, run RPCs there and what not, and th= en return to the host-system's context. The above covers basic support. The more complicated bit comes with object= -sharing, including heterogeneous lists, and immutables, and overrides. Mo= re on that later. Thanks, Kent From randy_presuhn@mindspring.com Mon Apr 16 19:15:02 2012 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 D787D21F8594 for ; Mon, 16 Apr 2012 19:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.045 X-Spam-Level: X-Spam-Status: No, score=-100.045 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 EV+-v0yUZIcm for ; Mon, 16 Apr 2012 19:15:01 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id B4BB021F858B for ; Mon, 16 Apr 2012 19:15:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=HlGt/G+o8LACiV3KUxRvmlrto4J3aB3ar4ojNu2xF2l+qlODNq6OWqUHWBPtPSEK; 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.187.237.246] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SJxwa-0001n0-BA for netmod@ietf.org; Mon, 16 Apr 2012 22:15:00 -0400 Message-ID: <000e01cd1c40$0d8f6b40$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <002f01cd1bf7$18f9ab60$6b01a8c0@oemcomputer><20120416.202832.486818825.mbj@tail-f.com><000401cd1c02$aedace60$6b01a8c0@oemcomputer> <20120416.222122.489615035.mbj@tail-f.com> Date: Mon, 16 Apr 2012 19:16:07 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f88bb79b07f118a1f5ddaaaf88756ca8b36350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.237.246 Subject: Re: [netmod] Adoption of: draft-bjorklund-netmod-snmp-cfg-02 (respondby 20120420) 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, 17 Apr 2012 02:15:03 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Monday, April 16, 2012 1:21 PM > Subject: Re: [netmod] Adoption of: draft-bjorklund-netmod-snmp-cfg-02 (respondby 20120420) > > "Randy Presuhn" wrote: > > > From: "Martin Bjorklund" > > I should allow a device to see a password only if I am willing to entrust > > the security of my entire network to that device. > > > > > Nevertheless, it would be great to discuss alternative solutions to > > > the problem (configuring keys). > > How would you solve this problem? I think the problem is not limited > to USM keys, but keys/passwords in general. USM is one possible answer, but probably not a palatable one for this group. :-) There have been lots of different technologies thrown at the key management problem space over the years. I think it would be worthwhile to have a security guru specializing in that topic (and that's certainly not me!!) give the WG some pointers to what the current state of the art is, while recognizing that there are some ways in which the demands put on SNMP keys may seem a little different from the requirements of user single-signon. (Think notifications and remotely executing disman scripts, for starters). I think it's also worthwhile to spend a little time thinking about what the configuration management requirements for keying material really are. For example, is being able to revert the key configuration to what it was at sometime in the past actually a desirable thing? Do you want old keys to be recoverable, or thoroughly scrubbed? (some jurisdictions may ask for the former, but security-conscious folks will probably want the latter) I'm not going to pretend that I know what the final answer should be, but I'm pretty confident that in general one would *not* want reverting a system's operational configuration to yesterday's "known working" state to also cause any intervening key updates to be undone. Randy From mbj@tail-f.com Tue Apr 17 00:15:34 2012 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 F185C21F84D3 for ; Tue, 17 Apr 2012 00:15:34 -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 zb29fwkFcfjT for ; Tue, 17 Apr 2012 00:15:34 -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 E789B21F84D2 for ; Tue, 17 Apr 2012 00:15:20 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id BE2C512008BC; Tue, 17 Apr 2012 09:15:18 +0200 (CEST) Date: Tue, 17 Apr 2012 09:15:17 +0200 (CEST) Message-Id: <20120417.091517.535788825.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <84600D05C20FF943918238042D7670FD48C129791B@EMBX01-HQ.jnpr.net> References: <004701cd0e58$a935d200$4001a8c0@gateway.2wire.net> <84600D05C20FF943918238042D7670FD48C129791B@EMBX01-HQ.jnpr.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] logical-systems 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, 17 Apr 2012 07:15:35 -0000 Hi, Kent Watsen wrote: > > I can't believe I missed the discussion about logical-routers, but it seems not > too late and I have some pretty defined thoughts about it. > > First off, note that the trend is to virtualize the entire system, not just the > "routing" part of it. For instance, I've seen virtualization implemented on > firewalls, routers, and switches. Sometimes, a small subset of the data-model > is virtualized (routing), but more often it's the entire shebang. > > Defining an explicit tree in the data-model for the virtualized systems is not > ideal - bigger schema file, harder to understand, difficult to keep in sync. I very much agree with this. > The best implementation I ever saw was from NetScreen's ScreenOS product - they > had a single data-model with per-node attributes indicating if the node was > "host-only" or "lsys-only" (lsys=="logical system"), all other nodes were > considered shared by default. Hmmm... this works well if the data model is tied to the implementation. A standard data model can probably never have these attributes. So some other mechanism is needed to indicate e.g. which objects are shared. > We also defined the notion of a "context". If SSH'd to a logical-system, you > would be in the logical-system's context. If SSH'd to the host-system, you > would be in the host-system's context, by default, but then could use special > RPCs to enter a lsys's contexts, run RPCs there and what not, and then return > to the host-system's context. I agree that this is probably the way to go. It is similar to how it is done in SNMPv3. > The above covers basic support. The more complicated bit comes with > object-sharing, including heterogeneous lists, and immutables, and overrides. > More on that later. Ok. So, what is your conclusion wrt draft-ietf-netmod-routing-cfg? /martin From lhotka@nic.cz Tue Apr 17 01:21:20 2012 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 AE9D521F85A5 for ; Tue, 17 Apr 2012 01:21:19 -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 qqlxCbje+ihn for ; Tue, 17 Apr 2012 01:21:14 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id ECDCC21F8606 for ; Tue, 17 Apr 2012 01:21:11 -0700 (PDT) Received: from [IPv6:2001:67c:64:42:6461:7faa:5c26:7b8c] (unknown [IPv6:2001:67c:64:42:6461:7faa:5c26:7b8c]) by mail.nic.cz (Postfix) with ESMTPSA id ECCF113F67F; Tue, 17 Apr 2012 10:21:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334650871; bh=UuG0PYWyhlNnS7bzp2YJZeFpCZdDfqb4OMk9PWKtHjo=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=LO+9NsChkwZzde62l2lJMwOCaksXa6X6ivZgDF8xSCtuLkVi+veF9DCCaQsCpcu5v gnHYXUN88EoefKTovotu8IAggqLdhtp3ePIXyGAooot75zxQ1e0pKFud11JLExfAbg NvHlycGsNMlfeulmA82EnoOn9pC0E9NiiFiSpBq8= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <84600D05C20FF943918238042D7670FD48C129791B@EMBX01-HQ.jnpr.net> Date: Tue, 17 Apr 2012 10:21:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <249A4398-58F5-41E4-9325-45A38FB3CAC2@nic.cz> References: <20120329.084030.108113872.mbj@tail-f.com><201203291134.q2TBYcIZ061366@idle.juniper.net> <20120329.141159.492740978.mbj@tail-f.com> <00fc01cd0e45$49e83760$4001a8c0@gateway.2wire.net> <004701cd0e58$a935d200$4001a8c0@gateway.2wire.net> <84600D05C20FF943918238042D7670FD48C129791B@EMBX01-HQ.jnpr.net> To: Kent Watsen X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] logical-systems (was: review of draft-ietf-netmod-routing-cfg-02) 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, 17 Apr 2012 08:21:20 -0000 On Apr 17, 2012, at 1:16 AM, Kent Watsen wrote: >=20 > I can't believe I missed the discussion about logical-routers, but it = seems not too late and I have some pretty defined thoughts about it. >=20 > First off, note that the trend is to virtualize the entire system, not = just the "routing" part of it. For instance, I've seen virtualization = implemented on firewalls, routers, and switches. Sometimes, a small = subset of the data-model is virtualized (routing), but more often it's = the entire shebang. OK, but this requires support from the level of the entire system, which = is not present in the existing modules yet. On the other hand, at least = one use case for the routing subsystem virtualization has been = identified - MPLS/BGP VPNs.=20 >=20 > Defining an explicit tree in the data-model for the virtualized = systems is not ideal - bigger schema file, harder to understand, = difficult to keep in sync. The best implementation I ever saw was from = NetScreen's But this is not what the routing module does, right? There is only one = (schema) tree which is supposed to be used by both types of router = instances. > ScreenOS product - they had a single data-model with per-node = attributes indicating if the node was "host-only" or "lsys-only" = (lsys=3D=3D"logical system"), all other nodes were considered shared by = default. This could be implemented by adding a "host/lsys" switch and then using = "when" or "must" constraints at appropriate places. And it can be done = by a module which implements this kind of logic via augmenting. >=20 > Also, it's a mistake to assume the host-system's configuration is a = superset including the lsys configs. I've see some implementations = where fetching configuration on the host-system did not return any = lsys-specfic configuration; you had to explicitly ask the logical-system = for its configuration. Does this mistake appear in the routing data model? I don't think so. >=20 > To define a unified solution to span all these variations, we used a = global attribute to specify the xpath to where lsys-configs might be = rooted in the host-system's config. If not specified, then it meant = that they weren't part of host-system's config. >=20 > We did the same with rpcs, defined a mechanism to indicate when RPCs = were available - host-only, lsys-only, or both (the default). Are there any obstacles why this cannot be done by augmenting the = existing data model? > =20 >=20 > We also defined the notion of a "context". If SSH'd to a = logical-system, you would be in the logical-system's context. If SSH'd = to the host-system, you would be in the host-system's context, by = default, but then could use special RPCs to enter a lsys's contexts, run = RPCs there and what not, and then return to the host-system's context. This is an interesting idea but if I understand it correctly, this would = require support from the NETCONF protocol which is not there. My main concern is that the deadline for the core routing data model is = this August, so we don't really have time for any sweeping changes and = substantial additions. I'd appreciate suggestions for changes that are = reasonably compatible with the given time frame. =46rom the reviews so far I got the impression that the possibility of = defining multiple router instances is quite welcome. Lada =20 >=20 > The above covers basic support. The more complicated bit comes with = object-sharing, including heterogeneous lists, and immutables, and = overrides. More on that later. >=20 > Thanks, > Kent >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Apr 17 01:28:47 2012 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 AC9F221F85A3 for ; Tue, 17 Apr 2012 01:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.142 X-Spam-Level: X-Spam-Status: No, score=-103.142 tagged_above=-999 required=5 tests=[AWL=0.107, 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 x78FiWoVcqi3 for ; Tue, 17 Apr 2012 01:28:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 51D1F21F8596 for ; Tue, 17 Apr 2012 01:28:43 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 400E720C55; Tue, 17 Apr 2012 10:28:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id G6YyR--Vyp1J; Tue, 17 Apr 2012 10:28:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F2DC20C4F; Tue, 17 Apr 2012 10:28:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B6D631E675EA; Tue, 17 Apr 2012 10:28:42 +0200 (CEST) Date: Tue, 17 Apr 2012 10:28:41 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20120417082841.GA53986@elstar.local> Mail-Followup-To: Ladislav Lhotka , Kent Watsen , "netmod@ietf.org" References: <20120329.084030.108113872.mbj@tail-f.com> <201203291134.q2TBYcIZ061366@idle.juniper.net> <20120329.141159.492740978.mbj@tail-f.com> <00fc01cd0e45$49e83760$4001a8c0@gateway.2wire.net> <004701cd0e58$a935d200$4001a8c0@gateway.2wire.net> <84600D05C20FF943918238042D7670FD48C129791B@EMBX01-HQ.jnpr.net> <249A4398-58F5-41E4-9325-45A38FB3CAC2@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <249A4398-58F5-41E4-9325-45A38FB3CAC2@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] logical-systems (was: review of draft-ietf-netmod-routing-cfg-02) 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: Tue, 17 Apr 2012 08:28:47 -0000 On Tue, Apr 17, 2012 at 10:21:10AM +0200, Ladislav Lhotka wrote: > > We also defined the notion of a "context". If SSH'd to a logical-system, you would be in the logical-system's context. If SSH'd to the host-system, you would be in the host-system's context, by default, but then could use special RPCs to enter a lsys's contexts, run RPCs there and what not, and then return to the host-system's context. > > This is an interesting idea but if I understand it correctly, this would require support from the NETCONF protocol which is not there. > > My main concern is that the deadline for the core routing data model is this August, so we don't really have time for any sweeping changes and substantial additions. I'd appreciate suggestions for changes that are reasonably compatible with the given time frame. > > From the reviews so far I got the impression that the possibility of defining multiple router instances is quite welcome. I tend to agree that multiple router instances are reasonably understood and that this is in scope of the routing data model. The more general problem, how to deal with virtualization, requires a much more fundamental discussion how to do this properly with NETCONF/YANG. /js (speaking as contributor) -- 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 Tue Apr 17 01:33:26 2012 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 6ACA121F85F4 for ; Tue, 17 Apr 2012 01:33:26 -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 gr9GcfK2o5zj for ; Tue, 17 Apr 2012 01:33: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 5A40121F85E6 for ; Tue, 17 Apr 2012 01:33:21 -0700 (PDT) Received: from [IPv6:2001:67c:64:42:6461:7faa:5c26:7b8c] (unknown [IPv6:2001:67c:64:42:6461:7faa:5c26:7b8c]) by mail.nic.cz (Postfix) with ESMTPSA id 7DF7713F67F; Tue, 17 Apr 2012 10:33:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334651600; bh=qmJd9yUs9Eoqd2ylOeocARL9ErxcMk+b8KbN4eDtJVU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=IRP5yKk83eH91aPqFIa+0Go5KWZisWkkbOWu5i9f8SWk6x/Tg74HlGMsCn2hUHxsb MccbSxd29I+s5FBPeJXgjYveh6XIGKUexUrce+o1kh2Gs0CyJyg884Df4mbaRi4vRK rJM8QeHjUcEO7EQ/y5UdeT3hNU1AL5DwSgCtbI58= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120417.091517.535788825.mbj@tail-f.com> Date: Tue, 17 Apr 2012 10:33:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6404652A-4785-4373-A9CC-DB6C2562147D@nic.cz> References: <004701cd0e58$a935d200$4001a8c0@gateway.2wire.net> <84600D05C20FF943918238042D7670FD48C129791B@EMBX01-HQ.jnpr.net> <20120417.091517.535788825.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] logical-systems 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, 17 Apr 2012 08:33:26 -0000 On Apr 17, 2012, at 9:15 AM, Martin Bjorklund wrote: > Hi, >=20 > Kent Watsen wrote: >>=20 >> I can't believe I missed the discussion about logical-routers, but it = seems not >> too late and I have some pretty defined thoughts about it. >>=20 >> First off, note that the trend is to virtualize the entire system, = not just the >> "routing" part of it. For instance, I've seen virtualization = implemented on >> firewalls, routers, and switches. Sometimes, a small subset of the = data-model >> is virtualized (routing), but more often it's the entire shebang. >>=20 >> Defining an explicit tree in the data-model for the virtualized = systems is not >> ideal - bigger schema file, harder to understand, difficult to keep = in sync. >=20 > I very much agree with this. Same here, but if I am not mistaken, in Paris you proposed to use = separate schema subtrees for physical and logical routers, in order to = avoid the extra level of hierarchy in the case where there are no = logical routers. >=20 >> The best implementation I ever saw was from NetScreen's ScreenOS = product - they >> had a single data-model with per-node attributes indicating if the = node was >> "host-only" or "lsys-only" (lsys=3D=3D"logical system"), all other = nodes were >> considered shared by default. >=20 > Hmmm... this works well if the data model is tied to the > implementation. A standard data model can probably never have these > attributes. So some other mechanism is needed to indicate e.g. which > objects are shared. Yes, this could/should be done in other modules that need it, via = augments. >=20 >> We also defined the notion of a "context". If SSH'd to a = logical-system, you >> would be in the logical-system's context. If SSH'd to the = host-system, you >> would be in the host-system's context, by default, but then could use = special >> RPCs to enter a lsys's contexts, run RPCs there and what not, and = then return >> to the host-system's context. >=20 > I agree that this is probably the way to go. It is similar to how it > is done in SNMPv3. Can you outline the necessary steps for implementing this? >=20 >> The above covers basic support. The more complicated bit comes with >> object-sharing, including heterogeneous lists, and immutables, and = overrides. >> More on that later. >=20 > Ok. >=20 >=20 > So, what is your conclusion wrt draft-ietf-netmod-routing-cfg? I second this question. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Apr 17 01:41:35 2012 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 4F06021F85E5 for ; Tue, 17 Apr 2012 01:41:35 -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_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 s6gvWHxk036h for ; Tue, 17 Apr 2012 01:41:34 -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 BD7C821F8568 for ; Tue, 17 Apr 2012 01:41:34 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id B7A9412008BC; Tue, 17 Apr 2012 10:41:33 +0200 (CEST) Date: Tue, 17 Apr 2012 10:41:31 +0200 (CEST) Message-Id: <20120417.104131.499427634.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <6404652A-4785-4373-A9CC-DB6C2562147D@nic.cz> References: <84600D05C20FF943918238042D7670FD48C129791B@EMBX01-HQ.jnpr.net> <20120417.091517.535788825.mbj@tail-f.com> <6404652A-4785-4373-A9CC-DB6C2562147D@nic.cz> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] logical-systems 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, 17 Apr 2012 08:41:35 -0000 Ladislav Lhotka wrote: > > On Apr 17, 2012, at 9:15 AM, Martin Bjorklund wrote: > > > Hi, > > > > Kent Watsen wrote: > >> The best implementation I ever saw was from NetScreen's ScreenOS product - > >> they > >> had a single data-model with per-node attributes indicating if the node was > >> "host-only" or "lsys-only" (lsys=="logical system"), all other nodes were > >> considered shared by default. > > > > Hmmm... this works well if the data model is tied to the > > implementation. A standard data model can probably never have these > > attributes. So some other mechanism is needed to indicate e.g. which > > objects are shared. > > Yes, this could/should be done in other modules that need it, via augments. The problem is that this vitualization is a property of the implementation, not of the data model. A system w/o virtualization will have a single instance of foo.yang, but another device might have one instance of foo.yang per "logical system". So it is not feasible to use data model annotations for this. > >> We also defined the notion of a "context". If SSH'd to a logical-system, > >> you > >> would be in the logical-system's context. If SSH'd to the host-system, you > >> would be in the host-system's context, by default, but then could use > >> special > >> RPCs to enter a lsys's contexts, run RPCs there and what not, and then > >> return > >> to the host-system's context. > > > > I agree that this is probably the way to go. It is similar to how it > > is done in SNMPv3. > > Can you outline the necessary steps for implementing this? rpc get-contexts { output { leaf-list context-name { type string; } } } rpc enter-context { input { leaf context-name { type string; } } // maybe the output is a list of capabilities in this context description "On success, the NETCONF session now is 'jailed' in the new context." } rpc exit-context; /martin From andrewmcgr@gmail.com Tue Apr 17 01:55:23 2012 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 7445021F856D for ; Tue, 17 Apr 2012 01:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 nonS4KnntJ58 for ; Tue, 17 Apr 2012 01:55:22 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id D6AD921F861D for ; Tue, 17 Apr 2012 01:55:22 -0700 (PDT) Received: by dady13 with SMTP id y13so11156013dad.27 for ; Tue, 17 Apr 2012 01:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=YXoS94MsGOo/aPFIopMM0I+KpX82hssJalWbAz8dNjE=; b=M+ggNZNyG0gQ9MFf+7HEf+IFoXPAYcQDJnuE4CprtYZvdqBgDA4J8jQjg/MG7UgkFr q/9Sj8w3XVdFT6Y2ymt7UPxlyESBnY4UWop5TLG5/6GgCSQgkmsk3xwB3V2o2DNSWioe tokN5MvLfKXD7rjDHGLeQ8nFQXinvip0tjCtKslKKLBljgw6kv2u1LILPkDsdRQR/vsF gAOLgYPpfvczKgyZcdOB28qi5unJPb7eqp2SBPHviBk57PUGcXYGRPU4FBJzM9JdWYlz W+c//rpc8bO0D6q8tGwQhupQ0+7znXLj/qWt7xWWXjEeIheIQKTIVoA+ANpDY3ickjY3 Vh6A== Received: by 10.68.224.99 with SMTP id rb3mr34919145pbc.79.1334652922594; Tue, 17 Apr 2012 01:55:22 -0700 (PDT) Received: from andrewm-lo.lan (198.239.69.111.dynamic.snap.net.nz. [111.69.239.198]) by mx.google.com with ESMTPS id d4sm20153175pbr.32.2012.04.17.01.55.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Apr 2012 01:55:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_77EDCDE5-B98F-4B0C-ABC9-BA4F08EFF0B8"; protocol="application/pkcs7-signature"; micalg=sha1 From: Andrew McGregor In-Reply-To: <249A4398-58F5-41E4-9325-45A38FB3CAC2@nic.cz> Date: Tue, 17 Apr 2012 20:55:14 +1200 Message-Id: <3DC88944-7DA1-4F4A-83E3-4F0F715BD0EE@gmail.com> References: <20120329.084030.108113872.mbj@tail-f.com><201203291134.q2TBYcIZ061366@idle.juniper.net> <20120329.141159.492740978.mbj@tail-f.com> <00fc01cd0e45$49e83760$4001a8c0@gateway.2wire.net> <004701cd0e58$a935d200$4001a8c0@gateway.2wire.net> <84600D05C20FF943918238042D7670FD48C129791B@EMBX01-HQ.jnpr.net> <249A4398-58F5-41E4-9325-45A38FB3CAC2@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.1257) Cc: "netmod@ietf.org" Subject: Re: [netmod] logical-systems (was: review of draft-ietf-netmod-routing-cfg-02) 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, 17 Apr 2012 08:55:23 -0000 --Apple-Mail=_77EDCDE5-B98F-4B0C-ABC9-BA4F08EFF0B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 17/04/2012, at 8:21 PM, Ladislav Lhotka wrote: >=20 > On Apr 17, 2012, at 1:16 AM, Kent Watsen wrote: >=20 >>=20 >> I can't believe I missed the discussion about logical-routers, but it = seems not too late and I have some pretty defined thoughts about it. >>=20 >> First off, note that the trend is to virtualize the entire system, = not just the "routing" part of it. For instance, I've seen = virtualization implemented on firewalls, routers, and switches. = Sometimes, a small subset of the data-model is virtualized (routing), = but more often it's the entire shebang. >=20 > OK, but this requires support from the level of the entire system, = which is not present in the existing modules yet. On the other hand, at = least one use case for the routing subsystem virtualization has been = identified - MPLS/BGP VPNs.=20 >=20 >>=20 >> Defining an explicit tree in the data-model for the virtualized = systems is not ideal - bigger schema file, harder to understand, = difficult to keep in sync. The best implementation I ever saw was from = NetScreen's >=20 > But this is not what the routing module does, right? There is only one = (schema) tree which is supposed to be used by both types of router = instances. So, fully virtualised routers is one thing, but partial virtualisation = where one system has multiple protocol instances is another. MPLS/BGP = VPNs are one example of that sort of behaviour, our 'VRF Lite' partial = virtualisation is another, and linux network namespaces could be a = third. In each case, there's an entirely separate routing table and = protocol instances, but only one system, and I think it worth reflecting = that in the data model. Andrew= --Apple-Mail=_77EDCDE5-B98F-4B0C-ABC9-BA4F08EFF0B8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFLjCCBSow ggQSoAMCAQICEQDMQ2ZKvgsUYA5oQg5SjWfVMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMTAwMTAwMDAwMFoXDTEyMDkzMDIzNTk1OVowJTEj MCEGCSqGSIb3DQEJARYUYW5kcmV3bWNnckBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQC+buTRxzSXTQmMyUqaokLJit3xU5WVudxHijhKbGRSTgJ867L/v8+rNhSoFwCV MdKIu/M7apWgGkkA+MT/LjDFj63jLT+4nTTLIojXZdoezbpp/rQ2ViSbi54AjhZBQ5X+yH2xcXmG KpDhZjeZC1bvKNvBtdOHCAcrx1Ys1BNj+AhwridEX/KD0cq5xSsJhjDggF6XSUOsaiqBHR6fiQMi 7gH8EuFBh83oklb/pdreg1fQ7gKJk/Me/atIbE1gtbIR88oaCtXoHfZxgkFwagwMtBHdkxN+wcZy 9xx78el9Lxrjx2nMq50hRlj/bqg/m4rSox7//DKfx7bfKNZAiSMDAgMBAAGjggHkMIIB4DAfBgNV HSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUXOXqNkq6sNbrD8B41dPko8Gs JucwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysG AQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATAr MCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9j cnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRh bmRyZXdtY2dyQGdtYWlsLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAgmf81vnsAnbcmIAyyqvEKxAK jRHerfreN10DK1ISkUJ//U4uffQV8sAGDtyIErzVFsW6NYRmFCMSE20M1ffbFpWUmXCtm/YTlkf1 5STVjTMNshDzMDhpjx99Z2J5RBJPZpXjwmpQnfKwB7zft9TcUSIb9FvZm33EKdF/XlS12U4Q9fsj 2shZf88RituX2+fCWfHoTWiFEhFUkLRtWf1YpgHpEXr82nqROxs/aWNlqtLnwTTu2ULr/WpUaRDs kom8gFZkMgw5kRfLpSXRrCFSORsZzkH2ooRxaJY7wMwZaCUS1am9DuwVy7gehoc3ZsjsDkMObZeu kx7Cg7GxIkgo+zGCA64wggOqAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzENmSr4LFGAOaEIOUo1n1TAJBgUrDgMCGgUAoIIB2TAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MTcwODU1MTVaMCMGCSqGSIb3DQEJBDEWBBQ15AIv wnMbVGuV2Z6aOT4AFfIOcDCBugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAzENmSr4LFGAOaEIOUo1n1TCBvAYLKoZIhvcNAQkQAgsxgayggakw gZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDMQ2ZKvgsUYA5oQg5SjWfVMA0G CSqGSIb3DQEBAQUABIIBAC59mMa+EjoUvU/wGYWNXzjk1LjN8eYh47JgXuuCMbje3ExVzXwwoWhj eARMMd9nLO55U2sxk7owOCmfKwJffwoecXSrBhCzHFaI37VrntlBirJ2ASpaEvEtl/0zX1ChzOQi U+RCe1a4kmyFdgchviUJdLmFvy8E4lJQ9+dEDKaASQ6mwgSGIDEerZyJWTjhnWMrBR7ealZRqBmp TMwJA3+6F81MsTA7pwX0tk1JKQxN1jQrdNUt/3tIyZ0pLRreaA7EtZE3GuvCuK78xyDfTqw8h5n8 pEXcTgFlmmMkKa3CB+uL8OG2qq+BNS3LJs/I5lnnCjgEq1MdWodZ+zAnrsYAAAAAAAA= --Apple-Mail=_77EDCDE5-B98F-4B0C-ABC9-BA4F08EFF0B8-- From lhotka@nic.cz Tue Apr 17 02:27:46 2012 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 6C53921F861F for ; Tue, 17 Apr 2012 02:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_34=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 1qmr-ZL0ltew for ; Tue, 17 Apr 2012 02:27: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 3255921F8611 for ; Tue, 17 Apr 2012 02:27:40 -0700 (PDT) Received: from [IPv6:2001:67c:64:42:a5d6:dd6a:d97:a08f] (unknown [IPv6:2001:67c:64:42:a5d6:dd6a:d97:a08f]) by mail.nic.cz (Postfix) with ESMTPSA id CDE4F14086D; Tue, 17 Apr 2012 11:27:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334654860; bh=jm9i1KQZ/lHYhcjMcjZJzCHeqDHRtXiAuwcfLigxj9s=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wOD5TA3OuFysFlOU1+Cy0NmTS+FYsj0iS6E2uDN4wewoIU7GexJWaV/LmRZq5I2Fv 3kyFjNNP3cDx1L80/JX0D/Br7pRqoWGPT0BZKUS7DP3XjkZXp/ragFFNLrtoj2Ak6A 6AO2L1dy4NAScd1pylXPJdbpNf1MZHZjqtYOuLDs= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120417.104131.499427634.mbj@tail-f.com> Date: Tue, 17 Apr 2012 11:27:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <84600D05C20FF943918238042D7670FD48C129791B@EMBX01-HQ.jnpr.net> <20120417.091517.535788825.mbj@tail-f.com> <6404652A-4785-4373-A9CC-DB6C2562147D@nic.cz> <20120417.104131.499427634.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] logical-systems 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, 17 Apr 2012 09:27:46 -0000 On Apr 17, 2012, at 10:41 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On Apr 17, 2012, at 9:15 AM, Martin Bjorklund wrote: >>=20 >>> Hi, >>>=20 >>> Kent Watsen wrote: >=20 >>>> The best implementation I ever saw was from NetScreen's ScreenOS = product - >>>> they >>>> had a single data-model with per-node attributes indicating if the = node was >>>> "host-only" or "lsys-only" (lsys=3D=3D"logical system"), all other = nodes were >>>> considered shared by default. >>>=20 >>> Hmmm... this works well if the data model is tied to the >>> implementation. A standard data model can probably never have these >>> attributes. So some other mechanism is needed to indicate e.g. = which >>> objects are shared. >>=20 >> Yes, this could/should be done in other modules that need it, via = augments. >=20 > The problem is that this vitualization is a property of the > implementation, not of the data model. A system w/o virtualization > will have a single instance of foo.yang, but another device might have > one instance of foo.yang per "logical system". So it is not feasible > to use data model annotations for this. Why not? We can have a switch in foo.yang distinguishing these two cases = and then conditional contents depending on this switch where necessary. >=20 >>>> We also defined the notion of a "context". If SSH'd to a = logical-system, >>>> you >>>> would be in the logical-system's context. If SSH'd to the = host-system, you >>>> would be in the host-system's context, by default, but then could = use >>>> special >>>> RPCs to enter a lsys's contexts, run RPCs there and what not, and = then >>>> return >>>> to the host-system's context. >>>=20 >>> I agree that this is probably the way to go. It is similar to how = it >>> is done in SNMPv3. >>=20 >> Can you outline the necessary steps for implementing this? >=20 > rpc get-contexts { > output { > leaf-list context-name { > type string; > } > } > } >=20 > rpc enter-context { > input { > leaf context-name { > type string; > } > } > // maybe the output is a list of capabilities in this context > description > "On success, the NETCONF session now is 'jailed' in the > new context." > } >=20 > rpc exit-context; This seems to have been accomplished in a "RESTful" way in the current = model by exposing the individual contexts as entries of the "router" = list. The "RPC" approach would remove one level from the data hierarchy, = but are there any other benefits? I can imagine a client software = implementing this context-oriented view for a human user and internally = working with the list of router instances. Lada =20 >=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Apr 17 02:35:49 2012 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 E8BDF21F8576 for ; Tue, 17 Apr 2012 02:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 kT3em9RiV1MP for ; Tue, 17 Apr 2012 02:35:48 -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 40C4921F863E for ; Tue, 17 Apr 2012 02:35:48 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 4EB7C12008BC; Tue, 17 Apr 2012 11:35:47 +0200 (CEST) Date: Tue, 17 Apr 2012 11:35:44 +0200 (CEST) Message-Id: <20120417.113544.526474665.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <6404652A-4785-4373-A9CC-DB6C2562147D@nic.cz> <20120417.104131.499427634.mbj@tail-f.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] logical-systems 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, 17 Apr 2012 09:35:49 -0000 Ladislav Lhotka wrote: > > On Apr 17, 2012, at 10:41 AM, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > >> > >> On Apr 17, 2012, at 9:15 AM, Martin Bjorklund wrote: > >> > >>> Hi, > >>> > >>> Kent Watsen wrote: > > > >>>> The best implementation I ever saw was from NetScreen's ScreenOS product - > >>>> they > >>>> had a single data-model with per-node attributes indicating if the node > >>>> was > >>>> "host-only" or "lsys-only" (lsys=="logical system"), all other nodes were > >>>> considered shared by default. > >>> > >>> Hmmm... this works well if the data model is tied to the > >>> implementation. A standard data model can probably never have these > >>> attributes. So some other mechanism is needed to indicate e.g. which > >>> objects are shared. > >> > >> Yes, this could/should be done in other modules that need it, via augments. > > > > The problem is that this vitualization is a property of the > > implementation, not of the data model. A system w/o virtualization > > will have a single instance of foo.yang, but another device might have > > one instance of foo.yang per "logical system". So it is not feasible > > to use data model annotations for this. > > Why not? We can have a switch in foo.yang distinguishing these two cases and > then conditional contents depending on this switch where necessary. Because you would have to design all your data models - including IETF models - to be prepared for virtualization. And you would have to figure out and design for all the different virtualization scenarios that Kent mentioned. > >>>> We also defined the notion of a "context". If SSH'd to a logical-system, > >>>> you > >>>> would be in the logical-system's context. If SSH'd to the host-system, > >>>> you > >>>> would be in the host-system's context, by default, but then could use > >>>> special > >>>> RPCs to enter a lsys's contexts, run RPCs there and what not, and then > >>>> return > >>>> to the host-system's context. > >>> > >>> I agree that this is probably the way to go. It is similar to how it > >>> is done in SNMPv3. > >> > >> Can you outline the necessary steps for implementing this? > > > > rpc get-contexts { > > output { > > leaf-list context-name { > > type string; > > } > > } > > } > > > > rpc enter-context { > > input { > > leaf context-name { > > type string; > > } > > } > > // maybe the output is a list of capabilities in this context > > description > > "On success, the NETCONF session now is 'jailed' in the > > new context." > > } > > > > rpc exit-context; > > This seems to have been accomplished in a "RESTful" way in the current model by > exposing the individual contexts as entries of the "router" list. The "RPC" > approach would remove one level from the data hierarchy, but are there any > other benefits? You remove the definition of this virtualization context from the data model, making the data model cleaner. You support multiple virtualization scenarios. /martin From wjhns1@hardakers.net Tue Apr 17 07:09:44 2012 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 4ECE221F84F3 for ; Tue, 17 Apr 2012 07:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 dJqBhoX+aDKH for ; Tue, 17 Apr 2012 07:09:43 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A4A21F84EC for ; Tue, 17 Apr 2012 07:09:43 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id D724276E; Tue, 17 Apr 2012 07:09:42 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" References: <002f01cd1bf7$18f9ab60$6b01a8c0@oemcomputer> <20120416.202832.486818825.mbj@tail-f.com> <000401cd1c02$aedace60$6b01a8c0@oemcomputer> <20120416.222122.489615035.mbj@tail-f.com> <000e01cd1c40$0d8f6b40$6b01a8c0@oemcomputer> Date: Tue, 17 Apr 2012 07:09:40 -0700 In-Reply-To: <000e01cd1c40$0d8f6b40$6b01a8c0@oemcomputer> (Randy Presuhn's message of "Mon, 16 Apr 2012 19:16:07 -0700") Message-ID: <0l8vhujvq3.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Adoption of: draft-bjorklund-netmod-snmp-cfg-02 (respondby 20120420) 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, 17 Apr 2012 14:09:44 -0000 "Randy Presuhn" writes: > There have been lots of different technologies thrown at the key > management problem space over the years. I think it would be > worthwhile to have a security guru specializing in that topic (and > that's certainly not me!!) give the WG some pointers to what the > current state of the art is I think the current state of the art with respect to shared secrets (eg, passwords) is quite simple: don't do it. For exactly the reasons that are coming up here: configuring a bunch of boxes with a shared secret means all boxes have access to it (or in the case of USM, a fortunately local copy). I'd say the management station should be delivering localized keys and that's the best you can achieve. Netconf, fortunately, should always run over an encrypted protocol and thus is safe to deliver a localized copy. You could, if really paranoid, define a negotiated feature such that the localized key config object would only be available when an encrypted session was in use. [I understand the desire to not deliver even those like the keychange algorithm achieves, but even the USM is typically configured the first time by manual initialization of the secret outside USM and probably frequently still over the network]. The state of the art, however, is typically to use public/private key solutions instead and thus delivery of the public key of the opposite side only requires that it not be modified and disclosure isn't a concern. IE, SNMP over (D)TLS (RFC6353: configuration of which is defined in the draft) or SNMP over SSH (RFC5592: which there are not configuration objects for at the moment). -- Wes Hardaker SPARTA, Inc. From andy@netconfcentral.org Tue Apr 17 08:05:40 2012 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 0746B11E80BD for ; Tue, 17 Apr 2012 08:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, 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 ebkQPBFBhRut for ; Tue, 17 Apr 2012 08:05:39 -0700 (PDT) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id 93B2811E80BB for ; Tue, 17 Apr 2012 08:05:37 -0700 (PDT) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3HF5aJn025154 for ; Tue, 17 Apr 2012 11:05:36 -0400 Authentication-Results: cm-omr9 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:36529] helo=[192.168.0.9]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 91/4D-19853-0C68D8F4; Tue, 17 Apr 2012 11:05:36 -0400 Message-ID: <4F8D86C0.8080008@netconfcentral.org> Date: Tue, 17 Apr 2012 08:05:36 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Martin Bjorklund References: <6404652A-4785-4373-A9CC-DB6C2562147D@nic.cz> <20120417.104131.499427634.mbj@tail-f.com> <20120417.113544.526474665.mbj@tail-f.com> In-Reply-To: <20120417.113544.526474665.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] logical-systems 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, 17 Apr 2012 15:05:40 -0000 On 04/17/2012 02:35 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> >> On Apr 17, 2012, at 10:41 AM, Martin Bjorklund wrote: >> >>> Ladislav Lhotka wrote: >>>> >>>> On Apr 17, 2012, at 9:15 AM, Martin Bjorklund wrote: >>>> >>>>> Hi, >>>>> >>>>> Kent Watsen wrote: >>> >>>>>> The best implementation I ever saw was from NetScreen's ScreenOS product - >>>>>> they >>>>>> had a single data-model with per-node attributes indicating if the node >>>>>> was >>>>>> "host-only" or "lsys-only" (lsys=="logical system"), all other nodes were >>>>>> considered shared by default. >>>>> >>>>> Hmmm... this works well if the data model is tied to the >>>>> implementation. A standard data model can probably never have these >>>>> attributes. So some other mechanism is needed to indicate e.g. which >>>>> objects are shared. >>>> >>>> Yes, this could/should be done in other modules that need it, via augments. >>> >>> The problem is that this vitualization is a property of the >>> implementation, not of the data model. A system w/o virtualization >>> will have a single instance of foo.yang, but another device might have >>> one instance of foo.yang per "logical system". So it is not feasible >>> to use data model annotations for this. >> >> Why not? We can have a switch in foo.yang distinguishing these two cases and >> then conditional contents depending on this switch where necessary. > > Because you would have to design all your data models - including IETF > models - to be prepared for virtualization. And you would have to > figure out and design for all the different virtualization scenarios > that Kent mentioned. > I agree -- a logical system that appears to the client as a self-contained device should just implement modules (and data instances) that are part of that logical system. There is going to be some separate config on the physical system that will tell the implementation how to create logical systems (e.g. per-VLAN). >>>>>> We also defined the notion of a "context". If SSH'd to a logical-system, >>>>>> you >>>>>> would be in the logical-system's context. If SSH'd to the host-system, >>>>>> you >>>>>> would be in the host-system's context, by default, but then could use >>>>>> special >>>>>> RPCs to enter a lsys's contexts, run RPCs there and what not, and then >>>>>> return >>>>>> to the host-system's context. >>>>> >>>>> I agree that this is probably the way to go. It is similar to how it >>>>> is done in SNMPv3. >>>> This is too restrictive, and does not really fit the 'isolation' use-case. It would be complicated to define a mapping from logical system to physical system, so each logical system can be accessed from the physical device. There may be instance-identifier translation, etc. >>>> Can you outline the necessary steps for implementing this? >>> >>> rpc get-contexts { >>> output { >>> leaf-list context-name { >>> type string; >>> } >>> } >>> } >>> >>> rpc enter-context { >>> input { >>> leaf context-name { >>> type string; >>> } >>> } >>> // maybe the output is a list of capabilities in this context >>> description >>> "On success, the NETCONF session now is 'jailed' in the >>> new context." >>> } >>> >>> rpc exit-context; >> The SNMP way is to specify the context in every PDU, not to enter some new 'in context X' state. >> This seems to have been accomplished in a "RESTful" way in the current model by >> exposing the individual contexts as entries of the "router" list. The "RPC" >> approach would remove one level from the data hierarchy, but are there any >> other benefits? > > You remove the definition of this virtualization context from the data > model, making the data model cleaner. You support multiple > virtualization scenarios. > > > /martin Andy From kwatsen@juniper.net Tue Apr 17 11:29:55 2012 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 5A8B011E80B8 for ; Tue, 17 Apr 2012 11:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 5JVPIN+F3-BR for ; Tue, 17 Apr 2012 11:29:54 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id BEFD511E80A0 for ; Tue, 17 Apr 2012 11:29:52 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT422mifu5pfJjxQ+UqXZj8//3PvCftN/@postini.com; Tue, 17 Apr 2012 11:29:52 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 17 Apr 2012 11:29:41 -0700 From: Kent Watsen To: Ladislav Lhotka , Martin Bjorklund Date: Tue, 17 Apr 2012 11:29:39 -0700 Thread-Topic: [netmod] logical-systems Thread-Index: Ac0cdMBDbI3rMZNwTZWc029HOhcz4gAURSJQ Message-ID: <84600D05C20FF943918238042D7670FD48C1297D36@EMBX01-HQ.jnpr.net> References: <004701cd0e58$a935d200$4001a8c0@gateway.2wire.net> <84600D05C20FF943918238042D7670FD48C129791B@EMBX01-HQ.jnpr.net> <20120417.091517.535788825.mbj@tail-f.com> <6404652A-4785-4373-A9CC-DB6C2562147D@nic.cz> In-Reply-To: <6404652A-4785-4373-A9CC-DB6C2562147D@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] logical-systems 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, 17 Apr 2012 18:29:55 -0000 >> So, what is your conclusion wrt draft-ietf-netmod-routing-cfg? > > I second this question. I'm not a routing guy, which is why I didn't review the draft before. Taking a quick look, I see container "routing" has list "router". This mak= es sense to me, as each LR is not having delegated administrative access. = Logical-systems are primarily distinguished as having distinct admin access= ... In yesterday's posting, I wasn't reacting to the draft so much as some of t= he discussion in the "review of draft-ietf-netmod-routing-cfg-02" thread. = I changed the email-subject to reflect that it wasn't intended to be a revi= ew of the routing draft, sorry if that wasn't clear. Hopefully I've now cl= arified that I don't actually have an issue with the draft as is. Thanks, Kent From bclaise@cisco.com Thu Apr 19 05:12:15 2012 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 B6B4021F847C for ; Thu, 19 Apr 2012 05:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.018, 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 atJUK502J6Nm for ; Thu, 19 Apr 2012 05:12:10 -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 73B5221F842F for ; Thu, 19 Apr 2012 05:12:10 -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 q3JCC5dn017024; Thu, 19 Apr 2012 14:12:05 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3JCC5Km011268; Thu, 19 Apr 2012 14:12:05 +0200 (CEST) Message-ID: <4F900112.40200@cisco.com> Date: Thu, 19 Apr 2012 14:12:02 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Juergen Schoenwaelder References: <4F8D93A7.2060403@cisco.com> In-Reply-To: <4F8D93A7.2060403@cisco.com> X-Forwarded-Message-Id: <4F8D93A7.2060403@cisco.com> Content-Type: multipart/alternative; boundary="------------040308020005020505090003" Cc: Ron Bonica , netmod-chairs@tools.ietf.org, NETMOD Working Group Subject: [netmod] New AD review of draft-ietf-netmod-smi-yang-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: Thu, 19 Apr 2012 12:12:15 -0000 This is a multi-part message in MIME format. --------------040308020005020505090003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Juergen, I'm performing the (new) AD review of draft-ietf-netmod-smi-yang-04. Lucky you, an extra pair of eyes specifically looking at your draft - 1. Introduction This document describes a translation of SMIv2 [RFC2578], [RFC2579], [RFC2580] MIB modules into YANG [RFC6020] modules, enabling read-only access to data objects defined in SMIv2 MIB modules via NETCONF. The mapping is illustrated by examples showing the translation of parts of the IF-MIB [RFC2863], the DIFFSERV-MIB [RFC3289], and the RMON2- MIB [RFC4502] SMIv2 module. read-only access of read-only MIB variables, or read-only access of read-only and read-write MIB variables. I guessed the former, but, while reading through the draft, I was always wondering: Why do we have this limitation? After reading the entire draft, I found the answer in section 11. We should have at a very minimum a pointer somewhere in the intro, with a sentence such as: "the reasons why ... are explained in section 11", or even better the explanation way earlier in the draft... for example in the intro. - Section 11. Implementing Configuration Data Nodes The translation of SMIv2 MIB modules into YANG modules defined above is read-only. The translation are not read-only: "The results of the translation of SMIv2 MIB modules into YANG modules, even if objects are read-write, consists of read-only objects." - SMIv1 modules may be converted to YANG by first following the rules in [RFC3584] to convert the SMIv1 module to SMIv2, then following the rules in this document to convert to YANG. I thought it was a MUST? SMIv1 modules MUST be first converted to SMIv2 before... Replacing "SMIv1 modules may be converted" by "SMIv1 modules can be converted" would also solve it. - Section 2. Mapping of Well Known Types The mappings shown in Appendix A may impact the imports of the generated YANG module since some SMIv2 types and textual conventions map to YANG types defined in the ietf-yang-types and ietf-inet-types YANG modules defined in [RFC6021] and the ietf-yang-smiv2 YANG module defined in this document. What do you mean by "may impact"? You want to say that you may have to import the ietf-yang-types and ietf-inet-types YANG modules? - Section 3. Translation of SMIv2 Modules and SMIv2 IMPORT Clauses SMIv2 modules are mapped to corresponding YANG modules. The YANG module name MUST be the same as the SMIv2 module name. ... when doing the translation, when the information model is the same, or when ... - Remember the discussion in OPS-DIR about documentating all the SMI TCs. Will we have the same issues with YANG typedef? I see two solutions: 1. We document all the typedef on a WIKI Pros: not much administration, a simple script can extract all the typedef from the IETF YANG modules Cons: need to be maintained (basically, all the IETF MIB modules must reside at the same location) 2. We ask IANA to maintain the typedef for us Cons: extra process: every new typdef in YANG module must be registered in IANA - Section 4.1 o Each SMIv2 REVISION clause is mapped to a YANG revision statement. The revision is identified by the date argument of the SMIv2 REVISION clause. DESCRIPTION sub-clauses of REVISION clauses are mapped to corresponding description statement nested in revision clauses. Do you see an issue with an initial MIB module, translated into a YANG module, then both the MIB modules and YANG modules are updated independently? What's happening in this case with the "revision" and "prefix"? Some more guidelines in such a case would be welcome. - leaf protocolDirLocalIndex { type leafref { path "/rmon2-mib:RMON2-MIB/" + "rmon2-mib:protocolDirTable/" + "rmon2-mib:protocolDirEntryf/" <------------------- f ? + "rmon2-mib:protocolDirLocalIndex"; } } // ... leaf protocolDirLocalIndex_2 { type leafref { path "/rmon2-mib:RMON2-MIB/" + "rmon2-mib:protocolDirTable/" + "rmon2-mib:protocolDirEntry/" + "rmon2-mib:protocolDirLocalIndex"; } } - Appendix A. Mapping of Well Known Types (normative) Would be nice to express that 1. this is fully in line with table 1 and table 2 in RFC6020 2. it complements these tables - please address http://www.ietf.org/mail-archive/web/netmod/current/msg06534.html - please address http://www.ietf.org/mail-archive/web/netmod/current/msg06484.html - please address the security directory review "secdir review of draft-ietf-netmod-smi-yang-04", from leifj@sunet.se Regards, Benoit. --------------040308020005020505090003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Juergen,

I'm performing the (new) AD review of draft-ietf-netmod-smi-yang-04.
Lucky you, an extra pair of eyes specifically looking at your draft

- 1.  Introduction

   This document describes a translation of SMIv2 [RFC2578], [RFC2579],
   [RFC2580] MIB modules into YANG [RFC6020] modules, enabling read-only
   access to data objects defined in SMIv2 MIB modules via NETCONF.  The
   mapping is illustrated by examples showing the translation of parts
   of the IF-MIB [RFC2863], the DIFFSERV-MIB [RFC3289], and the RMON2-
   MIB [RFC4502] SMIv2 module.

read-only access of read-only MIB variables, or read-only access of read-only and read-write MIB variables.
I guessed the former, but, while reading through the draft, I was always wondering: Why do we have this limitation?
After reading the entire draft, I found the answer in section 11.
We should have at a very minimum a pointer somewhere in the intro, with a sentence such as: "the reasons why ... are explained in section 11", or even better the explanation way earlier in the draft... for example in the intro.

- Section 11.  Implementing Configuration Data Nodes

   The translation of SMIv2 MIB modules into YANG modules defined above
   is read-only.

The translation are not read-only: "The results of the translation of SMIv2 MIB modules into YANG modules, even if objects are read-write, consists of read-only objects."


-    SMIv1 modules may be converted to YANG by first following the rules
   in [RFC3584] to convert the SMIv1 module to SMIv2, then following the
   rules in this document to convert to YANG.

I thought it was a MUST? SMIv1 modules MUST be first converted to SMIv2 before...
Replacing "SMIv1 modules may be converted" by "SMIv1 modules can be converted" would also solve it.

- Section 2.  Mapping of Well Known Types

  The mappings shown in Appendix A may impact the imports of the
   generated YANG module since some SMIv2 types and textual conventions
   map to YANG types defined in the ietf-yang-types and ietf-inet-types
   YANG modules defined in [RFC6021] and the ietf-yang-smiv2 YANG module
   defined in this document. 

What do you mean by "may impact"? You want to say that you may have to import the ietf-yang-types and ietf-inet-types YANG modules?

- Section 3.  Translation of SMIv2 Modules and SMIv2 IMPORT Clauses

   SMIv2 modules are mapped to corresponding YANG modules.  The YANG
   module name MUST be the same as the SMIv2 module name.

... when doing the translation, when the information model is the same, or when ...

- Remember the discussion in OPS-DIR about documentating all the SMI TCs. Will we have the same issues with YANG typedef?
I see two solutions:
1. We document all the typedef on a WIKI
    Pros: not much administration, a simple script can extract all the typedef from the IETF YANG modules
    Cons: need to be maintained (basically, all the IETF MIB modules must reside at the same location)
2. We ask IANA to maintain the typedef for us
    Cons: extra process: every new typdef in YANG module must be registered in IANA

- Section 4.1
   o  Each SMIv2 REVISION clause is mapped to a YANG revision statement.
      The revision is identified by the date argument of the SMIv2
      REVISION clause.  DESCRIPTION sub-clauses of REVISION clauses are
      mapped to corresponding description statement nested in revision
      clauses.

Do you see an issue with an initial MIB module, translated into a YANG module, then both the MIB modules and YANG modules are updated independently? What's happening in this case with the "revision" and "prefix"?
Some more guidelines in such a case would be welcome.


-   leaf protocolDirLocalIndex {
         type leafref {
           path "/rmon2-mib:RMON2-MIB/"
              + "rmon2-mib:protocolDirTable/"
              + "rmon2-mib:protocolDirEntryf/"                          <------------------- f ?
              + "rmon2-mib:protocolDirLocalIndex";
         }
       }

       // ...

       leaf protocolDirLocalIndex_2 {
         type leafref {
           path "/rmon2-mib:RMON2-MIB/"
              + "rmon2-mib:protocolDirTable/"
              + "rmon2-mib:protocolDirEntry/"
              + "rmon2-mib:protocolDirLocalIndex";
         }
       }

- Appendix A.  Mapping of Well Known Types (normative)
Would be nice to express that
1. this is fully in line with table 1 and table 2 in RFC6020
2. it complements these tables


- please address http://www.ietf.org/mail-archive/web/netmod/current/msg06534.html

- please address http://www.ietf.org/mail-archive/web/netmod/current/msg06484.html

- please address the security directory review "secdir review of draft-ietf-netmod-smi-yang-04", from leifj@sunet.se

Regards, Benoit.



--------------040308020005020505090003-- From internet-drafts@ietf.org Fri Apr 20 07:22:21 2012 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 3ED7821F8748; Fri, 20 Apr 2012 07:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, 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 RhERjSOtbT6S; Fri, 20 Apr 2012 07:22:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C8521F86E2; Fri, 20 Apr 2012 07:22:19 -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.00 Message-ID: <20120420142219.20837.46464.idtracker@ietfa.amsl.com> Date: Fri, 20 Apr 2012 07:22:19 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-smi-yang-05.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, 20 Apr 2012 14:22:21 -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 Workin= g Group of the IETF. Title : Translation of SMIv2 MIB Modules to YANG Modules Author(s) : Juergen Schoenwaelder Filename : draft-ietf-netmod-smi-yang-05.txt Pages : 44 Date : 2012-04-20 YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules for use with the SNMP protocol. This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only (config false) access to data objects defined in SMIv2 MIB modules via NETCONF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-smi-yang-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-smi-yang-05.txt From j.schoenwaelder@jacobs-university.de Fri Apr 20 07:26:53 2012 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 A7A1A21F86EC for ; Fri, 20 Apr 2012 07:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.172 X-Spam-Level: X-Spam-Status: No, score=-103.172 tagged_above=-999 required=5 tests=[AWL=0.077, 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 TcGLNzWJ0Hrs for ; Fri, 20 Apr 2012 07:26: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 E1CF421F84CE for ; Fri, 20 Apr 2012 07:26:52 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CCBBD20D2F; Fri, 20 Apr 2012 16:26:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id bFRLLJnsZlCd; Fri, 20 Apr 2012 16:26:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6870B20D32; Fri, 20 Apr 2012 16:26:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A03AB1E8F077; Fri, 20 Apr 2012 16:26:52 +0200 (CEST) Date: Fri, 20 Apr 2012 16:26:52 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120420142652.GA78894@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20120420142219.20837.46464.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120420142219.20837.46464.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] I-D Action: draft-ietf-netmod-smi-yang-05.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, 20 Apr 2012 14:26:53 -0000 Hi, this revision is providing clarifications to address the review comments received from Dan, Benoit, and Leif Johansson (Security Directorate reviewer). I also tried to fix the length issue reported by Martin. From my side, all issues are again closed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From reid@snmp.com Fri Apr 20 13:17:49 2012 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 4697721F85DB for ; Fri, 20 Apr 2012 13:17:49 -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 HMkMxJV+dWAB for ; Fri, 20 Apr 2012 13:17:48 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF1B21F85BD for ; Fri, 20 Apr 2012 13:17:48 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA16583; Fri, 20 Apr 2012 16:17:45 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id QAA18143; Fri, 20 Apr 2012 16:17:44 -0400 (EDT) Message-Id: <201204202017.QAA18143@adminfs.snmp.com> To: Juergen Schoenwaelder From: David Reid In-reply-to: Your message of Fri, 20 Apr 2012 16:26:52 +0200. <20120420142652.GA78894@elstar.local> Date: Fri, 20 Apr 2012 16:17:44 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-smi-yang-05.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 20:17:49 -0000 > Hi, > > this revision is providing clarifications to address the review > comments received from Dan, Benoit, and Leif Johansson (Security > Directorate reviewer). I also tried to fix the length issue reported > by Martin. From my side, all issues are again closed. > > /js > I reviewed the diffs. Looks good to me. -David Reid From dromasca@avaya.com Sun Apr 22 03:22:01 2012 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 7EBDF21F85E4 for ; Sun, 22 Apr 2012 03:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.915 X-Spam-Level: X-Spam-Status: No, score=-102.915 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, 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 C8jc9ltUQXTJ for ; Sun, 22 Apr 2012 03:22:00 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8E95621F85DF for ; Sun, 22 Apr 2012 03:22:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGnbk0+HCzI1/2dsb2JhbABBA7FAgQeCCQEBAQEDAQEBDx4KNBcCAgIBCA0BAgEEAQELBgwLAQYBGgwfCQgBAQQBEggah20LnUKcGwSJZIQhgkdjBJwQiiiCaw X-IronPort-AV: E=Sophos;i="4.75,462,1330923600"; d="scan'208";a="5563925" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 22 Apr 2012 06:21:58 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 Apr 2012 06:05:18 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Apr 2012 12:21:57 +0200 Message-ID: In-Reply-To: <20120420142652.GA78894@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-smi-yang-05.txt Thread-Index: Ac0fAaPID51+ECRDTLKHx8F7vAY8YABcA44w References: <20120420142219.20837.46464.idtracker@ietfa.amsl.com> <20120420142652.GA78894@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , Subject: Re: [netmod] I-D Action: draft-ietf-netmod-smi-yang-05.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, 22 Apr 2012 10:22:01 -0000 I am happy with this version of the document.=20 Regards, Dan > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Friday, April 20, 2012 5:27 PM > To: netmod@ietf.org > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-smi-yang-05.txt >=20 > Hi, >=20 > this revision is providing clarifications to address the review > comments received from Dan, Benoit, and Leif Johansson (Security > Directorate reviewer). I also tried to fix the length issue reported > by Martin. From my side, all issues are again closed. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Tue Apr 24 14:39:04 2012 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 DE42F21F8645 for ; Tue, 24 Apr 2012 14:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.041 X-Spam-Level: X-Spam-Status: No, score=-1.041 tagged_above=-999 required=5 tests=[AWL=-0.854, 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 bK96FfcHuFzB for ; Tue, 24 Apr 2012 14:39:04 -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 514BB21F8631 for ; Tue, 24 Apr 2012 14:39:04 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 98E5E1200D57 for ; Tue, 24 Apr 2012 23:39:02 +0200 (CEST) Date: Tue, 24 Apr 2012 23:39:01 +0200 (CEST) Message-Id: <20120424.233901.375853448.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] iana-maintained modules 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, 24 Apr 2012 21:39:05 -0000 Hi, In our current documents, we have two modules that are just YANG encodings of existing IANA registries: draft-ietf-netmod-iana-if-type: iana-if-type.yang - "ifType definitions" registry draft-ietf-netmod-routing-cfg: iana-afn-safi.yang - "Address Family Numbers" and "SAFI Values" registries Lada and I think we should have a single document with both these modules. The routing document will be a bit easier to navigate without the initial version of the IANA module, and it makes it more clear that the iana-afn-safi module is not really tied to the routing module. So we suggest we move the iana-afn-safi module to draft-ietf-netmod-iana-if-type (and change the title of the document). Does anyone have any objections to this? /martin & lada From andy@netconfcentral.org Sat Apr 28 06:31:36 2012 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 3791F21F8672 for ; Sat, 28 Apr 2012 06:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[AWL=-0.648, BAYES_05=-1.11] 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 x5rLXFse15fj for ; Sat, 28 Apr 2012 06:31:35 -0700 (PDT) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by ietfa.amsl.com (Postfix) with ESMTP id 8B71B21F8665 for ; Sat, 28 Apr 2012 06:31:35 -0700 (PDT) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3SDVXgb027124 for ; Sat, 28 Apr 2012 09:31:34 -0400 Authentication-Results: cm-omr6 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:43708] helo=[192.168.0.9]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 03/69-22382-531FB9F4; Sat, 28 Apr 2012 09:31:33 -0400 Message-ID: <4F9BF13B.7080205@netconfcentral.org> Date: Sat, 28 Apr 2012 06:31:39 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] comments on draft-lhotka-yang-json-00 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, 28 Apr 2012 13:31:36 -0000 Hi, I am trying to use this draft in some prototype work. I really like it, except for sec. 3.1. It states that the module:local-name variant MUST be used for top-level and any descendants from external augment (namespace change). IMO this is way too restrictive and not user friendly. Most YANG implementers try really hard not to have any configuration nodes with the same local name. It's not user-friendly since the CLI often shares the YANG model, and users don't like typing long module names. The server MUST require the module:local-name variant whenever there are sibling nodes with different expanded names but the same local names. If there is no local name collision, the module name can be left out. IMO: * The server MUST accept the module:local-name form whenever it is used. * The client MAY use the procedures in sec. 3.1 It is OK to assume the client knows the set of active modules on the server. An app can fill in the module and a CLI can prompt if there is a local-name conflict. If the client wants to be cautious and guard against future modules adding local-name collisions, they can follow the advice in sec. 3.1. But clients should not be forced to do that. Andy From lhotka@nic.cz Sun Apr 29 09:14:48 2012 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 6EEF221F84EC for ; Sun, 29 Apr 2012 09:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.060, 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 7q+vLRUJmy5e for ; Sun, 29 Apr 2012 09:14:47 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A9C4B21F84DF for ; Sun, 29 Apr 2012 09:14:47 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 7F0F513FCBF; Sun, 29 Apr 2012 18:14:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1335716085; bh=Ow+ZBejv+uaNC4tdsN5/UAZT2EOb/N0YqyivW/tq260=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=G9E/149GLCPVH4Xo51Gnup7dAK9fFPHvGtrVieHFJEY/4adFDKMuAdOjOr0wL67Wt BuaUDUrkRP7iKwVHS4fRy6LHYDqv1WSByb5qlyhWU7J+/u2sU4w0aXN2yicN/rJ5jg RVZ3PsNpGl6kk6V2bQa6x0IyVw1XS+0hbgqEUUTw= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <4F9BF13B.7080205@netconfcentral.org> Date: Sun, 29 Apr 2012 18:14:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1442C06B-7488-416F-955D-13FE0147E707@nic.cz> References: <4F9BF13B.7080205@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: NETMOD Working Group Subject: Re: [netmod] comments on draft-lhotka-yang-json-00 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, 29 Apr 2012 16:14:48 -0000 On Apr 28, 2012, at 3:31 PM, Andy Bierman wrote: > Hi, >=20 > I am trying to use this draft in some prototype work. Great! > I really like it, except for sec. 3.1. > It states that the module:local-name variant MUST be > used for top-level and any descendants from external augment > (namespace change). >=20 > IMO this is way too restrictive and not user friendly. > Most YANG implementers try really hard not to have > any configuration nodes with the same local name. > It's not user-friendly since the CLI often > shares the YANG model, and users don't like typing long module names. >=20 > The server MUST require the module:local-name variant whenever > there are sibling nodes with different expanded names but the same > local names. If there is no local name collision, the module name > can be left out. My very first version of the draft had this rule, but after a discussion = with Martin I changed my mind. The advantage of the current system is = that the namespace of every node, hence the YANG module where it is = defined, is immediately visible from the instance document. I agree with = you that in most cases explicit namespaces won't be necessary at all so = users needn't bother about them. >=20 > IMO: > * The server MUST accept the module:local-name form whenever it is = used. > * The client MAY use the procedures in sec. 3.1 * There form module:local-name MUST be used whenever there is a = collision in local-name. These three rules make sense to me, too. =20 >=20 > It is OK to assume the client knows the set of active modules > on the server. An app can fill in the module and a CLI can prompt > if there is a local-name conflict. If the client wants to be > cautious and guard against future modules adding local-name > collisions, they can follow the advice in sec. 3.1. > But clients should not be forced to do that. The draft essentially addresses the form of JSON documents that would be = exchanged between the server and the client, in the same way as the "XML = Mapping Rules" sections in 6020 address XML documents. I believe at this = stage the namespaces must already be uniquely resolvable. Any opinions? Lada >=20 > Andy >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Sun Apr 29 09:35:12 2012 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 2747321F852D for ; Sun, 29 Apr 2012 09:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4CbRRnQKUpT for ; Sun, 29 Apr 2012 09:35:11 -0700 (PDT) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF3421F8528 for ; Sun, 29 Apr 2012 09:35:11 -0700 (PDT) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3TGZ9jR018668 for ; Sun, 29 Apr 2012 12:35:09 -0400 Authentication-Results: cm-omr4 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:47297] helo=[192.168.0.9]) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 76/40-15972-DBD6D9F4; Sun, 29 Apr 2012 12:35:09 -0400 Message-ID: <4F9D6DC3.4090208@netconfcentral.org> Date: Sun, 29 Apr 2012 09:35:15 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ladislav Lhotka References: <4F9BF13B.7080205@netconfcentral.org> <1442C06B-7488-416F-955D-13FE0147E707@nic.cz> In-Reply-To: <1442C06B-7488-416F-955D-13FE0147E707@nic.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] comments on draft-lhotka-yang-json-00 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, 29 Apr 2012 16:35:12 -0000 On 04/29/2012 09:14 AM, Ladislav Lhotka wrote: > > On Apr 28, 2012, at 3:31 PM, Andy Bierman wrote: > >> Hi, >> >> I am trying to use this draft in some prototype work. > > Great! > >> I really like it, except for sec. 3.1. >> It states that the module:local-name variant MUST be >> used for top-level and any descendants from external augment >> (namespace change). >> >> IMO this is way too restrictive and not user friendly. >> Most YANG implementers try really hard not to have >> any configuration nodes with the same local name. >> It's not user-friendly since the CLI often >> shares the YANG model, and users don't like typing long module names. >> >> The server MUST require the module:local-name variant whenever >> there are sibling nodes with different expanded names but the same >> local names. If there is no local name collision, the module name >> can be left out. > > My very first version of the draft had this rule, but after a discussion with Martin I changed my mind. The advantage of the current system is that the namespace of every node, hence the YANG module where it is defined, is immediately visible from the instance document. I agree with you that in most cases explicit namespaces won't be necessary at all so users needn't bother about them. > IMO, the probability of local name collisions is < .0001 I don't think users want an educational experience to be reminded of the YANG module name associated with the configuration data. If the server can determine the expanded name for the given local name part (because there are no siblings with duplicate local names) then forcing the server to return an error anyway does not follow the Postel Principle. >> >> IMO: >> * The server MUST accept the module:local-name form whenever it is used. >> * The client MAY use the procedures in sec. 3.1 > > * There form module:local-name MUST be used whenever there is a collision in local-name. > > These three rules make sense to me, too. > >> >> It is OK to assume the client knows the set of active modules >> on the server. An app can fill in the module and a CLI can prompt >> if there is a local-name conflict. If the client wants to be >> cautious and guard against future modules adding local-name >> collisions, they can follow the advice in sec. 3.1. >> But clients should not be forced to do that. > > The draft essentially addresses the form of JSON documents that would be exchanged between the server and the client, in the same way as the "XML Mapping Rules" sections in 6020 address XML documents. I believe at this stage the namespaces must already be uniquely resolvable. > > Any opinions? > > Lada > >> >> Andy >> Andy From internet-drafts@ietf.org Sun Apr 29 12:32:41 2012 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 C810321F85F4; Sun, 29 Apr 2012 12:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, 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 tZAhniYomZ6e; Sun, 29 Apr 2012 12:32:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1E121F84C9; Sun, 29 Apr 2012 12:32:41 -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.02 Message-ID: <20120429193241.14918.71465.idtracker@ietfa.amsl.com> Date: Sun, 29 Apr 2012 12:32:41 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-iana-if-type-02.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, 29 Apr 2012 19:32:42 -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 Workin= g Group of the IETF. Title : IANA Interface Type and Address Family YANG Modules Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-iana-if-type-02.txt Pages : 48 Date : 2012-04-29 This document defines the initial versions of the iana-if-type and iana-afn-safi YANG modules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-iana-if-type-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-iana-if-type-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-iana-if-type/ From internet-drafts@ietf.org Sun Apr 29 12:33:44 2012 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 510AE21F8607; Sun, 29 Apr 2012 12:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, 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 7e+SpwnF6ZGN; Sun, 29 Apr 2012 12:33:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA0221F85F4; Sun, 29 Apr 2012 12:33:43 -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.02 Message-ID: <20120429193343.15285.66191.idtracker@ietfa.amsl.com> Date: Sun, 29 Apr 2012 12:33:43 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-04.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, 29 Apr 2012 19:33:44 -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 Workin= g Group of the IETF. Title : A YANG Data Model for Interface Configuration Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-interfaces-cfg-04.txt Pages : 24 Date : 2012-04-29 This document defines a YANG data model for the configuration of network interfaces. It is expected that interface type specific configuration data models augment the generic interfaces data model defined in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-interfaces-cfg-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-interfaces-cfg-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/ From internet-drafts@ietf.org Sun Apr 29 12:34:38 2012 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 E400221F861C; Sun, 29 Apr 2012 12:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, 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 Uc5k4bgFku2L; Sun, 29 Apr 2012 12:34:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7858F21F8600; Sun, 29 Apr 2012 12:34:37 -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.02 Message-ID: <20120429193437.14923.8290.idtracker@ietfa.amsl.com> Date: Sun, 29 Apr 2012 12:34:37 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-03.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, 29 Apr 2012 19:34:38 -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 Workin= g Group of the IETF. Title : A YANG Data Model for IP Configuration Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-ip-cfg-03.txt Pages : 16 Date : 2012-04-29 This document defines a YANG data model for configuration of IP implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-ip-cfg-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-ip-cfg-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/ From mbj@tail-f.com Sun Apr 29 13:14:27 2012 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 E364D21F85C9 for ; Sun, 29 Apr 2012 13:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Po0EHuyE2mw for ; Sun, 29 Apr 2012 13:14:27 -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 57EFE21F85C7 for ; Sun, 29 Apr 2012 13:14:27 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 352AF1200AE5; Sun, 29 Apr 2012 22:14:25 +0200 (CEST) Date: Sun, 29 Apr 2012 22:14:24 +0200 (CEST) Message-Id: <20120429.221424.296707243.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <1442C06B-7488-416F-955D-13FE0147E707@nic.cz> References: <4F9BF13B.7080205@netconfcentral.org> <1442C06B-7488-416F-955D-13FE0147E707@nic.cz> X-Mailer: Mew version 6.4 on Emacs 23.3 / 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] comments on draft-lhotka-yang-json-00 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, 29 Apr 2012 20:14:28 -0000 Hi, Ladislav Lhotka wrote: > > On Apr 28, 2012, at 3:31 PM, Andy Bierman wrote: > > The server MUST require the module:local-name variant whenever > > there are sibling nodes with different expanded names but the same > > local names. If there is no local name collision, the module name > > can be left out. > > My very first version of the draft had this rule, but after a discussion with > Martin I changed my mind. The advantage of the current system is that the > namespace of every node, hence the YANG module where it is defined, is > immediately visible from the instance document. I agree with you that in most > cases explicit namespaces won't be necessary at all so users needn't bother > about them. > > > > > IMO: > > * The server MUST accept the module:local-name form whenever it is used. > > * The client MAY use the procedures in sec. 3.1 > > * There form module:local-name MUST be used whenever there is a collision in > * local-name. > > These three rules make sense to me, too. The problem with this approach is that unless the client has parsed and interpreted all modules a server implement, it has to use the module:local-name on *all* nodes, if it wants to be certain to avoid errors. This isn't very user friendly. When the module:local-name syntax only is used on augmenting nodes (as it is in the current draft), the client adds the module name only when crossing modules. It might be ok to let the client skip the module name if there is no collision on the server though... But consider this case: The server implements: module a { ... container top; } module b { ... augament /a:top { leaf foo { type int32; } } } The client sends: "top" : { "foo": 42 } and this works. Now, the server upgrades module a to this: module a { ... container top { leaf foo { type int32; } } } The client's request still works, but sets another leaf. Not good. /martin From andy@netconfcentral.org Sun Apr 29 14:14:46 2012 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 4193D21F8546 for ; Sun, 29 Apr 2012 14:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mY9wvA6es9eP for ; Sun, 29 Apr 2012 14:14:45 -0700 (PDT) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7965521F8437 for ; Sun, 29 Apr 2012 14:14:45 -0700 (PDT) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3TLEiW8010984 for ; Sun, 29 Apr 2012 17:14:44 -0400 Authentication-Results: cm-omr11 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:47693] helo=[192.168.0.9]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id D7/A1-02293-34FAD9F4; Sun, 29 Apr 2012 17:14:44 -0400 Message-ID: <4F9DAF4A.5090704@netconfcentral.org> Date: Sun, 29 Apr 2012 14:14:50 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Martin Bjorklund References: <4F9BF13B.7080205@netconfcentral.org> <1442C06B-7488-416F-955D-13FE0147E707@nic.cz> <20120429.221424.296707243.mbj@tail-f.com> In-Reply-To: <20120429.221424.296707243.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-lhotka-yang-json-00 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, 29 Apr 2012 21:14:46 -0000 On 04/29/2012 01:14 PM, Martin Bjorklund wrote: > Hi, > > Ladislav Lhotka wrote: >> >> On Apr 28, 2012, at 3:31 PM, Andy Bierman wrote: >>> The server MUST require the module:local-name variant whenever >>> there are sibling nodes with different expanded names but the same >>> local names. If there is no local name collision, the module name >>> can be left out. >> >> My very first version of the draft had this rule, but after a discussion with >> Martin I changed my mind. The advantage of the current system is that the >> namespace of every node, hence the YANG module where it is defined, is >> immediately visible from the instance document. I agree with you that in most >> cases explicit namespaces won't be necessary at all so users needn't bother >> about them. >> >>> >>> IMO: >>> * The server MUST accept the module:local-name form whenever it is used. >>> * The client MAY use the procedures in sec. 3.1 >> >> * There form module:local-name MUST be used whenever there is a collision in >> * local-name. >> >> These three rules make sense to me, too. > > The problem with this approach is that unless the client has parsed and > interpreted all modules a server implement, it has to use the > module:local-name on *all* nodes, if it wants to be certain to avoid > errors. This isn't very user friendly. > The client MAY choose to use the module name all the time if it wants. It doesn't need to do that since a child node without a module name will be interpreted as the same module as the parent. There is no ambiguity at all, if the procedure in 3.1 is followed. But it should be up to the client to decide how strict to be. The server should accept liberal input. Nobody actually uses module:local-name in the real world. Mandating that format to solve a problem that doesn't actually occur in real deployment seems more unfriendly to users. > When the module:local-name syntax only is used on augmenting nodes (as > it is in the current draft), the client adds the module name only when > crossing modules. > > It might be ok to let the client skip the module name if there is no > collision on the server though... But consider this case: > > The server implements: > > module a { > ... > container top; > } > > module b { > ... > augament /a:top { > leaf foo { type int32; } > } > } > > > The client sends: > > "top" : { > "foo": 42 > } > > and this works. Now, the server upgrades module a to this: > > module a { > ... > container top { > leaf foo { type int32; } > } > } > > The client's request still works, but sets another leaf. Not good. > > Not what happens. The server will reject the request because now it has multiple siblings that match the same local name, with no module specified. That is an error -- not first one wins. The client MAY choose to send, or even SHOULD send, but not MUST send: "a:top" : { "b:foo": 42 } Then it will guard against this hypothetical problem. Vendors don't actually do augment in this fashion. The vendors I have talked to would make sure not to augment a module with duplicate node names. BTW, the JSON encoding is wrong. All the XML <--> converters I found do this: XML: 42 JSON: { "top" : { "foo" : "42" } } Otherwise the reverse translation is lost. > > /martin > > Andy From lhotka@nic.cz Sun Apr 29 22:11:10 2012 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 EA03021F8551 for ; Sun, 29 Apr 2012 22:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.054, 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 QpEOgRsMRQ3g for ; Sun, 29 Apr 2012 22:11:10 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DEC6E21F8548 for ; Sun, 29 Apr 2012 22:11:09 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 4732A140431; Mon, 30 Apr 2012 07:11:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1335762667; bh=NKJ5jgXvOGugx8pPo3ziA4p9WdHP9n4GlVdyUNYAykE=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=foglC/C9mKsLjABm9l9j0OupHHcsFGNLmc4RIt90csMAbugYiMS+HR9PMGfv8rA1o niG9ZExLEJRuYog7cFG8QPnS3duGEaWHr4YTzOJ74jQpjr9lmy1QNxhE9GahOGlftQ hxU5LTDSl7x2gJluMkOzMkCIhKf+Wxa2PAX2Roiw= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: <4F9DAF4A.5090704@netconfcentral.org> Date: Mon, 30 Apr 2012 07:11:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4B4A143D-3DC8-4E11-AD9B-6B78ED0E0AD8@nic.cz> References: <4F9BF13B.7080205@netconfcentral.org> <1442C06B-7488-416F-955D-13FE0147E707@nic.cz> <20120429.221424.296707243.mbj@tail-f.com> <4F9DAF4A.5090704@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-lhotka-yang-json-00 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, 30 Apr 2012 05:11:11 -0000 On Apr 29, 2012, at 11:14 PM, Andy Bierman wrote: > On 04/29/2012 01:14 PM, Martin Bjorklund wrote: >> Hi, >>=20 >> Ladislav Lhotka wrote: >>>=20 >>> On Apr 28, 2012, at 3:31 PM, Andy Bierman wrote: >>>> The server MUST require the module:local-name variant whenever >>>> there are sibling nodes with different expanded names but the same >>>> local names. If there is no local name collision, the module name >>>> can be left out. >>>=20 >>> My very first version of the draft had this rule, but after a = discussion with >>> Martin I changed my mind. The advantage of the current system is = that the >>> namespace of every node, hence the YANG module where it is defined, = is >>> immediately visible from the instance document. I agree with you = that in most >>> cases explicit namespaces won't be necessary at all so users needn't = bother >>> about them. >>>=20 >>>>=20 >>>> IMO: >>>> * The server MUST accept the module:local-name form whenever it is = used. >>>> * The client MAY use the procedures in sec. 3.1 >>>=20 >>> * There form module:local-name MUST be used whenever there is a = collision in >>> * local-name. >>>=20 >>> These three rules make sense to me, too. >>=20 >> The problem with this approach is that unless the client has parsed = and >> interpreted all modules a server implement, it has to use the >> module:local-name on *all* nodes, if it wants to be certain to avoid >> errors. This isn't very user friendly. >>=20 >=20 > The client MAY choose to use the module name all the time if it wants. > It doesn't need to do that since a child node without a module name = will > be interpreted as the same module as the parent. There is no > ambiguity at all, if the procedure in 3.1 is followed. >=20 > But it should be up to the client to decide how strict to be. > The server should accept liberal input. Nobody actually uses > module:local-name in the real world. Mandating that format > to solve a problem that doesn't actually occur in real deployment > seems more unfriendly to users. >=20 >=20 >=20 >> When the module:local-name syntax only is used on augmenting nodes = (as >> it is in the current draft), the client adds the module name only = when >> crossing modules. >>=20 >> It might be ok to let the client skip the module name if there is no >> collision on the server though... But consider this case: >>=20 >> The server implements: >>=20 >> module a { >> ... >> container top; >> } >>=20 >> module b { >> ... >> augament /a:top { >> leaf foo { type int32; } >> } >> } >>=20 >>=20 >> The client sends: >>=20 >> "top" : { >> "foo": 42 >> } >>=20 >> and this works. Now, the server upgrades module a to this: >>=20 >> module a { >> ... >> container top { >> leaf foo { type int32; } >> } >> } >>=20 >> The client's request still works, but sets another leaf. Not good. >>=20 >>=20 >=20 > Not what happens. > The server will reject the request because now it has multiple > siblings that match the same local name, with no module specified. > That is an error -- not first one wins. Right, rule #3 above makes the client input with unqualified "foo" = invalid. >=20 > The client MAY choose to send, or even SHOULD send, but not MUST send: >=20 > "a:top" : { > "b:foo": 42 > } >=20 > Then it will guard against this hypothetical problem. > Vendors don't actually do augment in this fashion. The vendors I have = talked > to would make sure not to augment a module with duplicate node names. >=20 > BTW, the JSON encoding is wrong. > All the XML <--> converters I found do this: >=20 > XML: >=20 > > 42 > >=20 > JSON: >=20 > { > "top" : { > "foo" : "42" > } > } Yes, according to the ABNF in RFC 4627, JSON-text starts with either "{" = (object) or "[" (array). The draft should also state that an XML = document translates to a JSON object. Lada =20 >=20 > Otherwise the reverse translation is lost. >=20 >=20 >>=20 >> /martin >>=20 >>=20 >=20 >=20 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Sun Apr 29 23:29:01 2012 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 8B50821F85A7 for ; Sun, 29 Apr 2012 23:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AK2O8graOi3z for ; Sun, 29 Apr 2012 23:29:01 -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 B391921F85A4 for ; Sun, 29 Apr 2012 23:29:00 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id AC3BB1200AC8; Mon, 30 Apr 2012 08:28:58 +0200 (CEST) Date: Mon, 30 Apr 2012 08:28:58 +0200 (CEST) Message-Id: <20120430.082858.246776878331071062.mbj@tail-f.com> To: andy@netconfcentral.org From: Martin Bjorklund In-Reply-To: <4F9DAF4A.5090704@netconfcentral.org> References: <1442C06B-7488-416F-955D-13FE0147E707@nic.cz> <20120429.221424.296707243.mbj@tail-f.com> <4F9DAF4A.5090704@netconfcentral.org> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] comments on draft-lhotka-yang-json-00 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, 30 Apr 2012 06:29:01 -0000 Andy Bierman wrote: > On 04/29/2012 01:14 PM, Martin Bjorklund wrote: > > Hi, > > > > Ladislav Lhotka wrote: > >> > >> On Apr 28, 2012, at 3:31 PM, Andy Bierman wrote: > >>> The server MUST require the module:local-name variant whenever > >>> there are sibling nodes with different expanded names but the same > >>> local names. If there is no local name collision, the module name > >>> can be left out. > >> > >> My very first version of the draft had this rule, but after a > >> discussion with > >> Martin I changed my mind. The advantage of the current system is that > >> the > >> namespace of every node, hence the YANG module where it is defined, is > >> immediately visible from the instance document. I agree with you that > >> in most > >> cases explicit namespaces won't be necessary at all so users needn't > >> bother > >> about them. > >> > >>> > >>> IMO: > >>> * The server MUST accept the module:local-name form whenever it is used. > >>> * The client MAY use the procedures in sec. 3.1 > >> > >> * There form module:local-name MUST be used whenever there is a > >> * collision in > >> * local-name. > >> > >> These three rules make sense to me, too. > > > > The problem with this approach is that unless the client has parsed > > and > > interpreted all modules a server implement, it has to use the > > module:local-name on *all* nodes, if it wants to be certain to avoid > > errors. This isn't very user friendly. > > > > The client MAY choose to use the module name all the time if it wants. > It doesn't need to do that since a child node without a module name > will > be interpreted as the same module as the parent. There is no > ambiguity at all, if the procedure in 3.1 is followed. > > But it should be up to the client to decide how strict to be. > The server should accept liberal input. Nobody actually uses > module:local-name in the real world. Mandating that format > to solve a problem that doesn't actually occur in real deployment > seems more unfriendly to users. > > > > > When the module:local-name syntax only is used on augmenting nodes (as > > it is in the current draft), the client adds the module name only when > > crossing modules. > > > > It might be ok to let the client skip the module name if there is no > > collision on the server though... But consider this case: > > > > The server implements: > > > > module a { > > ... > > container top; > > } > > > > module b { > > ... > > augament /a:top { > > leaf foo { type int32; } > > } > > } > > > > > > The client sends: > > > > "top" : { > > "foo": 42 > > } > > > > and this works. Now, the server upgrades module a to this: > > > > module a { > > ... > > container top { > > leaf foo { type int32; } > > } > > } > > > > The client's request still works, but sets another leaf. Not good. > > > > > > Not what happens. I think you misinterpreted the context in which I made this claim. There are three alterative encodings on the table: 1. The enconding described in the draft. (required "module:" on module crossing) 2. Your proposed lax encoding. (require "module:" if there is a collision - even if the child is in the same module as parent) 3. The encoding described in the draft + the client MAY skip module-name. Let me re-state what I wrote earlier. With (2), the client has to use the module:local-name on *all* nodes, if it wants to be certain to avoid errors. This isn't very user friendly. With (3), the scenario I described above could happen. > Vendors don't actually do augment in this fashion. The vendors I have > talked > to would make sure not to augment a module with duplicate node names. One sceanario is that a vendor adds node "foo", and later this node "foo" gets picked by a standard module. Then this happens. /martin From lhotka@nic.cz Sun Apr 29 23:56:28 2012 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 2407921F84A2 for ; Sun, 29 Apr 2012 23:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.050, 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 bDKET6oedVfy for ; Sun, 29 Apr 2012 23:56: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 3798A21F8551 for ; Sun, 29 Apr 2012 23:56:27 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id A195B13FCBF; Mon, 30 Apr 2012 08:56:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1335768983; bh=jRofe5XtmppweI47u9LAfaX86wpmp7kNzPPrN9Pjfg0=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=p06BmDGmzDiI+spX6S4j25Qtl+sxF7KltI/vv7L+RLkKjh+6W1yVGxs9lCaQ2/E7o U19l1oMYaMwNneBoARydgmVSVF62VdOS9ai8XYQFGQwUwYtgbNLCzJhn/7Xd6avSG3 R0Ua0RHH5wZeALAQfaSEN0A1OzTY16ODIiyVt4Jc= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120430.082858.246776878331071062.mbj@tail-f.com> Date: Mon, 30 Apr 2012 08:56:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7DFB7091-8040-4974-B597-BCB5236D648A@nic.cz> References: <1442C06B-7488-416F-955D-13FE0147E707@nic.cz> <20120429.221424.296707243.mbj@tail-f.com> <4F9DAF4A.5090704@netconfcentral.org> <20120430.082858.246776878331071062.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-lhotka-yang-json-00 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, 30 Apr 2012 06:56:28 -0000 On Apr 30, 2012, at 8:28 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On 04/29/2012 01:14 PM, Martin Bjorklund wrote: >>> Hi, >>>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>> On Apr 28, 2012, at 3:31 PM, Andy Bierman wrote: >>>>> The server MUST require the module:local-name variant whenever >>>>> there are sibling nodes with different expanded names but the same >>>>> local names. If there is no local name collision, the module name >>>>> can be left out. >>>>=20 >>>> My very first version of the draft had this rule, but after a >>>> discussion with >>>> Martin I changed my mind. The advantage of the current system is = that >>>> the >>>> namespace of every node, hence the YANG module where it is defined, = is >>>> immediately visible from the instance document. I agree with you = that >>>> in most >>>> cases explicit namespaces won't be necessary at all so users = needn't >>>> bother >>>> about them. >>>>=20 >>>>>=20 >>>>> IMO: >>>>> * The server MUST accept the module:local-name form whenever it is = used. >>>>> * The client MAY use the procedures in sec. 3.1 >>>>=20 >>>> * There form module:local-name MUST be used whenever there is a >>>> * collision in >>>> * local-name. >>>>=20 >>>> These three rules make sense to me, too. >>>=20 >>> The problem with this approach is that unless the client has parsed >>> and >>> interpreted all modules a server implement, it has to use the >>> module:local-name on *all* nodes, if it wants to be certain to avoid >>> errors. This isn't very user friendly. >>>=20 >>=20 >> The client MAY choose to use the module name all the time if it = wants. >> It doesn't need to do that since a child node without a module name >> will >> be interpreted as the same module as the parent. There is no >> ambiguity at all, if the procedure in 3.1 is followed. >>=20 >> But it should be up to the client to decide how strict to be. >> The server should accept liberal input. Nobody actually uses >> module:local-name in the real world. Mandating that format >> to solve a problem that doesn't actually occur in real deployment >> seems more unfriendly to users. >>=20 >>=20 >>=20 >>> When the module:local-name syntax only is used on augmenting nodes = (as >>> it is in the current draft), the client adds the module name only = when >>> crossing modules. >>>=20 >>> It might be ok to let the client skip the module name if there is no >>> collision on the server though... But consider this case: >>>=20 >>> The server implements: >>>=20 >>> module a { >>> ... >>> container top; >>> } >>>=20 >>> module b { >>> ... >>> augament /a:top { >>> leaf foo { type int32; } >>> } >>> } >>>=20 >>>=20 >>> The client sends: >>>=20 >>> "top" : { >>> "foo": 42 >>> } >>>=20 >>> and this works. Now, the server upgrades module a to this: >>>=20 >>> module a { >>> ... >>> container top { >>> leaf foo { type int32; } >>> } >>> } >>>=20 >>> The client's request still works, but sets another leaf. Not good. >>>=20 >>>=20 >>=20 >> Not what happens. >=20 > I think you misinterpreted the context in which I made this claim. > There are three alterative encodings on the table: >=20 > 1. The enconding described in the draft. > (required "module:" on module crossing) >=20 > 2. Your proposed lax encoding. > (require "module:" if there is a collision - even if the child is > in the same module as parent) >=20 > 3. The encoding described in the draft + the client MAY skip > module-name. >=20 >=20 > Let me re-state what I wrote earlier. >=20 > With (2), the client has to use the module:local-name on *all* nodes, > if it wants to be certain to avoid errors. This isn't very user Why? Which errors? The client knows the data model and can therefore = determine whether there is a collision in local names or not. > friendly. >=20 > With (3), the scenario I described above could happen. In your scenario, after the server upgrade the client input is no more = valid. The client has to take into account the new data model, realize = the collision in "foo", and use the prefix: { "top" : { "b:foo" : 42 } }=20 >=20 >=20 >> Vendors don't actually do augment in this fashion. The vendors I = have >> talked >> to would make sure not to augment a module with duplicate node names. >=20 > One sceanario is that a vendor adds node "foo", and later this node > "foo" gets picked by a standard module. Then this happens. If the vendor upgrades to the new revision of the standard module, it = should also remove its proprietary "foo". I think in practice the data models cannot be a haphazard collection of = modules and will be quite carefully selected and controlled. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Apr 30 00:08:34 2012 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 055B621F8554 for ; Mon, 30 Apr 2012 00:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6KsAxYQKaGe for ; Mon, 30 Apr 2012 00:08:30 -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 3219421F856C for ; Mon, 30 Apr 2012 00:08:28 -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 123071200AC8; Mon, 30 Apr 2012 09:08:27 +0200 (CEST) Date: Mon, 30 Apr 2012 09:08:26 +0200 (CEST) Message-Id: <20120430.090826.1628576556123045849.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <7DFB7091-8040-4974-B597-BCB5236D648A@nic.cz> References: <4F9DAF4A.5090704@netconfcentral.org> <20120430.082858.246776878331071062.mbj@tail-f.com> <7DFB7091-8040-4974-B597-BCB5236D648A@nic.cz> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] comments on draft-lhotka-yang-json-00 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, 30 Apr 2012 07:08:34 -0000 Ladislav Lhotka wrote: > > On Apr 30, 2012, at 8:28 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > >> On 04/29/2012 01:14 PM, Martin Bjorklund wrote: > >>> Hi, > >>> > >>> Ladislav Lhotka wrote: > >>>> > >>>> On Apr 28, 2012, at 3:31 PM, Andy Bierman wrote: > >>>>> The server MUST require the module:local-name variant whenever > >>>>> there are sibling nodes with different expanded names but the same > >>>>> local names. If there is no local name collision, the module name > >>>>> can be left out. > >>>> > >>>> My very first version of the draft had this rule, but after a > >>>> discussion with > >>>> Martin I changed my mind. The advantage of the current system is that > >>>> the > >>>> namespace of every node, hence the YANG module where it is defined, is > >>>> immediately visible from the instance document. I agree with you that > >>>> in most > >>>> cases explicit namespaces won't be necessary at all so users needn't > >>>> bother > >>>> about them. > >>>> > >>>>> > >>>>> IMO: > >>>>> * The server MUST accept the module:local-name form whenever it is used. > >>>>> * The client MAY use the procedures in sec. 3.1 > >>>> > >>>> * There form module:local-name MUST be used whenever there is a > >>>> * collision in > >>>> * local-name. > >>>> > >>>> These three rules make sense to me, too. > >>> > >>> The problem with this approach is that unless the client has parsed > >>> and > >>> interpreted all modules a server implement, it has to use the > >>> module:local-name on *all* nodes, if it wants to be certain to avoid > >>> errors. This isn't very user friendly. > >>> > >> > >> The client MAY choose to use the module name all the time if it wants. > >> It doesn't need to do that since a child node without a module name > >> will > >> be interpreted as the same module as the parent. There is no > >> ambiguity at all, if the procedure in 3.1 is followed. > >> > >> But it should be up to the client to decide how strict to be. > >> The server should accept liberal input. Nobody actually uses > >> module:local-name in the real world. Mandating that format > >> to solve a problem that doesn't actually occur in real deployment > >> seems more unfriendly to users. > >> > >> > >> > >>> When the module:local-name syntax only is used on augmenting nodes (as > >>> it is in the current draft), the client adds the module name only when > >>> crossing modules. > >>> > >>> It might be ok to let the client skip the module name if there is no > >>> collision on the server though... But consider this case: > >>> > >>> The server implements: > >>> > >>> module a { > >>> ... > >>> container top; > >>> } > >>> > >>> module b { > >>> ... > >>> augament /a:top { > >>> leaf foo { type int32; } > >>> } > >>> } > >>> > >>> > >>> The client sends: > >>> > >>> "top" : { > >>> "foo": 42 > >>> } > >>> > >>> and this works. Now, the server upgrades module a to this: > >>> > >>> module a { > >>> ... > >>> container top { > >>> leaf foo { type int32; } > >>> } > >>> } > >>> > >>> The client's request still works, but sets another leaf. Not good. > >>> > >>> > >> > >> Not what happens. > > > > I think you misinterpreted the context in which I made this claim. > > There are three alterative encodings on the table: > > > > 1. The enconding described in the draft. > > (required "module:" on module crossing) > > > > 2. Your proposed lax encoding. > > (require "module:" if there is a collision - even if the child is > > in the same module as parent) > > > > 3. The encoding described in the draft + the client MAY skip > > module-name. > > > > > > Let me re-state what I wrote earlier. > > > > With (2), the client has to use the module:local-name on *all* nodes, > > if it wants to be certain to avoid errors. This isn't very user > > Why? Which errors? The client knows the data model and can therefore > determine whether there is a collision in local names or not. This is what I originally wrote: The problem with this approach is that unless the client has parsed and interpreted all modules a server implement, it has to use the module:local-name on *all* nodes, if it wants to be certain to avoid errors. This isn't very user friendly. The error I refer to is the collision error. Suppose you write a client for a certain data model A: { "top": { "foo": 42 } } The client checks that the server implements A, and sends this. The problem with encoding scheme (2) is that if the server also implements B, the client will get a collision error with this request. Thus, the client must understand all modules a server implements. The underlying assumption (of doing a REST interface) is that it is supposed to be dead-simple. Requiring the client to understand *all* data models implemented by a server is not. > > With (3), the scenario I described above could happen. > > In your scenario, after the server upgrade the client input is no more > valid. The client has to take into account the new data model, realize > the collision in "foo", and use the prefix: > > { > "top" : { > "b:foo" : 42 > } > } Exactly. Not user-friendly for the client. > >> Vendors don't actually do augment in this fashion. The vendors I have > >> talked > >> to would make sure not to augment a module with duplicate node names. > > > > One sceanario is that a vendor adds node "foo", and later this node > > "foo" gets picked by a standard module. Then this happens. > > If the vendor upgrades to the new revision of the standard module, it > should also remove its proprietary "foo". Sure, but there will be old servers and old clients out there for some time, unless you require all implementations to upgrade simultaneously... > I think in practice the data models cannot be a haphazard collection > of modules and will be quite carefully selected and controlled. Sure. /martin From lhotka@nic.cz Mon Apr 30 00:45:50 2012 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 CA2FB21F85B8 for ; Mon, 30 Apr 2012 00:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.046, 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 IoGzMdSMkM7P for ; Mon, 30 Apr 2012 00:45: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 DF0C621F85B5 for ; Mon, 30 Apr 2012 00:45:43 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 6C36713FCBF; Mon, 30 Apr 2012 09:45:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1335771941; bh=fskfpz9n9sDUgc5OTAFy2lcZLmTd1uMRoLJ8ourckAY=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=PVlj/ggnCa+iMpAkC4MTbCRyLDvqRqfLhfurefMmtMrncBl+y9T8kvh29oZAAWtXw dEgy39nIkSOWbO61bgPstAXkAcn07nzq+R3YfSnbNo2BZBLu5vCAKD8urUYRUYDtxT PresDo8ycd7zsRnma7Ui0cmmn0M5H/vOB31FvK0s= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120430.090826.1628576556123045849.mbj@tail-f.com> Date: Mon, 30 Apr 2012 09:45:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6F4ED5AD-691C-492A-9A6C-F762E7CFA3B8@nic.cz> References: <4F9DAF4A.5090704@netconfcentral.org> <20120430.082858.246776878331071062.mbj@tail-f.com> <7DFB7091-8040-4974-B597-BCB5236D648A@nic.cz> <20120430.090826.1628576556123045849.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-lhotka-yang-json-00 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, 30 Apr 2012 07:45:51 -0000 On Apr 30, 2012, at 9:08 AM, Martin Bjorklund wrote: > This is what I originally wrote: >=20 > The problem with this approach is that unless the client has parsed > and interpreted all modules a server implement, it has to use the > module:local-name on *all* nodes, if it wants to be certain to avoid > errors. This isn't very user friendly. >=20 > The error I refer to is the collision error. Suppose you write a > client for a certain data model A: >=20 > {=20 > "top": { > "foo": 42 > } > } >=20 > The client checks that the server implements A, and sends this. The > problem with encoding scheme (2) is that if the server also implements > B, the client will get a collision error with this request. Thus, the > client must understand all modules a server implements. >=20 > The underlying assumption (of doing a REST interface) is that it is > supposed to be dead-simple. Requiring the client to understand *all* > data models implemented by a server is not. Well, if we regard the data model as a contract, we'd better assume that = both parties understand it (including the fine print:-). Module B can = introduce other things that break old client code. It would actually be nice to have rules in YANG that prevent module B = from having backward-incompatible side effects on module A, but it is = not the case. The rule stating that "augment" cannot define mandatory = nodes goes in that direction but it is not enough: e.g., B can define = new "must" constraints affecting A, or even deviations. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Apr 30 03:34:25 2012 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 2EC7621F85B5 for ; Mon, 30 Apr 2012 03:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.984 X-Spam-Level: X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[AWL=-0.797, 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 98JrnJ+4hioR for ; Mon, 30 Apr 2012 03: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 7F52121F8569 for ; Mon, 30 Apr 2012 03:34:24 -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 1A1D81200AC8 for ; Mon, 30 Apr 2012 12:34:23 +0200 (CEST) Date: Mon, 30 Apr 2012 12:34:22 +0200 (CEST) Message-Id: <20120430.123422.2268367902364057171.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] iana-if-type & interface-cfg 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, 30 Apr 2012 10:34:25 -0000 Hi, I have posted new versions of these documents, in which I believe all WGLC comments have been addressed. /martin From mbj@tail-f.com Mon Apr 30 03:36:28 2012 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 04FEB21F85A1 for ; Mon, 30 Apr 2012 03:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0o3U+mdRnkS for ; Mon, 30 Apr 2012 03:36:27 -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 8947A21F8596 for ; Mon, 30 Apr 2012 03:36:27 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id B3FE61200AC8 for ; Mon, 30 Apr 2012 12:36:26 +0200 (CEST) Date: Mon, 30 Apr 2012 12:36:25 +0200 (CEST) Message-Id: <20120430.123625.1495330351770276435.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] ip-cfg 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, 30 Apr 2012 10:36:28 -0000 Hi, I have posted a new version of this document, http://www.ietf.org/internet-drafts/draft-ietf-netmod-ip-cfg-03.txt. I do not have any outstanding open issues, so please review this version. /martin From andy@netconfcentral.org Mon Apr 30 06:56:46 2012 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 C112221F8531 for ; Mon, 30 Apr 2012 06:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 bIVb5xkenNyk for ; Mon, 30 Apr 2012 06:56:46 -0700 (PDT) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2B58121F84F8 for ; Mon, 30 Apr 2012 06:56:46 -0700 (PDT) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3UDujg0029502 for ; Mon, 30 Apr 2012 09:56:45 -0400 Authentication-Results: cm-omr6 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:51015] helo=[192.168.0.9]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id ED/03-10031-C1A9E9F4; Mon, 30 Apr 2012 09:56:45 -0400 Message-ID: <4F9E9A23.8000005@netconfcentral.org> Date: Mon, 30 Apr 2012 06:56:51 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ladislav Lhotka References: <4F9BF13B.7080205@netconfcentral.org> <1442C06B-7488-416F-955D-13FE0147E707@nic.cz> <20120429.221424.296707243.mbj@tail-f.com> <4F9DAF4A.5090704@netconfcentral.org> <4B4A143D-3DC8-4E11-AD9B-6B78ED0E0AD8@nic.cz> In-Reply-To: <4B4A143D-3DC8-4E11-AD9B-6B78ED0E0AD8@nic.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-lhotka-yang-json-00 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, 30 Apr 2012 13:56:46 -0000 On 04/29/2012 10:11 PM, Ladislav Lhotka wrote: > > On Apr 29, 2012, at 11:14 PM, Andy Bierman wrote: > >> On 04/29/2012 01:14 PM, Martin Bjorklund wrote: >... >>>>> >>>>> IMO: >>>>> * The server MUST accept the module:local-name form whenever it is used. >>>>> * The client MAY use the procedures in sec. 3.1 >>>> >>>> * There form module:local-name MUST be used whenever there is a collision in >>>> * local-name. >>>> This is the approach I prefer. ... > Lada Andy From lhotka@nic.cz Mon Apr 30 08:05:40 2012 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 7D6CF21F865D for ; Mon, 30 Apr 2012 08:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.043, 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 F7UIuRnEuKAT for ; Mon, 30 Apr 2012 08:05:40 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CB8EF21F8630 for ; Mon, 30 Apr 2012 08:05:39 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 48780140431; Mon, 30 Apr 2012 17:05:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1335798338; bh=QTNSPIpCwag7GawXnshsxroGubvgqeAGoDiiutEyfYY=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=kEbQ4nPQRoMWvhBUarBqAEihCFDCr9zztgsUCJqd0MCYj2kbz3UO2TZwfwN/7D6my ZYyLc5IODUuXUx3J9BURE8wCR/ENHKPtheknJQ41TTIBOEhZZzbqYj8P5TYbwk5/NN Y+fxP7FI26eDL7CfPcFs5dseI3Y6jkXhzqCZbQLI= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: <4F9E9A23.8000005@netconfcentral.org> Date: Mon, 30 Apr 2012 17:05:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <21F6C1F8-7F30-4035-AC1D-346C043389D7@nic.cz> References: <4F9BF13B.7080205@netconfcentral.org> <1442C06B-7488-416F-955D-13FE0147E707@nic.cz> <20120429.221424.296707243.mbj@tail-f.com> <4F9DAF4A.5090704@netconfcentral.org> <4B4A143D-3DC8-4E11-AD9B-6B78ED0E0AD8@nic.cz> <4F9E9A23.8000005@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-lhotka-yang-json-00 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, 30 Apr 2012 15:05:40 -0000 On Apr 30, 2012, at 3:56 PM, Andy Bierman wrote: > On 04/29/2012 10:11 PM, Ladislav Lhotka wrote: >>=20 >> On Apr 29, 2012, at 11:14 PM, Andy Bierman wrote: >>=20 >>> On 04/29/2012 01:14 PM, Martin Bjorklund wrote: >> ... >=20 >>>>>>=20 >>>>>> IMO: >>>>>> * The server MUST accept the module:local-name form whenever it = is used. >>>>>> * The client MAY use the procedures in sec. 3.1 >>>>>=20 >>>>> * There form module:local-name MUST be used whenever there is a = collision in >>>>> * local-name. >>>>>=20 >=20 > This is the approach I prefer. Yup, it is the most flexible option. Server and application developers = may choose to use the module prefixes if and where they want to, but = with sane data models it is quite likely that explicit namespace = identifiers won't be needed at all, which is IMO a great virtue. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From iesg-secretary@ietf.org Mon Apr 30 09:41:38 2012 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 1023A21F8782; Mon, 30 Apr 2012 09:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, 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 lX6sYN8i4bs1; Mon, 30 Apr 2012 09:41:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD9421F87CC; Mon, 30 Apr 2012 09:41:37 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120430164137.13692.62374.idtracker@ietfa.amsl.com> Date: Mon, 30 Apr 2012 09:41:37 -0700 Cc: netmod chair , netmod mailing list , RFC Editor Subject: [netmod] Protocol Action: 'Translation of SMIv2 MIB Modules to YANG Modules' to Proposed Standard (draft-ietf-netmod-smi-yang-05.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, 30 Apr 2012 16:41:38 -0000 The IESG has approved the following document: - 'Translation of SMIv2 MIB Modules to YANG Modules' (draft-ietf-netmod-smi-yang-05.txt) as Proposed Standard This document is the product of the NETCONF Data Modeling Language Working Group. The IESG contact persons are Benoit Claise and Ronald Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netmod-smi-yang/ Technical Summary This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only access to data objects defined in SMIv2 MIB modules via NETCONF. Working Group Summary The normal WG process was followed and the document has been discussed extensively. The document reflects WG consensus, with nothing special worth noting. Document Quality The document was extensively reviewed and there are two independent implementations. Personnel David Kessens is the Document Shepherd. Dan Romascanu was the first responsible Area Director. Benoit Claise is the current responsible Area Director. RFC Editor Note OLD: This document describes a translation of SMIv2 [RFC2578], [RFC2579], [RFC2580] MIB modules into YANG [RFC6020] modules, enabling read-only (config false) access to SMIv2 objects defined in SMIv2 MIB modules via NETCONF [RFC6241]. NEW: This document describes a translation of SMIv2 [RFC2578], [RFC2579], [RFC2580] MIB modules into YANG [RFC6020] modules, enabling read-only (config false, as defined in section 7.19.1 of RFC 6020) access to SMIv2 objects defined in SMIv2 MIB modules via NETCONF [RFC6241].