From andy@yumaworks.com Mon Sep 3 10:06:41 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6204B21F86D1 for ; Mon, 3 Sep 2012 10:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.833 X-Spam-Level: X-Spam-Status: No, score=-2.833 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VataXAe4msd1 for ; Mon, 3 Sep 2012 10:06:40 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE1CA21F86CF for ; Mon, 3 Sep 2012 10:06:40 -0700 (PDT) Received: by qcac10 with SMTP id c10so4046814qca.31 for ; Mon, 03 Sep 2012 10:06:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=pMkav2BH1DtXvgfBatK+7MzSEgzGTLHmI7oSmsJg6rw=; b=FjjEmVpMJr7ZJRRNTaeZbEqVh2il98B4fFX44c4erhkp7FfC5UkW/6RqSvIpHUFOQL uQYvWIYsG5oAIh88GCEBF4uxZ5nExhWJ+X++In6GnnqOnk+BypfMdEAt4HWIeJ48qIEO vWHc4Yss90Zgha43KGyM63sxXOGXt7EYJPB2yGTm6x97MXiw+W1f0Fl7P4rdXwCLK53o EIFM9qzGenr5nRpDdzrflxCNtfHmp6zffeV6RgS+A2/G/QXXzS6MHac/Pg/+q/XE2IWR hJUGp4G1tQ7d9PSsa3ULkiwgbX5PICthcl9+9VtkXkGaNVa3yzPC86BYwC/2lOEnGLGm Skxw== MIME-Version: 1.0 Received: by 10.229.137.146 with SMTP id w18mr9925742qct.12.1346692000091; Mon, 03 Sep 2012 10:06:40 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Mon, 3 Sep 2012 10:06:39 -0700 (PDT) In-Reply-To: <20120831.221343.480406307.mbj@tail-f.com> References: <5040664E.7030803@bwijnen.net> <201208311628.MAA20112@adminfs.snmp.com> <20120831.221343.480406307.mbj@tail-f.com> Date: Mon, 3 Sep 2012 10:06:39 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQk6sAfHpc1Cg+WX58sxVi6/yQqNIWVfVzyh6cF3lgkjFJ4PC/6APTxEREgXDmdtxAALBxlP Cc: netconf@ietf.org Subject: Re: [Netconf] Action by Spet 4th: NetConf interop testing - doodle poll X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 17:06:41 -0000 On Fri, Aug 31, 2012 at 1:13 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Fri, Aug 31, 2012 at 9:28 AM, David Reid wrote: >> >> If you plan to participate, >> >> PLEASE fill out the doodle poll no later than Sept 4 >> > >> > I filled out the doodle poll, although I'm not yet sure if I can >> > participate. > > Great if you can be there! > > >> > There are a few issues that have been brought up on the list which would be >> > helpful to resolve soon such as: >> > >> > What tests do we want to run? >> >> Various people have some proprietary test tools. >> There are various real applications that can >> supposedly manage real servers. >> We need some content to test the operations >> in RFC 6241. >> >> > What Yang modules will we use? > > Some (generic) implementations can work with any modules, and some > implement a fixed set of modules. I think each implementation has to > share the data models they implement with the others. For the generic > implementation, we can pick some of the standard (or draft) modules. > But we need to know well in advance, so that we can adapt our test > programs. > We can use any dummy module to test NETCONF, otherwise we would be expanding the test to include testing some content. Since you have a test-script that checks ietf-netconf-monitoring conformance, why not see if we can get an interop report for RFC 6022 as well? Did anybody else implement it? > > > /martin Andy From j.schoenwaelder@jacobs-university.de Mon Sep 3 12:02:50 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC1721F8643 for ; Mon, 3 Sep 2012 12:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZHqYiht31Uc for ; Mon, 3 Sep 2012 12:02:49 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 76F3021F83EF for ; Mon, 3 Sep 2012 12:02:49 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BE1DE20C10; Mon, 3 Sep 2012 21:02:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id OswO64t7pEju; Mon, 3 Sep 2012 21:02:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F52E20B6C; Mon, 3 Sep 2012 21:02:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 02D48218BE91; Mon, 3 Sep 2012 21:02:40 +0200 (CEST) Date: Mon, 3 Sep 2012 21:02:40 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120903190240.GA55654@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , netconf@ietf.org References: <5040664E.7030803@bwijnen.net> <201208311628.MAA20112@adminfs.snmp.com> <20120831.221343.480406307.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Action by Spet 4th: NetConf interop testing - doodle pollg X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 19:02:50 -0000 On Mon, Sep 03, 2012 at 10:06:39AM -0700, Andy Bierman wrote: > > We can use any dummy module to test NETCONF, otherwise > we would be expanding the test to include testing some content. > > Since you have a test-script that checks ietf-netconf-monitoring > conformance, why not see if we can get an interop report > for RFC 6022 as well? Did anybody else implement it? > I think there is nothing config true in ietf-netconf-monitoring if I recall correctly. I think we better choose a data model with config true nodes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Mon Sep 3 12:08:33 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942F921F86C3 for ; Mon, 3 Sep 2012 12:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eO+2lVWrTE4v for ; Mon, 3 Sep 2012 12:08:33 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 16F6521F8673 for ; Mon, 3 Sep 2012 12:08:32 -0700 (PDT) Received: by qcac10 with SMTP id c10so4110704qca.31 for ; Mon, 03 Sep 2012 12:08:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=uctGMtQX7vk5LErSpj5fgnys2EXJi1wl2cVRSpsPDKA=; b=moFaf0qcXLKEgiDo3xsqgRW1hwS8Kvtb91mlZk69atf1ma1Vx3YqFB67lqB6WB+IMH 2K4eeEKCY5ranupn1/JW9uGWCBpsC2uWqA9BZp5dNTCoc3pbLjosMM5KppsFZ1Jnr2wu XajqTFJpdl91crvudkF45zWtydLmDf4zAYUf8bnkN1ib8jNuPVEINREnXrcRQg12ZpfO +cZZsUV2acEsd/LMkRENOUcOVb6c99gc+Suey3HrnbTHlOVxmsNcOcDaXR6oCrBfkYjy nz81zrPBK8vglZDUbZQfPhC6VgM/ryb+qU3HCRTXRKxLmJzKLsVSXzVtaMR33u18Uqia fODQ== MIME-Version: 1.0 Received: by 10.224.77.13 with SMTP id e13mr36099379qak.68.1346699311913; Mon, 03 Sep 2012 12:08:31 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Mon, 3 Sep 2012 12:08:28 -0700 (PDT) In-Reply-To: <20120903190240.GA55654@elstar.local> References: <5040664E.7030803@bwijnen.net> <201208311628.MAA20112@adminfs.snmp.com> <20120831.221343.480406307.mbj@tail-f.com> <20120903190240.GA55654@elstar.local> Date: Mon, 3 Sep 2012 12:08:28 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , netconf@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnPudUSE3ZC1SFbU4PJLsuBXDr1sOR+Qy/hUtugHEJl8yLGWOG1LMZjZp3g5jIDEeiquyRb Subject: Re: [Netconf] Action by Spet 4th: NetConf interop testing - doodle pollg X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 19:08:33 -0000 On Mon, Sep 3, 2012 at 12:02 PM, Juergen Schoenwaelder wrote: > On Mon, Sep 03, 2012 at 10:06:39AM -0700, Andy Bierman wrote: >> >> We can use any dummy module to test NETCONF, otherwise >> we would be expanding the test to include testing some content. >> >> Since you have a test-script that checks ietf-netconf-monitoring >> conformance, why not see if we can get an interop report >> for RFC 6022 as well? Did anybody else implement it? >> > > I think there is nothing config true in ietf-netconf-monitoring if I > recall correctly. I think we better choose a data model with config > true nodes. > Agreed. This module is read-only, but we can test subtree and XPath filtering with readd-only nodes. NACM (RFC 6536) has config=true nodes. > /js Andy From mbj@tail-f.com Mon Sep 3 12:29:32 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8619121F8685 for ; Mon, 3 Sep 2012 12:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8m8GK4+SCGb3 for ; Mon, 3 Sep 2012 12:29:31 -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 9803A21F866D for ; Mon, 3 Sep 2012 12:29:31 -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 EC69E1200D73; Mon, 3 Sep 2012 21:29:29 +0200 (CEST) Date: Mon, 03 Sep 2012 21:29:29 +0200 (CEST) Message-Id: <20120903.212929.452961899.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120903190240.GA55654@elstar.local> References: <20120831.221343.480406307.mbj@tail-f.com> <20120903190240.GA55654@elstar.local> 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: netconf@ietf.org Subject: Re: [Netconf] Action by Spet 4th: NetConf interop testing - doodle pollg X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 19:29:32 -0000 Juergen Schoenwaelder wrote: > On Mon, Sep 03, 2012 at 10:06:39AM -0700, Andy Bierman wrote: > > > > We can use any dummy module to test NETCONF, otherwise > > we would be expanding the test to include testing some content. > > > > Since you have a test-script that checks ietf-netconf-monitoring > > conformance, why not see if we can get an interop report > > for RFC 6022 as well? Did anybody else implement it? > > > > I think there is nothing config true in ietf-netconf-monitoring if I > recall correctly. I think we better choose a data model with config > true nodes. We should do both. ietf-netconf-monitoring can be tested in itself, and it can be used to test with filters. /martin From bertietf@bwijnen.net Tue Sep 4 07:31:21 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68CD11E809B for ; Tue, 4 Sep 2012 07:31:21 -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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NY2SFznZdFk3 for ; Tue, 4 Sep 2012 07:31:21 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA5611E8097 for ; Tue, 4 Sep 2012 07:31:18 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T8u9s-0007LT-IS for netconf@ietf.org; Tue, 04 Sep 2012 16:31:17 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1T8u9r-0004QT-Sm for netconf@ietf.org; Tue, 04 Sep 2012 16:31:16 +0200 Message-ID: <504610B3.1040004@bwijnen.net> Date: Tue, 04 Sep 2012 16:31:15 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Netconf References: <50447A63.2080403@bwijnen.net> In-Reply-To: <50447A63.2080403@bwijnen.net> X-Forwarded-Message-Id: <50447A63.2080403@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120904 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd46cc70b8706d52060c47c19acf9f9aafc Subject: [Netconf] We have (rough) consensus on New WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 14:31:21 -0000 We (WG chairs) believe that we do have consensus (although maybe still a bit rough) on the below WG charter. So we will send complete new charter text (including what we have already done etc) to our AD (Benoit) for IESG approval. This means that the netconf-over-tls document can now be submitted as WG document. This also menas that the 'obsoleting Netconf over Beep and Soap' an now be submitted as WG document. The interop event has generated enough interest, and we will post more messages about that too. Bert and Mehmet From bertietf@bwijnen.net Tue Sep 4 07:40:49 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F4E21F847B for ; Tue, 4 Sep 2012 07:40:47 -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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1-nxvqVV0h3 for ; Tue, 4 Sep 2012 07:40:42 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3C021F8462 for ; Tue, 4 Sep 2012 07:40:42 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T8uIx-0006Yu-EB; Tue, 04 Sep 2012 16:40:40 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1T8uIx-0004zf-8D; Tue, 04 Sep 2012 16:40:39 +0200 Message-ID: <504612E6.5080104@bwijnen.net> Date: Tue, 04 Sep 2012 16:40:38 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Benoit Claise Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120904 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd47f59300c0bea54605bbfee0cada55fc1 Cc: netconf Subject: [Netconf] Requesting AD/IESG approval: new/revised NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 14:40:49 -0000 Benoit, hope you had a good vacation. Below is the new WG charter that we have WG consensus on. Pls get it approved by IESG. We go from the assumption that IESG will approve and we will start moving the documents as per the WG charter. Hope that is OK. Bert and Mehmet Network Configuration (netconf) ------------------------------- Charter Current Status: Active Chairs: Bert Wijnen Mehmet Ersue Operations and Management Area Directors: Ronald Bonica Benoit Claise Operations and Management Area Advisor: Benoit Claise Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: netconf-request@ietf.org or: https://www.ietf.org/mailman/listinfo/netconf Archive: http://www.ietf.org/mail-archive/web/netconf/ Description of Working Group: Configuration of networks of devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed their own mechanisms or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF Working Group has produced a protocol suitable for network configuration, with the following characteristics: - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough so that vendors can provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases) - Uses an XML-based data representation, that can be easily manipulated using non-specialized XML manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports multiple (e.g. candidate and running) data-stores to optimize configuration preparation and activation - Supports network wide configuration transactions (with features such as locking and rollback capability) - Runs over a secure transport; SSH is mandatory to implement while TLS, BEEP, and SOAP are optional transports. - Provides support for asynchronous notifications. - Supports an Access Control Model and a YANG module for configuring the Access Control parameters. - Supports a YANG module for System Notifications The NETCONF protocol has been designed independent of the data modeling language. The IETF recommends to use YANG as the NETCONF modeling language, which introduces advanced language features for configuration management. In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. This means that RFC5593 needs to be updated. 2. Based on the implementation, deployment experience and interoperability testing, the WG will document the status of NETCONF in a report. Based on this, the WG may decide to make some clarifications to RFC6241 and RFC6242 (then also fixing any reported errata). 3. Since Netconf over BEEP and over SOAP seem not being deployed the WG will write a document that makes those 2 protocols (RFC4743 and RFC4744) HISTORIC. Goals and Milestones: done - Send with-defaults to IESG for consideration as Proposed Standard done - WG Last Call on rfc4741bis done - rfc4741bis to IESG for consideration as Proposed Standard done - Send rfc4742bis to IESG for consideration as proposed Standard. done - first WG draft (rev 00) on NACM posted done - first WG draft (rev 00) on NETCONF specific YANG modules posted done - WGLC for NACM document done - WGLC for NETCONF specific notifications document done - submit NACM document to IESG for consideration as Proposed Standard done - submit NETCONF specific notifications document to IESG for consideration as Proposed Standard Sep 2012 - submit initial WG draft for rfc5539bis Sep 2012 - submit initial WG draft for making RFC4743 and RFC4744 historic. Sep 2012 - WGLC for rfc5539bis Sep 2012 - WGLC for RFC4743 and 4743 to historic Okt 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard Okt 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience Feb 2013 - possibly submit RFC6241/6242 implementation/deployment experience doc to IESG for publication as Informational RFC. Mar 2013 - Evaluate if more work needs to be done by NETCONF WG From bclaise@cisco.com Wed Sep 5 07:38:40 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C0321F84B2 for ; Wed, 5 Sep 2012 07:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.279 X-Spam-Level: X-Spam-Status: No, score=-4.279 tagged_above=-999 required=5 tests=[AWL=-1.680, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rX7P1OHfl93k for ; Wed, 5 Sep 2012 07:38:40 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id F390D21F846A for ; Wed, 5 Sep 2012 07:38:39 -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 q85Ecaq0029286; Wed, 5 Sep 2012 16:38:36 +0200 (CEST) Received: from [10.60.67.92] (ams-bclaise-89111.cisco.com [10.60.67.92]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q85EcX2f020137; Wed, 5 Sep 2012 16:38:33 +0200 (CEST) Message-ID: <504763E9.3040600@cisco.com> Date: Wed, 05 Sep 2012 16:38:33 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net> <502E0A3B.9010008@bwijnen.net> In-Reply-To: <502E0A3B.9010008@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 14:38:41 -0000 + 1 Regards, Benoit. > We had agreed in our last f2f meeting that people would submit > individual I-Ds, and based on that we would potentially > consider work in this space. So by all means do submit > such individual drafts and discuss them on the mailing list. > > But we do not have a good problem statement or starting I-D > to base this work on, so cannot put it on the current charter. > > Bert Wijnen > > On 8/17/12 11:04 AM, Ladislav Lhotka wrote: >> Hi, >> >> I had the impression that there was a reasonable agreement that work >> on operational state data is needed. Although this problem lies >> somewhere between NETCONF and NETMOD, I think the NETCONF WG is now >> in a better position to start this work because apparently NETMOD WG >> will have to continue the work on the core data models for some time. >> >> So I propose the following fourth item for the charter: >> >> 4. The WG will investigate the relationship and interactions between >> configurations and >> operational state data, propose their appropriate representation >> and semantics, and >> devise methods for effective data modeling of both configurations >> and operational state data. >> It is expected that this work will be carried out in a close >> sooperation with the NETMOD WG. >> >> Lada >> >> "Bert Wijnen (IETF)" writes: >> >>> Based on the comments and feedback and the positions >>> expressed on the mailing list, it is clear that after all >>> we did NOT have consensus on the new WG charter. >>> >>> Without further ado, this is another proposed WG charter. >>> It focuses on the things that we do seme to have agreement on. >>> >>> Pls comment and/or express your support or objections >>> no later than August 31, 2012. >>> >>> OK, new chapter text (omitting the description of what we have >>> achieved sofar): >>> >>> In the current phase of the incremental development of NETCONF the >>> workgroup will focus on following items: >>> >>> 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. >>> This means that RFC5593 needs to be updated. >>> >>> 2. Based on the implementation, deployment experience and >>> interoperability >>> testing, the WG will document the status of NETCONF in a report. >>> Based on this, the WG may decide to make some clarifications to >>> RFC6241 and RFC6242 (then also fixing any reported errata). >>> >>> 3. Since Netconf over BEEP and over SOAP seem not being deployed >>> the WG will write a document that makes those 2 protocols >>> (RFC4743 and RFC4744) HISTORIC. >>> >>> Goals and Milestones: >>> done - Send with-defaults to IESG for consideration as >>> Proposed Standard >>> done - WG Last Call on rfc4741bis >>> done - rfc4741bis to IESG for consideration as Proposed >>> Standard >>> done - Send rfc4742bis to IESG for consideration as proposed >>> Standard. >>> done - first WG draft (rev 00) on NACM posted >>> done - first WG draft (rev 00) on NETCONF specific YANG >>> modules posted >>> done - WGLC for NACM document >>> done - WGLC for NETCONF specific notifications document >>> done - submit NACM document to IESG for consideration as >>> Proposed Standard >>> done - submit NETCONF specific notifications document to >>> IESG for >>> consideration as Proposed Standard >>> Aug 2012 - submit initial WG draft for rfc5539bis >>> Aug 2012 - submit initial WG draft for making RFC4743 and >>> RFC4744 historic. >>> Sep 2012 - WGLC for rfc5539bis >>> Sep 2012 - WGLC for RFC4743 and 4743 to historic >>> Oct 2012 - submit rfc5539bis to AD/IESG for consideration as >>> Proposed Standard >>> Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 >>> historic >>> Nov 2012 - Collect Implementation/Deployment reports for RFC6241 >>> and 6242 >>> Dec 2012 - Initial I-D for RFC6241/6242 >>> implementation/deployment experience >>> Jan 2013 - WGLC on RFC6241/6242 implementation/deployment >>> experience >>> Feb 2013 - submit RFC6241/6242 implementation/deployment >>> experience doc >>> to IESG for publication as Informational RFC. >>> Mar 2013 - Evaluate if more work needs to be done by NETCONF WG >>> or close WG >>> >>> Bert and Mehmet >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From bclaise@cisco.com Wed Sep 5 07:42:17 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E7321F84C8 for ; Wed, 5 Sep 2012 07:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[AWL=2.600, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEt8SY7t3VnR for ; Wed, 5 Sep 2012 07:42:16 -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 2B42C21F846A for ; Wed, 5 Sep 2012 07:42:16 -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 q85EgDbf029693; Wed, 5 Sep 2012 16:42:13 +0200 (CEST) Received: from [10.60.67.92] (ams-bclaise-89111.cisco.com [10.60.67.92]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q85EgCeC023125; Wed, 5 Sep 2012 16:42:12 +0200 (CEST) Message-ID: <504764C4.5030805@cisco.com> Date: Wed, 05 Sep 2012 16:42:12 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <500929D1.3070107@bwijnen.net> In-Reply-To: <500929D1.3070107@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf Subject: Re: [Netconf] RFC4743 and RFC4744 (Netconf over SOAP and BEEP) to historic X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 14:42:17 -0000 Bert, While the new charter proposal follows its procedure, may I suggest that you post this draft. All the current energy in NETCONF could be used to expedite this draft. Regards, Benoit. > Can't submit a rev 00 I-D at the moment. > > But since we have the "making RFC4743 and RFC4744 to Historic" > topic as part of a possible revised WG charter on the agenda, > I did quickly do an initial writeup, so people can see how > we might approach this. > > I have it attached below. > > Bert > > ---------------------------------------------------------------------- > netconf B. Wijnen > Internet-Draft July 19, 2012 > Obsoletes: 4743/4744 (if approved) > Intended status: Informational > Expires: January 20, 2013 > > > RFC4743 and RFC4744 to Historic status > draft-bwijnen-netconf-rfc4743-rfc4744-to-historic-00 > > Abstract > > This document moves RFC4743 (Using NETCONF over the Simple Object > Access Protocol (SOAP)) and RFC4744 (Using the NETCONF Protocol over > the Blocks Extensible Exchange Protocol (BEEP)) to HISTORIC status to > reflect the fact that those two documents have shown very little (if > any) implementations and deployment. Furthermore, no-one in the > NETCONF WG is nterested or volunteering to work on them anymore. > > Status of this Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on January 20, 2013. > > Copyright Notice > > Copyright (c) 2012 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > > > > Wijnen Expires January 20, 2013 [Page 1] > > Internet-Draft RFC4743-RFC4744-historic July 2012 > > > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3 > 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 > 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 > 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 5.1. Normative References . . . . . . . . . . . . . . . . . . . 3 > 5.2. Informative References . . . . . . . . . . . . . . . . . . 3 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Wijnen Expires January 20, 2013 [Page 2] > > Internet-Draft RFC4743-RFC4744-historic July 2012 > > > 1. Introduction > > This document moves RFC 4743 [RFC4743] and RFC 4744 [RFC4744] to > HISTORIC status in accordance with RFC 2026 [RFC2026]. These have > seen very little (if any) implementations or deployment, and none of > the initial proponents are active in the NETCONF space anymorei. No- > one (else) in the WG is interested or willing to pick up > responsibility for these documents. Possibly changes might be needed > for compatibility with NETCONF 1.1. > > In the WG nobody gave a positive response when asked who is using it > or wants to keep it. > > > 2. Acknowledgements > > Thanks to the original editors/authors of RFC4743 and RFC4744. At > the time, these NETCONF transports seemed to be attractive. > > > 3. IANA Considerations > > This memo includes no request to IANA. > > > 4. Security Considerations > > This draft introduces no new security considerations. > > > 5. References > > 5.1. Normative References > > [RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access > Protocol (SOAP)", RFC 4743, December 2006. > > [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over > the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, > December 2006. > > 5.2. Informative References > > [RFC2026] Bradner, S., "The Internet Standards Process -- Revision > 3", BCP 9, RFC 2026, October 1996. > > > > > > > Wijnen Expires January 20, 2013 [Page 3] > > Internet-Draft RFC4743-RFC4744-historic July 2012 > > > Author's Address > > Bert Wijnen > Schagen 33 > Linschoten, 3461 GL > Netherlands > > Phone: +31 348-407-775 > Email: bertietf@bwijnen.net > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Wijnen Expires January 20, 2013 [Page 4] > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From bertietf@bwijnen.net Wed Sep 5 08:02:17 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA29221F8648 for ; Wed, 5 Sep 2012 08:02:17 -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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzTCgPLiCTBm for ; Wed, 5 Sep 2012 08:02:16 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 71B0E21F85A7 for ; Wed, 5 Sep 2012 08:02:15 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T9H7M-0001r5-6K for netconf@ietf.org; Wed, 05 Sep 2012 17:02:13 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1T9H7L-0002Bg-QL for netconf@ietf.org; Wed, 05 Sep 2012 17:02:12 +0200 Message-ID: <50476973.8080708@bwijnen.net> Date: Wed, 05 Sep 2012 17:02:11 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Netconf References: <3662635EF3C645549721026B9865FCE4@BertLaptop> <5040664E.7030803@bwijnen.net> In-Reply-To: <5040664E.7030803@bwijnen.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120905 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd46c12973169f6e8595e21e3cf13def2f6 Subject: [Netconf] We will do NetConf interop testing on Sat/Sun Nov 3/4 prior to IETF Atlanta X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:02:18 -0000 The doodle poll shows that Saturday and Sunday before the IETF in Atlanta are the best times. See the results yourself at: http://www.doodle.com/nibe3k4c4zuq84mw So set your calendars and arrange your travel for that event on Nov 3/4 from 9-5 each day. We are trying to get/arrange space at the IETF hotel, but we have not secured that space yet. A fallback is to go to NSN facilities just at the outskirts of Atlanta. We hope to have a final decision on the location in the next week or 2. People who still want to register their intent to participate can do so at the doodle poll. We will only accept participant who will bring an implementation ready for testing! I.e. we are unable to cater for visitors or observers. The WG chairs will serve as observers to make sure that the reports are properly done. More info later. Bert and Mehmet On 8/31/12 9:22 AM, Bert Wijnen (IETF) wrote: > Several of the implementers have already agreed to come together > for an Interop Test event just before the Atlanta IETF. > > I created a DOODLE poll to check for the best dates. > If you want to come with your implementation to test, > pls go to the doodle poll and express if you prefer > Friday/Saturday (2-3 Nov) or Saturday/Sunday (3-4 Nov). > PLEASE do so no later than Sept 4th 2012. > > The Event will either be at the IETF hotel or at an NSN facility > in Atalanta (but a bit away from the IETF hotel). > > http://www.doodle.com/nibe3k4c4zuq84mw > > If you plan to participate, > PLEASE fill out the doodle poll no later than Sept 4 > > Bert > > > From andy@yumaworks.com Wed Sep 5 08:02:34 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854B821F8468 for ; Wed, 5 Sep 2012 08:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUJZcnMwToBj for ; Wed, 5 Sep 2012 08:02:33 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2534421F846B for ; Wed, 5 Sep 2012 08:02:33 -0700 (PDT) Received: by qcac10 with SMTP id c10so149167qca.31 for ; Wed, 05 Sep 2012 08:02:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=1PMtdYpqPYm45OlkxqaArYJWJ+RYUHltQ/BC4YQihok=; b=pkhedg5jtYncasMkxE/JSXooqv96SB4RzPQAY269SVoW3JacWonQSWigKKsMsZcBwO rGXaXJu1scrPMWqPExF2AfXPps6cETrDsqh4KJ4s+YiTWVD4Lxxp2ZxmwzcxvcxQIuLI JG8KEhSdAB5B+xjGP7MC+dtaf7/8GfmcUD2qkLUPDT6GklDzQ1C8gBJOnet6FRkPmACS Lz84A2FApe4k7xlVcUERQQvEWKesSYO0XJlw9tE3kX6sXNvHcGuVL+aXiw2Jw2T1JbHn ECyFURrZwIrNGzS+LPGqATEkrDHmEj4JoP2ywVIOhtCAAXJF+oTjk75aDbcXLQP8aXRe WeSg== MIME-Version: 1.0 Received: by 10.224.44.202 with SMTP id b10mr17697970qaf.2.1346857352391; Wed, 05 Sep 2012 08:02:32 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Wed, 5 Sep 2012 08:02:32 -0700 (PDT) In-Reply-To: <504764C4.5030805@cisco.com> References: <500929D1.3070107@bwijnen.net> <504764C4.5030805@cisco.com> Date: Wed, 5 Sep 2012 08:02:32 -0700 Message-ID: From: Andy Bierman To: Benoit Claise Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmLVeJBx45PF8WafmsP8cg4BLXnm+8jDcoNfgfxSYJzFJTSdn0HG18i49fhi3l2CWOILFjd Cc: netconf Subject: Re: [Netconf] RFC4743 and RFC4744 (Netconf over SOAP and BEEP) to historic X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:02:34 -0000 On Wed, Sep 5, 2012 at 7:42 AM, Benoit Claise wrote: > Bert, > > While the new charter proposal follows its procedure, may I suggest that you > post this draft. > All the current energy in NETCONF could be used to expedite this draft. > I hope we follow a process where we articulate and agree on the problems we are attempting to solve, instead of the usual "here's my solution draft, standardize it". We also learned a thing or 2 about operational state with MIBs over 20+ years and I hope we don't ignore that. E.g., we have to pick our discontinuity timestamp, such as /system/clock/current-datetime. Some NETCONF systems have no SNMP agent, so sysUpTime is not appropriate. Also returns everything. That was a mistake from the start. We could have return just config=false. Simple. IMO the WG is looking for an ocean to boil wrt/ operational state, and ignoring the little details that could make a difference right away. > Regards, Benoit. Andy > > >> Can't submit a rev 00 I-D at the moment. >> >> But since we have the "making RFC4743 and RFC4744 to Historic" >> topic as part of a possible revised WG charter on the agenda, >> I did quickly do an initial writeup, so people can see how >> we might approach this. >> >> I have it attached below. >> >> Bert >> >> ---------------------------------------------------------------------- >> netconf B. Wijnen >> Internet-Draft July 19, 2012 >> Obsoletes: 4743/4744 (if approved) >> Intended status: Informational >> Expires: January 20, 2013 >> >> >> RFC4743 and RFC4744 to Historic status >> draft-bwijnen-netconf-rfc4743-rfc4744-to-historic-00 >> >> Abstract >> >> This document moves RFC4743 (Using NETCONF over the Simple Object >> Access Protocol (SOAP)) and RFC4744 (Using the NETCONF Protocol over >> the Blocks Extensible Exchange Protocol (BEEP)) to HISTORIC status to >> reflect the fact that those two documents have shown very little (if >> any) implementations and deployment. Furthermore, no-one in the >> NETCONF WG is nterested or volunteering to work on them anymore. >> >> Status of this Memo >> >> This Internet-Draft is submitted in full conformance with the >> provisions of BCP 78 and BCP 79. >> >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF). Note that other groups may also distribute >> working documents as Internet-Drafts. The list of current Internet- >> Drafts is at http://datatracker.ietf.org/drafts/current/. >> >> Internet-Drafts are draft documents valid for a maximum of six months >> and may be updated, replaced, or obsoleted by other documents at any >> time. It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >> >> This Internet-Draft will expire on January 20, 2013. >> >> Copyright Notice >> >> Copyright (c) 2012 IETF Trust and the persons identified as the >> document authors. All rights reserved. >> >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents >> (http://trustee.ietf.org/license-info) in effect on the date of >> publication of this document. Please review these documents >> carefully, as they describe your rights and restrictions with respect >> to this document. Code Components extracted from this document must >> include Simplified BSD License text as described in Section 4.e of >> >> >> >> Wijnen Expires January 20, 2013 [Page 1] >> >> Internet-Draft RFC4743-RFC4744-historic July 2012 >> >> >> the Trust Legal Provisions and are provided without warranty as >> described in the Simplified BSD License. >> >> >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3 >> 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 >> 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 >> 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 5.1. Normative References . . . . . . . . . . . . . . . . . . . 3 >> 5.2. Informative References . . . . . . . . . . . . . . . . . . 3 >> Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Wijnen Expires January 20, 2013 [Page 2] >> >> Internet-Draft RFC4743-RFC4744-historic July 2012 >> >> >> 1. Introduction >> >> This document moves RFC 4743 [RFC4743] and RFC 4744 [RFC4744] to >> HISTORIC status in accordance with RFC 2026 [RFC2026]. These have >> seen very little (if any) implementations or deployment, and none of >> the initial proponents are active in the NETCONF space anymorei. No- >> one (else) in the WG is interested or willing to pick up >> responsibility for these documents. Possibly changes might be needed >> for compatibility with NETCONF 1.1. >> >> In the WG nobody gave a positive response when asked who is using it >> or wants to keep it. >> >> >> 2. Acknowledgements >> >> Thanks to the original editors/authors of RFC4743 and RFC4744. At >> the time, these NETCONF transports seemed to be attractive. >> >> >> 3. IANA Considerations >> >> This memo includes no request to IANA. >> >> >> 4. Security Considerations >> >> This draft introduces no new security considerations. >> >> >> 5. References >> >> 5.1. Normative References >> >> [RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access >> Protocol (SOAP)", RFC 4743, December 2006. >> >> [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over >> the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, >> December 2006. >> >> 5.2. Informative References >> >> [RFC2026] Bradner, S., "The Internet Standards Process -- Revision >> 3", BCP 9, RFC 2026, October 1996. >> >> >> >> >> >> >> Wijnen Expires January 20, 2013 [Page 3] >> >> Internet-Draft RFC4743-RFC4744-historic July 2012 >> >> >> Author's Address >> >> Bert Wijnen >> Schagen 33 >> Linschoten, 3461 GL >> Netherlands >> >> Phone: +31 348-407-775 >> Email: bertietf@bwijnen.net >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Wijnen Expires January 20, 2013 [Page 4] >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From andy@yumaworks.com Wed Sep 5 08:11:33 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218F421F84DF for ; Wed, 5 Sep 2012 08:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yH5JFB5dLNZd for ; Wed, 5 Sep 2012 08:11:32 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3904D21F8497 for ; Wed, 5 Sep 2012 08:11:32 -0700 (PDT) Received: by qafi29 with SMTP id i29so4320844qaf.10 for ; Wed, 05 Sep 2012 08:11:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=CZZYjp2pgJ+6/e76V6JSAHCSrSu7/wGYND2eBp9R85c=; b=RuXJm5V/66s+MQo0gvgEUUv1MiLTbtfQur5jebZjaD727+BR5cC3OGcueKnj/fCcjG 9ZV9C5CIcVMTjh7F77QEbi53/rtMqEewDQY/wTjbjYkzQUQPrWr0x8baTZVg+0tpjMdx S78wsHbB9kg+WPTVFuPnsGPYHAvkZ7h1jM/GHdDFBA1fQjGjlZmapv55fjv2RHJoja4X 59HkctePfY00aH03sihC29DMk4mTtersIAZ+1InlTyHHMMO2qFbn0U1fzDv+KrPMmXPS yn3jdk6suTUT83F19tOn/D671lKIlbZ3Zy4pH8Jz0M8PRmEVUp27zoBje8yWhQvWoPau rw7g== MIME-Version: 1.0 Received: by 10.224.203.197 with SMTP id fj5mr44904283qab.98.1346857891463; Wed, 05 Sep 2012 08:11:31 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Wed, 5 Sep 2012 08:11:30 -0700 (PDT) In-Reply-To: References: <500929D1.3070107@bwijnen.net> <504764C4.5030805@cisco.com> Date: Wed, 5 Sep 2012 08:11:30 -0700 Message-ID: From: Andy Bierman To: Benoit Claise Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl9bvb9r007ntUzgYcgfqy7LAS9OyDqwF5ODkA9lv5lak7S5EHP/JdPrimcR3d9eqTj1JHR Cc: netconf Subject: Re: [Netconf] RFC4743 and RFC4744 (Netconf over SOAP and BEEP) to historic X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:11:33 -0000 oops -- though I was responding to a +1 on Operational State, not BEEP. Andy On Wed, Sep 5, 2012 at 8:02 AM, Andy Bierman wrote: > On Wed, Sep 5, 2012 at 7:42 AM, Benoit Claise wrote: >> Bert, >> >> While the new charter proposal follows its procedure, may I suggest that you >> post this draft. >> All the current energy in NETCONF could be used to expedite this draft. >> > > I hope we follow a process where we articulate and agree on > the problems we are attempting to solve, instead of the usual > "here's my solution draft, standardize it". > > We also learned a thing or 2 about operational state with MIBs > over 20+ years and I hope we don't ignore that. E.g., we have to > pick our discontinuity timestamp, such as /system/clock/current-datetime. > Some NETCONF systems have no SNMP agent, so sysUpTime > is not appropriate. Also returns everything. That was a mistake > from the start. We could have return just config=false. Simple. > > IMO the WG is looking for an ocean to boil wrt/ operational state, > and ignoring the little details that could make a difference right away. > > >> Regards, Benoit. > > Andy > >> >> >>> Can't submit a rev 00 I-D at the moment. >>> >>> But since we have the "making RFC4743 and RFC4744 to Historic" >>> topic as part of a possible revised WG charter on the agenda, >>> I did quickly do an initial writeup, so people can see how >>> we might approach this. >>> >>> I have it attached below. >>> >>> Bert >>> >>> ---------------------------------------------------------------------- >>> netconf B. Wijnen >>> Internet-Draft July 19, 2012 >>> Obsoletes: 4743/4744 (if approved) >>> Intended status: Informational >>> Expires: January 20, 2013 >>> >>> >>> RFC4743 and RFC4744 to Historic status >>> draft-bwijnen-netconf-rfc4743-rfc4744-to-historic-00 >>> >>> Abstract >>> >>> This document moves RFC4743 (Using NETCONF over the Simple Object >>> Access Protocol (SOAP)) and RFC4744 (Using the NETCONF Protocol over >>> the Blocks Extensible Exchange Protocol (BEEP)) to HISTORIC status to >>> reflect the fact that those two documents have shown very little (if >>> any) implementations and deployment. Furthermore, no-one in the >>> NETCONF WG is nterested or volunteering to work on them anymore. >>> >>> Status of this Memo >>> >>> This Internet-Draft is submitted in full conformance with the >>> provisions of BCP 78 and BCP 79. >>> >>> Internet-Drafts are working documents of the Internet Engineering >>> Task Force (IETF). Note that other groups may also distribute >>> working documents as Internet-Drafts. The list of current Internet- >>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>> >>> Internet-Drafts are draft documents valid for a maximum of six months >>> and may be updated, replaced, or obsoleted by other documents at any >>> time. It is inappropriate to use Internet-Drafts as reference >>> material or to cite them other than as "work in progress." >>> >>> This Internet-Draft will expire on January 20, 2013. >>> >>> Copyright Notice >>> >>> Copyright (c) 2012 IETF Trust and the persons identified as the >>> document authors. All rights reserved. >>> >>> This document is subject to BCP 78 and the IETF Trust's Legal >>> Provisions Relating to IETF Documents >>> (http://trustee.ietf.org/license-info) in effect on the date of >>> publication of this document. Please review these documents >>> carefully, as they describe your rights and restrictions with respect >>> to this document. Code Components extracted from this document must >>> include Simplified BSD License text as described in Section 4.e of >>> >>> >>> >>> Wijnen Expires January 20, 2013 [Page 1] >>> >>> Internet-Draft RFC4743-RFC4744-historic July 2012 >>> >>> >>> the Trust Legal Provisions and are provided without warranty as >>> described in the Simplified BSD License. >>> >>> >>> Table of Contents >>> >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 >>> 2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3 >>> 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 >>> 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 >>> 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3 >>> 5.1. Normative References . . . . . . . . . . . . . . . . . . . 3 >>> 5.2. Informative References . . . . . . . . . . . . . . . . . . 3 >>> Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Wijnen Expires January 20, 2013 [Page 2] >>> >>> Internet-Draft RFC4743-RFC4744-historic July 2012 >>> >>> >>> 1. Introduction >>> >>> This document moves RFC 4743 [RFC4743] and RFC 4744 [RFC4744] to >>> HISTORIC status in accordance with RFC 2026 [RFC2026]. These have >>> seen very little (if any) implementations or deployment, and none of >>> the initial proponents are active in the NETCONF space anymorei. No- >>> one (else) in the WG is interested or willing to pick up >>> responsibility for these documents. Possibly changes might be needed >>> for compatibility with NETCONF 1.1. >>> >>> In the WG nobody gave a positive response when asked who is using it >>> or wants to keep it. >>> >>> >>> 2. Acknowledgements >>> >>> Thanks to the original editors/authors of RFC4743 and RFC4744. At >>> the time, these NETCONF transports seemed to be attractive. >>> >>> >>> 3. IANA Considerations >>> >>> This memo includes no request to IANA. >>> >>> >>> 4. Security Considerations >>> >>> This draft introduces no new security considerations. >>> >>> >>> 5. References >>> >>> 5.1. Normative References >>> >>> [RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access >>> Protocol (SOAP)", RFC 4743, December 2006. >>> >>> [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over >>> the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, >>> December 2006. >>> >>> 5.2. Informative References >>> >>> [RFC2026] Bradner, S., "The Internet Standards Process -- Revision >>> 3", BCP 9, RFC 2026, October 1996. >>> >>> >>> >>> >>> >>> >>> Wijnen Expires January 20, 2013 [Page 3] >>> >>> Internet-Draft RFC4743-RFC4744-historic July 2012 >>> >>> >>> Author's Address >>> >>> Bert Wijnen >>> Schagen 33 >>> Linschoten, 3461 GL >>> Netherlands >>> >>> Phone: +31 348-407-775 >>> Email: bertietf@bwijnen.net >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Wijnen Expires January 20, 2013 [Page 4] >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf From bclaise@cisco.com Wed Sep 5 08:46:49 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316FC21F8672 for ; Wed, 5 Sep 2012 08:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.07 X-Spam-Level: X-Spam-Status: No, score=-8.07 tagged_above=-999 required=5 tests=[AWL=1.928, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+W1evkUPG4g for ; Wed, 5 Sep 2012 08:46:48 -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 7E14221F8670 for ; Wed, 5 Sep 2012 08:46:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q85FkhWh006463; Wed, 5 Sep 2012 17:46:44 +0200 (CEST) Received: from [10.60.67.92] (ams-bclaise-89111.cisco.com [10.60.67.92]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q85Fkhwp020585; Wed, 5 Sep 2012 17:46:43 +0200 (CEST) Message-ID: <504773E2.1080807@cisco.com> Date: Wed, 05 Sep 2012 17:46:42 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Andy Bierman References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net> <502E0A3B.9010008@bwijnen.net> <504763E9.3040600@cisco.com> In-Reply-To: <504763E9.3040600@cisco.com> Content-Type: multipart/alternative; boundary="------------030705070101050205000806" Cc: netconf Subject: [Netconf] Operational State: Re: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:46:49 -0000 This is a multi-part message in MIME format. --------------030705070101050205000806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andy, I cut and pasted your answer into the right email thread, for readability: Andy> I hope we follow a process where we articulate and agree on the problems we are attempting to solve, instead of the usual "here's my solution draft, standardize it". No disagreement here. For the people interested in writing a draft on the operational data (I believe I've seen some interest from Martin and Lada), that's a good advice: let's define the problem statement. Andy> We also learned a thing or 2 about operational state with MIBs over 20+ years and I hope we don't ignore that. E.g., we have to pick our discontinuity timestamp, such as /system/clock/current-datetime. Some NETCONF systems have no SNMP agent, so sysUpTime is not appropriate. Also returns everything. That was a mistake from the start. We could have return just config=false. Simple. IMO the WG is looking for an ocean to boil wrt/ operational state, and ignoring the little details that could make a difference right away. Personally, one problem I see is: a WG charter including a entry for management They might look at NETCONF/YANG, but then the next question is: I have config data, but also operational state and counters. So is NETCONF/YANG suitable? Regards, Benoit > + 1 > > Regards, Benoit. >> We had agreed in our last f2f meeting that people would submit >> individual I-Ds, and based on that we would potentially >> consider work in this space. So by all means do submit >> such individual drafts and discuss them on the mailing list. >> >> But we do not have a good problem statement or starting I-D >> to base this work on, so cannot put it on the current charter. >> >> Bert Wijnen >> >> On 8/17/12 11:04 AM, Ladislav Lhotka wrote: >>> Hi, >>> >>> I had the impression that there was a reasonable agreement that work >>> on operational state data is needed. Although this problem lies >>> somewhere between NETCONF and NETMOD, I think the NETCONF WG is now >>> in a better position to start this work because apparently NETMOD WG >>> will have to continue the work on the core data models for some time. >>> >>> So I propose the following fourth item for the charter: >>> >>> 4. The WG will investigate the relationship and interactions between >>> configurations and >>> operational state data, propose their appropriate representation >>> and semantics, and >>> devise methods for effective data modeling of both >>> configurations and operational state data. >>> It is expected that this work will be carried out in a close >>> sooperation with the NETMOD WG. >>> >>> Lada >>> >>> "Bert Wijnen (IETF)" writes: >>> >>>> Based on the comments and feedback and the positions >>>> expressed on the mailing list, it is clear that after all >>>> we did NOT have consensus on the new WG charter. >>>> >>>> Without further ado, this is another proposed WG charter. >>>> It focuses on the things that we do seme to have agreement on. >>>> >>>> Pls comment and/or express your support or objections >>>> no later than August 31, 2012. >>>> >>>> OK, new chapter text (omitting the description of what we have >>>> achieved sofar): >>>> >>>> In the current phase of the incremental development of NETCONF the >>>> workgroup will focus on following items: >>>> >>>> 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. >>>> This means that RFC5593 needs to be updated. >>>> >>>> 2. Based on the implementation, deployment experience and >>>> interoperability >>>> testing, the WG will document the status of NETCONF in a >>>> report. >>>> Based on this, the WG may decide to make some clarifications to >>>> RFC6241 and RFC6242 (then also fixing any reported errata). >>>> >>>> 3. Since Netconf over BEEP and over SOAP seem not being deployed >>>> the WG will write a document that makes those 2 protocols >>>> (RFC4743 and RFC4744) HISTORIC. >>>> >>>> Goals and Milestones: >>>> done - Send with-defaults to IESG for consideration as >>>> Proposed Standard >>>> done - WG Last Call on rfc4741bis >>>> done - rfc4741bis to IESG for consideration as Proposed >>>> Standard >>>> done - Send rfc4742bis to IESG for consideration as >>>> proposed Standard. >>>> done - first WG draft (rev 00) on NACM posted >>>> done - first WG draft (rev 00) on NETCONF specific YANG >>>> modules posted >>>> done - WGLC for NACM document >>>> done - WGLC for NETCONF specific notifications document >>>> done - submit NACM document to IESG for consideration as >>>> Proposed Standard >>>> done - submit NETCONF specific notifications document to >>>> IESG for >>>> consideration as Proposed Standard >>>> Aug 2012 - submit initial WG draft for rfc5539bis >>>> Aug 2012 - submit initial WG draft for making RFC4743 and >>>> RFC4744 historic. >>>> Sep 2012 - WGLC for rfc5539bis >>>> Sep 2012 - WGLC for RFC4743 and 4743 to historic >>>> Oct 2012 - submit rfc5539bis to AD/IESG for consideration as >>>> Proposed Standard >>>> Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 >>>> historic >>>> Nov 2012 - Collect Implementation/Deployment reports for >>>> RFC6241 and 6242 >>>> Dec 2012 - Initial I-D for RFC6241/6242 >>>> implementation/deployment experience >>>> Jan 2013 - WGLC on RFC6241/6242 implementation/deployment >>>> experience >>>> Feb 2013 - submit RFC6241/6242 implementation/deployment >>>> experience doc >>>> to IESG for publication as Informational RFC. >>>> Mar 2013 - Evaluate if more work needs to be done by NETCONF WG >>>> or close WG >>>> >>>> Bert and Mehmet >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --------------030705070101050205000806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Andy,

I cut and pasted your answer into the right email thread, for readability:
Andy> I hope we follow a process where we articulate and agree on
the problems we are attempting to solve, instead of the usual
"here's my solution draft, standardize it".
No disagreement here. For the people interested in writing a draft on the operational data (I believe I've seen some interest from Martin and Lada), that's a good advice: let's define the problem statement. 
Andy> We also learned a thing or 2 about operational state with MIBs
over 20+ years and I hope we don't ignore that.  E.g., we have to
pick our discontinuity timestamp, such as /system/clock/current-datetime.
Some NETCONF systems have no SNMP agent, so sysUpTime
is not appropriate. Also <get> returns everything. That was a mistake
from the start. We could have <get2> return just config=false.  Simple.

IMO the WG is looking for an ocean to boil wrt/ operational state,
and ignoring the little details that could make a difference right away.

Personally, one problem I see is: a WG charter including a entry for management
They might look at NETCONF/YANG, but then the next question is: I have config data, but also operational state and counters. So is NETCONF/YANG suitable?

Regards, Benoit


    

    
+ 1
      

      

      Regards, Benoit.
      

      
We had agreed in our last f2f meeting that
        people would submit
        

        individual I-Ds, and based on that we would potentially
        

        consider work in this space. So by all means do submit
        

        such individual drafts and discuss them on the mailing list.
        

        

        But we do not have a good problem statement or starting I-D
        

        to base this work on, so cannot put it on the current charter.
        

        

        Bert Wijnen
        

        

        On 8/17/12 11:04 AM, Ladislav Lhotka wrote:
        

        
Hi,
          

          

          I had the impression that there was a reasonable agreement
          that work on operational state data is needed. Although this
          problem lies somewhere between NETCONF and NETMOD, I think the
          NETCONF WG is now in a better position to start this work
          because apparently NETMOD WG will have to continue the work on
          the core data models for some time.
          

          

          So I propose the following fourth item for the charter:
          

          

          4. The WG will investigate the relationship and interactions
          between configurations and
          

              operational state data, propose their appropriate
          representation and semantics, and
          

              devise methods for effective data modeling of both
          configurations and operational state data.
          

              It is expected that this work will be carried out in a
          close sooperation with the NETMOD WG.
          

          

          Lada
          

          

          "Bert Wijnen (IETF)" <bertietf@bwijnen.net> writes:
          

          

          
Based on the comments and feedback and
            the positions
            

            expressed on the mailing list, it is clear that after all
            

            we did NOT have consensus on the new WG charter.
            

            

            Without further ado, this is another proposed WG charter.
            

            It focuses on the things that we do seme to have agreement
            on.
            

            

            Pls comment and/or express your support or objections
            

            no later than August 31, 2012.
            

            

            OK, new chapter text (omitting the description of what we
            have
            

            achieved sofar):
            

            

                In the current phase of the incremental development of
            NETCONF the
            

                workgroup will focus on following items:
            

            

                1. Advance NETCONF over TLS to be in-line with NETCONF
            1:1.
            

                   This means that RFC5593 needs to be updated.
            

            

                2. Based on the implementation, deployment experience
            and interoperability
            

                   testing, the WG will document the status of NETCONF
            in a report.
            

                   Based on this, the WG may decide to make some
            clarifications to
            

                   RFC6241 and RFC6242 (then also fixing any reported
            errata).
            

            

                3. Since Netconf over BEEP and over SOAP seem not being
            deployed
            

                   the WG will write a document that makes those 2
            protocols
            

                   (RFC4743 and RFC4744) HISTORIC.
            

            

            Goals and Milestones:
            

                done     - Send with-defaults to IESG for consideration
            as Proposed Standard
            

                done     - WG Last Call on rfc4741bis
            

                done     - rfc4741bis to IESG for consideration as
            Proposed Standard
            

                done     - Send rfc4742bis to IESG for consideration as
            proposed Standard.
            

                done     - first WG draft (rev 00) on NACM posted
            

                done     - first WG draft (rev 00) on NETCONF specific
            YANG modules posted
            

                done     - WGLC for NACM document
            

                done     - WGLC for NETCONF specific notifications
            document
            

                done     - submit NACM document to IESG for
            consideration as Proposed Standard
            

                done     - submit NETCONF specific notifications 
            document to IESG for
            

                           consideration as Proposed Standard
            

                Aug 2012 - submit initial WG draft for rfc5539bis
            

                Aug 2012 - submit initial WG draft for making RFC4743
            and RFC4744 historic.
            

                Sep 2012 - WGLC for rfc5539bis
            

                Sep 2012 - WGLC for RFC4743 and 4743 to historic
            

                Oct 2012 - submit rfc5539bis to AD/IESG for
            consideration as Proposed Standard
            

                Oct 2012 - submit request to AD/IESG to make RFC4743 and
            4744 historic
            

                Nov 2012 - Collect Implementation/Deployment reports for
            RFC6241 and 6242
            

                Dec 2012 - Initial I-D for RFC6241/6242
            implementation/deployment experience
            

                Jan 2013 - WGLC on RFC6241/6242
            implementation/deployment experience
            

                Feb 2013 - submit RFC6241/6242 implementation/deployment
            experience doc
            

                           to IESG for publication as Informational RFC.
            

                Mar 2013 - Evaluate if more work needs to be done by
            NETCONF WG or close WG
            

            

            Bert and Mehmet
            

            _______________________________________________
            

            Netconf mailing list
            

            Netconf@ietf.org
            

            https://www.ietf.org/mailman/listinfo/netconf
            

          

          

        

        _______________________________________________
        

        Netconf mailing list
        

        Netconf@ietf.org
        

        https://www.ietf.org/mailman/listinfo/netconf
        

        

        

      

      

      _______________________________________________
      

      Netconf mailing list
      

      Netconf@ietf.org
      

      https://www.ietf.org/mailman/listinfo/netconf
      

      

      

    

    

  


--------------030705070101050205000806--

From andy@yumaworks.com  Wed Sep  5 09:03:42 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC1B21F8669 for ; Wed,  5 Sep 2012 09:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.077
X-Spam-Level: 
X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mkkb0783UCKq for ; Wed,  5 Sep 2012 09:03:41 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E01B21F8667 for ; Wed,  5 Sep 2012 09:03:41 -0700 (PDT)
Received: by qafi29 with SMTP id i29so4364943qaf.10 for ; Wed, 05 Sep 2012 09:03:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=BKJvdJpnng4Tah1J5NJOsz5W+veic7s2twdDoWkTAFg=; b=a9qs4QPgJbDQ5iw7C2DakjsBWn4XKhPpTmqs2R6nNzCMwLRWaDc0ZIQ6jfj1L5lbEJ HfbOEtFhf1+/qLcfLC6Jy15EgYyinbMZk+i1V439RvauVFZca0XFOrFHtaAeytlGluIv 9GxJd5x2gFQb7G/EsH+XiG6AM0y6+obxiuyBkAfxFD6W+4VX9H/FW54mnf3tRfX2qea9 Z723Q+Jr6ti8NLTwE9BV7rfRMbwbn5NgJN019wDMg9VlEqW96OR5DrS5I24bByOao6Ti EhNwziSW4sejRm7+j4ubyn36vt6c/2//FLiWD4/v6ueNF9E8HhS4WFjEfsjwb/PKdmRv jXqg==
MIME-Version: 1.0
Received: by 10.224.175.204 with SMTP id bb12mr11630298qab.14.1346861020724; Wed, 05 Sep 2012 09:03:40 -0700 (PDT)
Received: by 10.49.35.230 with HTTP; Wed, 5 Sep 2012 09:03:40 -0700 (PDT)
In-Reply-To: <504773E2.1080807@cisco.com>
References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net>  <502E0A3B.9010008@bwijnen.net> <504763E9.3040600@cisco.com> <504773E2.1080807@cisco.com>
Date: Wed, 5 Sep 2012 09:03:40 -0700
Message-ID: 
From: Andy Bierman 
To: Benoit Claise 
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQlWqhyC2SPDCGIt6K0RiGB0Gkg2vAlRWUiuW7GaF1XYshyhbIZg6dkKqSTR+l8HwKVe1WAH
Cc: netconf 
Subject: Re: [Netconf] Operational State: Re: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Sep 2012 16:03:42 -0000

On Wed, Sep 5, 2012 at 8:46 AM, Benoit Claise  wrote:
> Andy,
>
> I cut and pasted your answer into the right email thread, for readability:
>
> Andy> I hope we follow a process where we articulate and agree on
> the problems we are attempting to solve, instead of the usual
> "here's my solution draft, standardize it".
>
> No disagreement here. For the people interested in writing a draft on the
> operational data (I believe I've seen some interest from Martin and Lada),
> that's a good advice: let's define the problem statement.
>
> Andy> We also learned a thing or 2 about operational state with MIBs
> over 20+ years and I hope we don't ignore that.  E.g., we have to
> pick our discontinuity timestamp, such as /system/clock/current-datetime.
> Some NETCONF systems have no SNMP agent, so sysUpTime
> is not appropriate. Also  returns everything. That was a mistake
> from the start. We could have  return just config=false.  Simple.
>
> IMO the WG is looking for an ocean to boil wrt/ operational state,
> and ignoring the little details that could make a difference right away.
>
>
> Personally, one problem I see is: a WG charter including a entry for
> management
> They might look at NETCONF/YANG, but then the next question is: I have
> config data, but also operational state and counters. So is NETCONF/YANG
> suitable?


Companies are taking 2 different approaches (or a mix of both)
  - mixing config=false data nodes with config=true nodes and using 
  - creating custom RPC  operations to provide specific data,
    often matching CLI show commands

IMO NETCONF can be even better than SNMP for monitoring,
depending on the application and data model.  SNMP has no
real filtering like subtree or XPath. (SNMP doesn't have real
sub-trees, it has data scattered all over).  If the INDEX gets big
(e.g., RMON2) then SNMP performance is awful, as the naming
is 90% of the data, duplicated in every varbind.

I don't think replacing standard monitoring MIBs with YANG modules
is worth doing, but I would not classify SNMP as good for monitoring,
and NETCONF as inappropriate for monitoring.

>
> Regards, Benoit
>


Andy

> + 1
>
> Regards, Benoit.
>
> We had agreed in our last f2f meeting that people would submit
> individual I-Ds, and based on that we would potentially
> consider work in this space. So by all means do submit
> such individual drafts and discuss them on the mailing list.
>
> But we do not have a good problem statement or starting I-D
> to base this work on, so cannot put it on the current charter.
>
> Bert Wijnen
>
> On 8/17/12 11:04 AM, Ladislav Lhotka wrote:
>
> Hi,
>
> I had the impression that there was a reasonable agreement that work on
> operational state data is needed. Although this problem lies somewhere
> between NETCONF and NETMOD, I think the NETCONF WG is now in a better
> position to start this work because apparently NETMOD WG will have to
> continue the work on the core data models for some time.
>
> So I propose the following fourth item for the charter:
>
> 4. The WG will investigate the relationship and interactions between
> configurations and
>     operational state data, propose their appropriate representation and
> semantics, and
>     devise methods for effective data modeling of both configurations and
> operational state data.
>     It is expected that this work will be carried out in a close sooperation
> with the NETMOD WG.
>
> Lada
>
> "Bert Wijnen (IETF)"  writes:
>
> Based on the comments and feedback and the positions
> expressed on the mailing list, it is clear that after all
> we did NOT have consensus on the new WG charter.
>
> Without further ado, this is another proposed WG charter.
> It focuses on the things that we do seme to have agreement on.
>
> Pls comment and/or express your support or objections
> no later than August 31, 2012.
>
> OK, new chapter text (omitting the description of what we have
> achieved sofar):
>
>     In the current phase of the incremental development of NETCONF the
>     workgroup will focus on following items:
>
>     1. Advance NETCONF over TLS to be in-line with NETCONF 1:1.
>        This means that RFC5593 needs to be updated.
>
>     2. Based on the implementation, deployment experience and
> interoperability
>        testing, the WG will document the status of NETCONF in a report.
>        Based on this, the WG may decide to make some clarifications to
>        RFC6241 and RFC6242 (then also fixing any reported errata).
>
>     3. Since Netconf over BEEP and over SOAP seem not being deployed
>        the WG will write a document that makes those 2 protocols
>        (RFC4743 and RFC4744) HISTORIC.
>
> Goals and Milestones:
>     done     - Send with-defaults to IESG for consideration as Proposed
> Standard
>     done     - WG Last Call on rfc4741bis
>     done     - rfc4741bis to IESG for consideration as Proposed Standard
>     done     - Send rfc4742bis to IESG for consideration as proposed
> Standard.
>     done     - first WG draft (rev 00) on NACM posted
>     done     - first WG draft (rev 00) on NETCONF specific YANG modules
> posted
>     done     - WGLC for NACM document
>     done     - WGLC for NETCONF specific notifications document
>     done     - submit NACM document to IESG for consideration as Proposed
> Standard
>     done     - submit NETCONF specific notifications  document to IESG for
>                consideration as Proposed Standard
>     Aug 2012 - submit initial WG draft for rfc5539bis
>     Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744
> historic.
>     Sep 2012 - WGLC for rfc5539bis
>     Sep 2012 - WGLC for RFC4743 and 4743 to historic
>     Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed
> Standard
>     Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic
>     Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and
> 6242
>     Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment
> experience
>     Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience
>     Feb 2013 - submit RFC6241/6242 implementation/deployment experience doc
>                to IESG for publication as Informational RFC.
>     Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or close
> WG
>
> Bert and Mehmet
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
>

From pgili@cisco.com  Wed Sep  5 09:10:12 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957F921F869E for ; Wed,  5 Sep 2012 09:10:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.799
X-Spam-Level: 
X-Spam-Status: No, score=-8.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DReZdfWNwrHO for ; Wed,  5 Sep 2012 09:10:11 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCE521F8681 for ; Wed,  5 Sep 2012 09:10:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgili@cisco.com; l=8275; q=dns/txt; s=iport; t=1346861411; x=1348071011; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=x4VUkTrD+3Nk72e7186nm5bKS6k2AyHz+NZZUtKw06M=; b=kdpBmaMH25cRQa7u98oh3uOo9m+EOcA9C3bJqzSupr4CCadfFJQgwXsn /PeSymOuStU8jr79MvAxide1BzSA99y2htgJ74KV3KnKiB0MKemZR9iHn PLy1RTvJz6ysoQHgLqonHSPcXVnawGMDMjLnF4925OwN3XSveHSSq+W/A I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAOd4R1CtJXG+/2dsb2JhbABFuySBB4IgAQEBAwEBAQEPASctBwQHDAQCAQgRBAEBAQoUBQQHJwsUCQgCBAENBQgTB4dlBguaPKAtBIsRhiJgA6QMgWeCY4Fh
X-IronPort-AV: E=Sophos;i="4.80,375,1344211200"; d="scan'208";a="118534076"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 05 Sep 2012 16:10:10 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q85GAAdc007122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Sep 2012 16:10:10 GMT
Received: from xmb-aln-x14.cisco.com ([169.254.8.192]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Wed, 5 Sep 2012 11:10:09 -0500
From: "Patrick Gili (pgili)" 
To: Andy Bierman , "Benoit Claise (bclaise)" 
Thread-Topic: [Netconf] Operational State: Re: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st
Thread-Index: AQHNi32vroH4pz/sJk21+V664K5QgJd8PN0A//+sy3A=
Date: Wed, 5 Sep 2012 16:10:07 +0000
Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB04DA91@xmb-aln-x14.cisco.com>
References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net>  <502E0A3B.9010008@bwijnen.net> <504763E9.3040600@cisco.com> <504773E2.1080807@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.86.254.102]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19164.003
x-tm-as-result: No--42.303800-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: netconf 
Subject: Re: [Netconf] Operational State: Re: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Sep 2012 16:10:12 -0000

Benoit,

I fully support Andy's sentiments regarding NETCONF+YANG. I think it is ful=
ly capable of dealing with both configuration and operational data. However=
, the one point that I don't necessarily agree with his statement, "I don't=
 think replacing standard monitoring MIBs with YANG modules is worth doing,=
 but I would not classify SNMP as good for monitoring, and NETCONF as inapp=
ropriate for monitoring." We're receiving quite a different message from cu=
stomers--in fact, we have customers expressing a desire to abandon everythi=
ng for NETCONF, including syslog, SNMP, RADIUS, DHCP, RADIUS, and other pro=
tocols used today for the exchange of data.

Patrick

-----Original Message-----
From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf =
Of Andy Bierman
Sent: Wednesday, September 05, 2012 12:04 PM
To: Benoit Claise (bclaise)
Cc: netconf
Subject: Re: [Netconf] Operational State: Re: New WGLC for a proposed new W=
G Charter - respond BEFORE Sept 1st

On Wed, Sep 5, 2012 at 8:46 AM, Benoit Claise  wrote:
> Andy,
>
> I cut and pasted your answer into the right email thread, for readability=
:
>
> Andy> I hope we follow a process where we articulate and agree on
> the problems we are attempting to solve, instead of the usual "here's=20
> my solution draft, standardize it".
>
> No disagreement here. For the people interested in writing a draft on=20
> the operational data (I believe I've seen some interest from Martin=20
> and Lada), that's a good advice: let's define the problem statement.
>
> Andy> We also learned a thing or 2 about operational state with MIBs
> over 20+ years and I hope we don't ignore that.  E.g., we have to pick=20
> our discontinuity timestamp, such as /system/clock/current-datetime.
> Some NETCONF systems have no SNMP agent, so sysUpTime is not=20
> appropriate. Also  returns everything. That was a mistake from=20
> the start. We could have  return just config=3Dfalse.  Simple.
>
> IMO the WG is looking for an ocean to boil wrt/ operational state, and=20
> ignoring the little details that could make a difference right away.
>
>
> Personally, one problem I see is: a WG charter including a entry for=20
> management They might look at NETCONF/YANG, but then the next question=20
> is: I have config data, but also operational state and counters. So is=20
> NETCONF/YANG suitable?


Companies are taking 2 different approaches (or a mix of both)
  - mixing config=3Dfalse data nodes with config=3Dtrue nodes and using 
  - creating custom RPC  operations to provide specific data,
    often matching CLI show commands

IMO NETCONF can be even better than SNMP for monitoring, depending on the a=
pplication and data model.  SNMP has no real filtering like subtree or XPat=
h. (SNMP doesn't have real sub-trees, it has data scattered all over).  If =
the INDEX gets big (e.g., RMON2) then SNMP performance is awful, as the nam=
ing is 90% of the data, duplicated in every varbind.

I don't think replacing standard monitoring MIBs with YANG modules is worth=
 doing, but I would not classify SNMP as good for monitoring, and NETCONF a=
s inappropriate for monitoring.

>
> Regards, Benoit
>


Andy

> + 1
>
> Regards, Benoit.
>
> We had agreed in our last f2f meeting that people would submit=20
> individual I-Ds, and based on that we would potentially consider work=20
> in this space. So by all means do submit such individual drafts and=20
> discuss them on the mailing list.
>
> But we do not have a good problem statement or starting I-D to base=20
> this work on, so cannot put it on the current charter.
>
> Bert Wijnen
>
> On 8/17/12 11:04 AM, Ladislav Lhotka wrote:
>
> Hi,
>
> I had the impression that there was a reasonable agreement that work=20
> on operational state data is needed. Although this problem lies=20
> somewhere between NETCONF and NETMOD, I think the NETCONF WG is now in=20
> a better position to start this work because apparently NETMOD WG will=20
> have to continue the work on the core data models for some time.
>
> So I propose the following fourth item for the charter:
>
> 4. The WG will investigate the relationship and interactions between=20
> configurations and
>     operational state data, propose their appropriate representation=20
> and semantics, and
>     devise methods for effective data modeling of both configurations=20
> and operational state data.
>     It is expected that this work will be carried out in a close=20
> sooperation with the NETMOD WG.
>
> Lada
>
> "Bert Wijnen (IETF)"  writes:
>
> Based on the comments and feedback and the positions expressed on the=20
> mailing list, it is clear that after all we did NOT have consensus on=20
> the new WG charter.
>
> Without further ado, this is another proposed WG charter.
> It focuses on the things that we do seme to have agreement on.
>
> Pls comment and/or express your support or objections no later than=20
> August 31, 2012.
>
> OK, new chapter text (omitting the description of what we have=20
> achieved sofar):
>
>     In the current phase of the incremental development of NETCONF the
>     workgroup will focus on following items:
>
>     1. Advance NETCONF over TLS to be in-line with NETCONF 1:1.
>        This means that RFC5593 needs to be updated.
>
>     2. Based on the implementation, deployment experience and=20
> interoperability
>        testing, the WG will document the status of NETCONF in a report.
>        Based on this, the WG may decide to make some clarifications to
>        RFC6241 and RFC6242 (then also fixing any reported errata).
>
>     3. Since Netconf over BEEP and over SOAP seem not being deployed
>        the WG will write a document that makes those 2 protocols
>        (RFC4743 and RFC4744) HISTORIC.
>
> Goals and Milestones:
>     done     - Send with-defaults to IESG for consideration as Proposed
> Standard
>     done     - WG Last Call on rfc4741bis
>     done     - rfc4741bis to IESG for consideration as Proposed Standard
>     done     - Send rfc4742bis to IESG for consideration as proposed
> Standard.
>     done     - first WG draft (rev 00) on NACM posted
>     done     - first WG draft (rev 00) on NETCONF specific YANG modules
> posted
>     done     - WGLC for NACM document
>     done     - WGLC for NETCONF specific notifications document
>     done     - submit NACM document to IESG for consideration as Proposed
> Standard
>     done     - submit NETCONF specific notifications  document to IESG fo=
r
>                consideration as Proposed Standard
>     Aug 2012 - submit initial WG draft for rfc5539bis
>     Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744=20
> historic.
>     Sep 2012 - WGLC for rfc5539bis
>     Sep 2012 - WGLC for RFC4743 and 4743 to historic
>     Oct 2012 - submit rfc5539bis to AD/IESG for consideration as=20
> Proposed Standard
>     Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 histori=
c
>     Nov 2012 - Collect Implementation/Deployment reports for RFC6241=20
> and
> 6242
>     Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment=20
> experience
>     Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience
>     Feb 2013 - submit RFC6241/6242 implementation/deployment experience d=
oc
>                to IESG for publication as Informational RFC.
>     Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or=20
> close WG
>
> Bert and Mehmet
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
>
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

From dromasca@avaya.com  Wed Sep  5 09:28:37 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6708821F8678 for ; Wed,  5 Sep 2012 09:28:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.455
X-Spam-Level: 
X-Spam-Status: No, score=-103.455 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7bEEfijywKK for ; Wed,  5 Sep 2012 09:28:37 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id A7F4321F84CE for ; Wed,  5 Sep 2012 09:28:36 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAMZ8R1DGmAcF/2dsb2JhbABFuySBB4IgAQEBAQMSHgo/DAQCAQgNCA0GDAcEAQYBRREBAQQBEggah2udUZ02kTNgA5taihmCZQ
X-IronPort-AV: E=Sophos;i="4.80,375,1344225600"; d="scan'208";a="323567217"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Sep 2012 12:24:35 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Sep 2012 12:22:05 -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: Wed, 5 Sep 2012 18:28:32 +0200
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Netconf] Operational State: Re: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st
Thread-Index: Ac2LgA8Qk81a+ltERgKH5q5v4MEfdQAArwKw
References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net> <502E0A3B.9010008@bwijnen.net><504763E9.3040600@cisco.com> <504773E2.1080807@cisco.com> 
From: "Romascanu, Dan (Dan)" 
To: "Andy Bierman" , "Benoit Claise" 
Cc: netconf 
Subject: Re: [Netconf] Operational State: Re: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Sep 2012 16:28:37 -0000

> -----Original Message-----
> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On
> Behalf Of Andy Bierman
>=20
> IMO NETCONF can be even better than SNMP for monitoring, depending on
> the application and data model.  SNMP has no real filtering like
subtree
> or XPath. (SNMP doesn't have real sub-trees, it has data scattered all
> over).  If the INDEX gets big (e.g., RMON2) then SNMP performance is
> awful, as the naming is 90% of the data, duplicated in every varbind.
>=20
> I don't think replacing standard monitoring MIBs with YANG modules is
> worth doing, but I would not classify SNMP as good for monitoring, and
> NETCONF as inappropriate for monitoring.
>=20

Do we have information that can help us to compare performance for
retrieving monitoring information (and we need to be more specific here
- are we talking about large tables of counters, or something else?)
using the two protocols? The fact that SNMP is not efficient because of
the indexation scheme is not relevant, what is important is how it
compares on the wire with fetching the same amount of information using
NETCONF/YANG.=20

Dan


From alex@cisco.com  Wed Sep  5 10:28:44 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B6821F8670 for ; Wed,  5 Sep 2012 10:28:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.699
X-Spam-Level: 
X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riOuCGtf1Zdo for ; Wed,  5 Sep 2012 10:28:43 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9907A21F863B for ; Wed,  5 Sep 2012 10:28:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7891; q=dns/txt; s=iport; t=1346866123; x=1348075723; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Lqxs8Wg1gGDpuJaEld9nyI4n7n2oZuorrmVDptOfZqk=; b=dI+XFZws616ZaWQCPTemZYJbg7tSAFUo55UKLsdaADDqCQaeP2nHObqf nN0IsmZr9cbAZmTvMpGaQlljWJDc+VV99ph8LxoBWDXXkjk3lfkKqlInm CEzoa3NpwCLJ6621w4HzCcyao5wv240Tva4GrsqljfexE1Igl67Y9M28Z Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFADSLR1CtJV2a/2dsb2JhbABFuySBB4IgAQEBAwEBAQEPASctBwQHDAQCAQgRBAEBAQoUBQQHJwsUCQgCBAENBQgTB4dlBguaWKAnBIsRFYYNYAOkDIFngmOBWQg
X-IronPort-AV: E=Sophos;i="4.80,375,1344211200"; d="scan'208";a="115546837"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 05 Sep 2012 17:28:42 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q85HSgcw003107 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Sep 2012 17:28:42 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.54]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Wed, 5 Sep 2012 12:28:41 -0500
From: "Alexander Clemm (alex)" 
To: Andy Bierman , "Benoit Claise (bclaise)" 
Thread-Topic: [Netconf] Operational State: Re: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st
Thread-Index: AQHNi32vEwcyZxkS3k2cyDOEfCaNTZd8PN0A///C/xA=
Date: Wed, 5 Sep 2012 17:28:41 +0000
Message-ID: 
References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net>  <502E0A3B.9010008@bwijnen.net> <504763E9.3040600@cisco.com> <504773E2.1080807@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.169.63]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19164.003
x-tm-as-result: No--51.888500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: netconf 
Subject: Re: [Netconf] Operational State: Re: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Sep 2012 17:28:44 -0000

+1 on the 

One advantage in the context of Netconf/Yang vs SNMP is the inherent suppor=
t for scoping.
For monitoring, I do think there are some additional requirements to consid=
er that limit Netconf's (but not Yang's) appeal in certain scenarios, e.g. =
in managed service provider scenarios the requirement to maintain an associ=
ation and have it initiated from the manager

--- Alex

-----Original Message-----
From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf =
Of Andy Bierman
Sent: Wednesday, September 05, 2012 9:04 AM
To: Benoit Claise (bclaise)
Cc: netconf
Subject: Re: [Netconf] Operational State: Re: New WGLC for a proposed new W=
G Charter - respond BEFORE Sept 1st

On Wed, Sep 5, 2012 at 8:46 AM, Benoit Claise  wrote:
> Andy,
>
> I cut and pasted your answer into the right email thread, for readability=
:
>
> Andy> I hope we follow a process where we articulate and agree on
> the problems we are attempting to solve, instead of the usual
> "here's my solution draft, standardize it".
>
> No disagreement here. For the people interested in writing a draft on the
> operational data (I believe I've seen some interest from Martin and Lada)=
,
> that's a good advice: let's define the problem statement.
>
> Andy> We also learned a thing or 2 about operational state with MIBs
> over 20+ years and I hope we don't ignore that.  E.g., we have to
> pick our discontinuity timestamp, such as /system/clock/current-datetime.
> Some NETCONF systems have no SNMP agent, so sysUpTime
> is not appropriate. Also  returns everything. That was a mistake
> from the start. We could have  return just config=3Dfalse.  Simple.
>
> IMO the WG is looking for an ocean to boil wrt/ operational state,
> and ignoring the little details that could make a difference right away.
>
>
> Personally, one problem I see is: a WG charter including a entry for
> management
> They might look at NETCONF/YANG, but then the next question is: I have
> config data, but also operational state and counters. So is NETCONF/YANG
> suitable?


Companies are taking 2 different approaches (or a mix of both)
  - mixing config=3Dfalse data nodes with config=3Dtrue nodes and using 
  - creating custom RPC  operations to provide specific data,
    often matching CLI show commands

IMO NETCONF can be even better than SNMP for monitoring,
depending on the application and data model.  SNMP has no
real filtering like subtree or XPath. (SNMP doesn't have real
sub-trees, it has data scattered all over).  If the INDEX gets big
(e.g., RMON2) then SNMP performance is awful, as the naming
is 90% of the data, duplicated in every varbind.

I don't think replacing standard monitoring MIBs with YANG modules
is worth doing, but I would not classify SNMP as good for monitoring,
and NETCONF as inappropriate for monitoring.

>
> Regards, Benoit
>


Andy

> + 1
>
> Regards, Benoit.
>
> We had agreed in our last f2f meeting that people would submit
> individual I-Ds, and based on that we would potentially
> consider work in this space. So by all means do submit
> such individual drafts and discuss them on the mailing list.
>
> But we do not have a good problem statement or starting I-D
> to base this work on, so cannot put it on the current charter.
>
> Bert Wijnen
>
> On 8/17/12 11:04 AM, Ladislav Lhotka wrote:
>
> Hi,
>
> I had the impression that there was a reasonable agreement that work on
> operational state data is needed. Although this problem lies somewhere
> between NETCONF and NETMOD, I think the NETCONF WG is now in a better
> position to start this work because apparently NETMOD WG will have to
> continue the work on the core data models for some time.
>
> So I propose the following fourth item for the charter:
>
> 4. The WG will investigate the relationship and interactions between
> configurations and
>     operational state data, propose their appropriate representation and
> semantics, and
>     devise methods for effective data modeling of both configurations and
> operational state data.
>     It is expected that this work will be carried out in a close sooperat=
ion
> with the NETMOD WG.
>
> Lada
>
> "Bert Wijnen (IETF)"  writes:
>
> Based on the comments and feedback and the positions
> expressed on the mailing list, it is clear that after all
> we did NOT have consensus on the new WG charter.
>
> Without further ado, this is another proposed WG charter.
> It focuses on the things that we do seme to have agreement on.
>
> Pls comment and/or express your support or objections
> no later than August 31, 2012.
>
> OK, new chapter text (omitting the description of what we have
> achieved sofar):
>
>     In the current phase of the incremental development of NETCONF the
>     workgroup will focus on following items:
>
>     1. Advance NETCONF over TLS to be in-line with NETCONF 1:1.
>        This means that RFC5593 needs to be updated.
>
>     2. Based on the implementation, deployment experience and
> interoperability
>        testing, the WG will document the status of NETCONF in a report.
>        Based on this, the WG may decide to make some clarifications to
>        RFC6241 and RFC6242 (then also fixing any reported errata).
>
>     3. Since Netconf over BEEP and over SOAP seem not being deployed
>        the WG will write a document that makes those 2 protocols
>        (RFC4743 and RFC4744) HISTORIC.
>
> Goals and Milestones:
>     done     - Send with-defaults to IESG for consideration as Proposed
> Standard
>     done     - WG Last Call on rfc4741bis
>     done     - rfc4741bis to IESG for consideration as Proposed Standard
>     done     - Send rfc4742bis to IESG for consideration as proposed
> Standard.
>     done     - first WG draft (rev 00) on NACM posted
>     done     - first WG draft (rev 00) on NETCONF specific YANG modules
> posted
>     done     - WGLC for NACM document
>     done     - WGLC for NETCONF specific notifications document
>     done     - submit NACM document to IESG for consideration as Proposed
> Standard
>     done     - submit NETCONF specific notifications  document to IESG fo=
r
>                consideration as Proposed Standard
>     Aug 2012 - submit initial WG draft for rfc5539bis
>     Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744
> historic.
>     Sep 2012 - WGLC for rfc5539bis
>     Sep 2012 - WGLC for RFC4743 and 4743 to historic
>     Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed
> Standard
>     Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 histori=
c
>     Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and
> 6242
>     Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment
> experience
>     Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience
>     Feb 2013 - submit RFC6241/6242 implementation/deployment experience d=
oc
>                to IESG for publication as Informational RFC.
>     Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or cl=
ose
> WG
>
> Bert and Mehmet
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
>
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

From andy@yumaworks.com  Wed Sep  5 11:12:05 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDD321F8680 for ; Wed,  5 Sep 2012 11:12:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.702
X-Spam-Level: 
X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWYMsHgr4YD4 for ; Wed,  5 Sep 2012 11:12:04 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1A821F856C for ; Wed,  5 Sep 2012 11:12:04 -0700 (PDT)
Received: by qafi29 with SMTP id i29so4461864qaf.10 for ; Wed, 05 Sep 2012 11:12:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=vz1pC3vgKDmY3149ZhHHbjRCQFE77sP4k71OGP7oD1M=; b=UzHZraShME0EdnBnQqF/uzqBXRcwlDUBcNfbMnz0e2jbtNSpwuq4dDRtXQmWRcZXhG Wymsvjz1DflKa4xEmDN9nkziR82bFL6YkgfDaDAOfSYOVsYGxDRoIgRQc1ulX6gihc4r Hblj+pvyQBgapA3A1/Gny27G3oE7RzMIzSwY4z6Vuy8VTMHAAcBG99ZMJxCGPB4J+j1l kRMlwxng/wMjSfkFQvoBLEgdNtzHJkKGq5tshWOANmmRp0EgVw8iTWmWBNW7jQYUZqPR OuGh3/s+0hbdE5XXX84KfIvyt291t7e7eHefCRAwPismaK4XhIu5V1iddQwSvdwE3lO8 PVpg==
MIME-Version: 1.0
Received: by 10.224.203.197 with SMTP id fj5mr45978678qab.98.1346868723579; Wed, 05 Sep 2012 11:12:03 -0700 (PDT)
Received: by 10.49.35.230 with HTTP; Wed, 5 Sep 2012 11:12:03 -0700 (PDT)
In-Reply-To: <50E64ADF99EAEE4CACEC18958F0FC0AB04DA91@xmb-aln-x14.cisco.com>
References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net>  <502E0A3B.9010008@bwijnen.net> <504763E9.3040600@cisco.com> <504773E2.1080807@cisco.com>  <50E64ADF99EAEE4CACEC18958F0FC0AB04DA91@xmb-aln-x14.cisco.com>
Date: Wed, 5 Sep 2012 11:12:03 -0700
Message-ID: 
From: Andy Bierman 
To: "Patrick Gili (pgili)" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQk8jJHoA7ZVH1MFq7tLFJgF5jWUuBxp1n1wypE+09R1Jp6gR37coPnGayBGlM2FO2tUAbmL
Cc: netconf 
Subject: Re: [Netconf] Operational State: Re: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Sep 2012 18:12:05 -0000

Interesting data point.

I meant that the SMI2YANG conversion of most MIB modules
is good enough, and a standards effort to rewrite them would take
too long.

Andy


On Wed, Sep 5, 2012 at 9:10 AM, Patrick Gili (pgili)  wrot=
e:
> Benoit,
>
> I fully support Andy's sentiments regarding NETCONF+YANG. I think it is f=
ully capable of dealing with both configuration and operational data. Howev=
er, the one point that I don't necessarily agree with his statement, "I don=
't think replacing standard monitoring MIBs with YANG modules is worth doin=
g, but I would not classify SNMP as good for monitoring, and NETCONF as ina=
ppropriate for monitoring." We're receiving quite a different message from =
customers--in fact, we have customers expressing a desire to abandon everyt=
hing for NETCONF, including syslog, SNMP, RADIUS, DHCP, RADIUS, and other p=
rotocols used today for the exchange of data.
>
> Patrick
>
> -----Original Message-----
> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behal=
f Of Andy Bierman
> Sent: Wednesday, September 05, 2012 12:04 PM
> To: Benoit Claise (bclaise)
> Cc: netconf
> Subject: Re: [Netconf] Operational State: Re: New WGLC for a proposed new=
 WG Charter - respond BEFORE Sept 1st
>
> On Wed, Sep 5, 2012 at 8:46 AM, Benoit Claise  wrote:
>> Andy,
>>
>> I cut and pasted your answer into the right email thread, for readabilit=
y:
>>
>> Andy> I hope we follow a process where we articulate and agree on
>> the problems we are attempting to solve, instead of the usual "here's
>> my solution draft, standardize it".
>>
>> No disagreement here. For the people interested in writing a draft on
>> the operational data (I believe I've seen some interest from Martin
>> and Lada), that's a good advice: let's define the problem statement.
>>
>> Andy> We also learned a thing or 2 about operational state with MIBs
>> over 20+ years and I hope we don't ignore that.  E.g., we have to pick
>> our discontinuity timestamp, such as /system/clock/current-datetime.
>> Some NETCONF systems have no SNMP agent, so sysUpTime is not
>> appropriate. Also  returns everything. That was a mistake from
>> the start. We could have  return just config=3Dfalse.  Simple.
>>
>> IMO the WG is looking for an ocean to boil wrt/ operational state, and
>> ignoring the little details that could make a difference right away.
>>
>>
>> Personally, one problem I see is: a WG charter including a entry for
>> management They might look at NETCONF/YANG, but then the next question
>> is: I have config data, but also operational state and counters. So is
>> NETCONF/YANG suitable?
>
>
> Companies are taking 2 different approaches (or a mix of both)
>   - mixing config=3Dfalse data nodes with config=3Dtrue nodes and using <=
get>
>   - creating custom RPC  operations to provide specific data,
>     often matching CLI show commands
>
> IMO NETCONF can be even better than SNMP for monitoring, depending on the=
 application and data model.  SNMP has no real filtering like subtree or XP=
ath. (SNMP doesn't have real sub-trees, it has data scattered all over).  I=
f the INDEX gets big (e.g., RMON2) then SNMP performance is awful, as the n=
aming is 90% of the data, duplicated in every varbind.
>
> I don't think replacing standard monitoring MIBs with YANG modules is wor=
th doing, but I would not classify SNMP as good for monitoring, and NETCONF=
 as inappropriate for monitoring.
>
>>
>> Regards, Benoit
>>
>
>
> Andy
>
>> + 1
>>
>> Regards, Benoit.
>>
>> We had agreed in our last f2f meeting that people would submit
>> individual I-Ds, and based on that we would potentially consider work
>> in this space. So by all means do submit such individual drafts and
>> discuss them on the mailing list.
>>
>> But we do not have a good problem statement or starting I-D to base
>> this work on, so cannot put it on the current charter.
>>
>> Bert Wijnen
>>
>> On 8/17/12 11:04 AM, Ladislav Lhotka wrote:
>>
>> Hi,
>>
>> I had the impression that there was a reasonable agreement that work
>> on operational state data is needed. Although this problem lies
>> somewhere between NETCONF and NETMOD, I think the NETCONF WG is now in
>> a better position to start this work because apparently NETMOD WG will
>> have to continue the work on the core data models for some time.
>>
>> So I propose the following fourth item for the charter:
>>
>> 4. The WG will investigate the relationship and interactions between
>> configurations and
>>     operational state data, propose their appropriate representation
>> and semantics, and
>>     devise methods for effective data modeling of both configurations
>> and operational state data.
>>     It is expected that this work will be carried out in a close
>> sooperation with the NETMOD WG.
>>
>> Lada
>>
>> "Bert Wijnen (IETF)"  writes:
>>
>> Based on the comments and feedback and the positions expressed on the
>> mailing list, it is clear that after all we did NOT have consensus on
>> the new WG charter.
>>
>> Without further ado, this is another proposed WG charter.
>> It focuses on the things that we do seme to have agreement on.
>>
>> Pls comment and/or express your support or objections no later than
>> August 31, 2012.
>>
>> OK, new chapter text (omitting the description of what we have
>> achieved sofar):
>>
>>     In the current phase of the incremental development of NETCONF the
>>     workgroup will focus on following items:
>>
>>     1. Advance NETCONF over TLS to be in-line with NETCONF 1:1.
>>        This means that RFC5593 needs to be updated.
>>
>>     2. Based on the implementation, deployment experience and
>> interoperability
>>        testing, the WG will document the status of NETCONF in a report.
>>        Based on this, the WG may decide to make some clarifications to
>>        RFC6241 and RFC6242 (then also fixing any reported errata).
>>
>>     3. Since Netconf over BEEP and over SOAP seem not being deployed
>>        the WG will write a document that makes those 2 protocols
>>        (RFC4743 and RFC4744) HISTORIC.
>>
>> Goals and Milestones:
>>     done     - Send with-defaults to IESG for consideration as Proposed
>> Standard
>>     done     - WG Last Call on rfc4741bis
>>     done     - rfc4741bis to IESG for consideration as Proposed Standard
>>     done     - Send rfc4742bis to IESG for consideration as proposed
>> Standard.
>>     done     - first WG draft (rev 00) on NACM posted
>>     done     - first WG draft (rev 00) on NETCONF specific YANG modules
>> posted
>>     done     - WGLC for NACM document
>>     done     - WGLC for NETCONF specific notifications document
>>     done     - submit NACM document to IESG for consideration as Propose=
d
>> Standard
>>     done     - submit NETCONF specific notifications  document to IESG f=
or
>>                consideration as Proposed Standard
>>     Aug 2012 - submit initial WG draft for rfc5539bis
>>     Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744
>> historic.
>>     Sep 2012 - WGLC for rfc5539bis
>>     Sep 2012 - WGLC for RFC4743 and 4743 to historic
>>     Oct 2012 - submit rfc5539bis to AD/IESG for consideration as
>> Proposed Standard
>>     Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 histor=
ic
>>     Nov 2012 - Collect Implementation/Deployment reports for RFC6241
>> and
>> 6242
>>     Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment
>> experience
>>     Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience
>>     Feb 2013 - submit RFC6241/6242 implementation/deployment experience =
doc
>>                to IESG for publication as Informational RFC.
>>     Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or
>> close WG
>>
>> Bert and Mehmet
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>>
>>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

From j.schoenwaelder@jacobs-university.de  Wed Sep  5 11:40:34 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDAAC21F8685 for ; Wed,  5 Sep 2012 11:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level: 
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nc8C2HLOcUIR for ; Wed,  5 Sep 2012 11:40:33 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 30CFA21F8686 for ; Wed,  5 Sep 2012 11:40:31 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3089B20C57; Wed,  5 Sep 2012 20:40:30 +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 Py8IPWQOFhXF; Wed,  5 Sep 2012 20:40:30 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7947D20C56; Wed,  5 Sep 2012 20:40:29 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id E78E1218FD1D; Wed,  5 Sep 2012 20:40:24 +0200 (CEST)
Date: Wed, 5 Sep 2012 20:40:24 +0200
From: Juergen Schoenwaelder 
To: "Romascanu, Dan (Dan)" 
Message-ID: <20120905184024.GA59496@elstar.local>
Mail-Followup-To: "Romascanu, Dan (Dan)" , Andy Bierman , Benoit Claise , netconf 
References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net>  <502E0A3B.9010008@bwijnen.net> <504763E9.3040600@cisco.com> <504773E2.1080807@cisco.com>  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netconf 
Subject: Re: [Netconf] Operational State: Re: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Sep 2012 18:40:34 -0000

On Wed, Sep 05, 2012 at 06:28:32PM +0200, Romascanu, Dan (Dan) wrote:
> 
> Do we have information that can help us to compare performance for
> retrieving monitoring information (and we need to be more specific here
> - are we talking about large tables of counters, or something else?)
> using the two protocols? The fact that SNMP is not efficient because of
> the indexation scheme is not relevant, what is important is how it
> compares on the wire with fetching the same amount of information using
> NETCONF/YANG. 
> 

While such performance considerations are highly relevant in some
context, there are lots of contexts where the time to implement a
robust management solution is key, not just the on the wire efficiency.

That said, there have been academic studies comparing SNMP with
alternatives and the common pattern was that SNMP is always winning
for regular infrequent polls for little amounts of information while
it tends to loose on larger data transfers. A starting point to dig
into this is this survey.

@Article{AFLPS09,
  author =       "L. Andrey and O. Festor and A. Lahmadi and A. Pras and
                 J. Sch{\"o}nw{\"a}lder",
  title =        "{Survey of SNMP Performance Analysis Studies}",
  journal =      "International Journal of Network Management",
  volume =       "19",
  number =       "6",
  pages =        "527--548",
  publisher =    "Wiley",
  year =         "2009",
}

Of course, published in 2009, it does not cover newer papers on this
topic.

But once again, the efficiency with which one can build robust
applications is in certain environments more important than just the
plain on the wire efficiency.

/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  Wed Sep  5 12:10:18 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A1121F86F2 for ; Wed,  5 Sep 2012 12:10:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.05
X-Spam-Level: 
X-Spam-Status: No, score=-0.05 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6, J_CHICKENPOX_65=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOqMYDSCBuVU for ; Wed,  5 Sep 2012 12:10:17 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) by ietfa.amsl.com (Postfix) with ESMTP id ACA4D21F85B8 for ; Wed,  5 Sep 2012 12:10:16 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7452213F807; Wed,  5 Sep 2012 21:09:54 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1346872194; bh=pcU/MGO3iRpT3far3GsaLpOWED9RoAd08x9o34CAtu8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=evodSdNFEonmrem02JQ2yCK+bJ3fC9+/f66phit0E5DFgUN16fVJQdyj/rUXMpR5F 9G3/MLl3pJWYImfK/qhP53bhj2HsKSpRyHNm5J2GrAVg8xibPdNwKxQMADuJH9/cwe R2uVJTDGDon4fg3rWXqyIwXlMhGIVDWykSP91TJ4=
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
From: Ladislav Lhotka 
In-Reply-To: <504773E2.1080807@cisco.com>
Date: Wed, 5 Sep 2012 21:09:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <11650CFE-67D8-4382-8CF7-A143D96F6663@nic.cz>
References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net>  <502E0A3B.9010008@bwijnen.net> <504763E9.3040600@cisco.com> <504773E2.1080807@cisco.com>
To: Benoit Claise 
X-Mailer: Apple Mail (2.1486)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netconf 
Subject: Re: [Netconf] Operational State: Re: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Sep 2012 19:10:18 -0000

On Sep 5, 2012, at 5:46 PM, Benoit Claise  wrote:

> Andy,
>=20
> I cut and pasted your answer into the right email thread, for =
readability:
> Andy> I hope we follow a process where we articulate and agree on
> the problems we are attempting to solve, instead of the usual
> "here's my solution draft, standardize it".
>=20
>=20
> No disagreement here. For the people interested in writing a draft on =
the operational data (I believe I've seen some interest from Martin and =
Lada), that's a good advice: let's define the problem statement.
> Andy> We also learned a thing or 2 about operational state with MIBs
> over 20+ years and I hope we don't ignore that.  E.g., we have to
> pick our discontinuity timestamp, such as =
/system/clock/current-datetime.
> Some NETCONF systems have no SNMP agent, so sysUpTime
> is not appropriate. Also  returns everything. That was a mistake
> from the start. We could have  return just config=3Dfalse.  =
Simple.
>=20
> IMO the WG is looking for an ocean to boil wrt/ operational state,
> and ignoring the little details that could make a difference right =
away.
>=20
>=20
> Personally, one problem I see is: a WG charter including a entry for =
management
> They might look at NETCONF/YANG, but then the next question is: I have =
config data, but also operational state and counters. So is NETCONF/YANG =
suitable?

Right, and it is also the problem statement you are asking for: The =
existing NETMOD core modules do not model, for the most part, =
operational state data, mainly because there is no easy way to do so =
with the existing YANG semantics.

For one, there has has to be a way for finding out, via NETCONF, IP =
addresses that are in operational use on an interface. =20

Lada

>=20
> Regards, Benoit
>=20
>> + 1=20
>>=20
>> Regards, Benoit.=20
>>> We had agreed in our last f2f meeting that people would submit=20
>>> individual I-Ds, and based on that we would potentially=20
>>> consider work in this space. So by all means do submit=20
>>> such individual drafts and discuss them on the mailing list.=20
>>>=20
>>> But we do not have a good problem statement or starting I-D=20
>>> to base this work on, so cannot put it on the current charter.=20
>>>=20
>>> Bert Wijnen=20
>>>=20
>>> On 8/17/12 11:04 AM, Ladislav Lhotka wrote:=20
>>>> Hi,=20
>>>>=20
>>>> I had the impression that there was a reasonable agreement that =
work on operational state data is needed. Although this problem lies =
somewhere between NETCONF and NETMOD, I think the NETCONF WG is now in a =
better position to start this work because apparently NETMOD WG will =
have to continue the work on the core data models for some time.=20
>>>>=20
>>>> So I propose the following fourth item for the charter:=20
>>>>=20
>>>> 4. The WG will investigate the relationship and interactions =
between configurations and=20
>>>>     operational state data, propose their appropriate =
representation and semantics, and=20
>>>>     devise methods for effective data modeling of both =
configurations and operational state data.=20
>>>>     It is expected that this work will be carried out in a close =
sooperation with the NETMOD WG.=20
>>>>=20
>>>> Lada=20
>>>>=20
>>>> "Bert Wijnen (IETF)"  writes:=20
>>>>=20
>>>>> Based on the comments and feedback and the positions=20
>>>>> expressed on the mailing list, it is clear that after all=20
>>>>> we did NOT have consensus on the new WG charter.=20
>>>>>=20
>>>>> Without further ado, this is another proposed WG charter.=20
>>>>> It focuses on the things that we do seme to have agreement on.=20
>>>>>=20
>>>>> Pls comment and/or express your support or objections=20
>>>>> no later than August 31, 2012.=20
>>>>>=20
>>>>> OK, new chapter text (omitting the description of what we have=20
>>>>> achieved sofar):=20
>>>>>=20
>>>>>     In the current phase of the incremental development of NETCONF =
the=20
>>>>>     workgroup will focus on following items:=20
>>>>>=20
>>>>>     1. Advance NETCONF over TLS to be in-line with NETCONF 1:1.=20
>>>>>        This means that RFC5593 needs to be updated.=20
>>>>>=20
>>>>>     2. Based on the implementation, deployment experience and =
interoperability=20
>>>>>        testing, the WG will document the status of NETCONF in a =
report.=20
>>>>>        Based on this, the WG may decide to make some =
clarifications to=20
>>>>>        RFC6241 and RFC6242 (then also fixing any reported errata).=20=

>>>>>=20
>>>>>     3. Since Netconf over BEEP and over SOAP seem not being =
deployed=20
>>>>>        the WG will write a document that makes those 2 protocols=20=

>>>>>        (RFC4743 and RFC4744) HISTORIC.=20
>>>>>=20
>>>>> Goals and Milestones:=20
>>>>>     done     - Send with-defaults to IESG for consideration as =
Proposed Standard=20
>>>>>     done     - WG Last Call on rfc4741bis=20
>>>>>     done     - rfc4741bis to IESG for consideration as Proposed =
Standard=20
>>>>>     done     - Send rfc4742bis to IESG for consideration as =
proposed Standard.=20
>>>>>     done     - first WG draft (rev 00) on NACM posted=20
>>>>>     done     - first WG draft (rev 00) on NETCONF specific YANG =
modules posted=20
>>>>>     done     - WGLC for NACM document=20
>>>>>     done     - WGLC for NETCONF specific notifications document=20
>>>>>     done     - submit NACM document to IESG for consideration as =
Proposed Standard=20
>>>>>     done     - submit NETCONF specific notifications  document to =
IESG for=20
>>>>>                consideration as Proposed Standard=20
>>>>>     Aug 2012 - submit initial WG draft for rfc5539bis=20
>>>>>     Aug 2012 - submit initial WG draft for making RFC4743 and =
RFC4744 historic.=20
>>>>>     Sep 2012 - WGLC for rfc5539bis=20
>>>>>     Sep 2012 - WGLC for RFC4743 and 4743 to historic=20
>>>>>     Oct 2012 - submit rfc5539bis to AD/IESG for consideration as =
Proposed Standard=20
>>>>>     Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 =
historic=20
>>>>>     Nov 2012 - Collect Implementation/Deployment reports for =
RFC6241 and 6242=20
>>>>>     Dec 2012 - Initial I-D for RFC6241/6242 =
implementation/deployment experience=20
>>>>>     Jan 2013 - WGLC on RFC6241/6242 implementation/deployment =
experience=20
>>>>>     Feb 2013 - submit RFC6241/6242 implementation/deployment =
experience doc=20
>>>>>                to IESG for publication as Informational RFC.=20
>>>>>     Mar 2013 - Evaluate if more work needs to be done by NETCONF =
WG or close WG=20
>>>>>=20
>>>>> Bert and Mehmet=20
>>>>> _______________________________________________=20
>>>>> Netconf mailing list=20
>>>>> Netconf@ietf.org=20
>>>>> https://www.ietf.org/mailman/listinfo/netconf=20
>>>>=20
>>> _______________________________________________=20
>>> Netconf mailing list=20
>>> Netconf@ietf.org=20
>>> https://www.ietf.org/mailman/listinfo/netconf=20
>>>=20
>>>=20
>>=20
>> _______________________________________________=20
>> Netconf mailing list=20
>> Netconf@ietf.org=20
>> https://www.ietf.org/mailman/listinfo/netconf=20
>>=20
>>=20
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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





From andy@yumaworks.com  Wed Sep  5 12:17:51 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C948321F8526 for ; Wed,  5 Sep 2012 12:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gRcsJv+tgCZ for ; Wed,  5 Sep 2012 12:17:51 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B812121F848B for ; Wed,  5 Sep 2012 12:17:50 -0700 (PDT)
Received: by qcac10 with SMTP id c10so358568qca.31 for ; Wed, 05 Sep 2012 12:17:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=V9lMSp2kpl1jsJIfocurAc5rYyq+Xea1SuEvsuG5GZM=; b=lOZU3lLt7MwCGAh+VMgF+JIiuAgTvkFnjvnue9bkF+cnyPgrLxH7SNNdvJORhByXt3 20QPPlAtMc/bCW+Wz1xoe3jM1Scnp4PPKSSxQeSs9esmFgURqKpYVMuGDHyI5ekQHmuN jo6dMa2xKFqFwOeWX1eLwm8s2zKN6b14GOB/dcsIJm8KiXqSv6P3bbVoc5SrDLHyr7l5 otXPWLDSeROE+QlZzhFh6ZhOGPBZofT+6oQke/DDUjAeUgwEr8h/kUqaMQRc3LXb33p3 ACaSUeuVND00uPkgRlOhzo37qHRi7lKsqzFpzsv3khzd2ZWLBGYU68wLhUz+0LlIkIVL IzoA==
MIME-Version: 1.0
Received: by 10.224.184.72 with SMTP id cj8mr195137qab.11.1346872669688; Wed, 05 Sep 2012 12:17:49 -0700 (PDT)
Received: by 10.49.35.230 with HTTP; Wed, 5 Sep 2012 12:17:49 -0700 (PDT)
In-Reply-To: <11650CFE-67D8-4382-8CF7-A143D96F6663@nic.cz>
References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net>  <502E0A3B.9010008@bwijnen.net> <504763E9.3040600@cisco.com> <504773E2.1080807@cisco.com> <11650CFE-67D8-4382-8CF7-A143D96F6663@nic.cz>
Date: Wed, 5 Sep 2012 12:17:49 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnMl8bCR7/Yaw+nyCRh1/DzYtWJNLN9u2PsvbDqAPuvphfX1VpgL1sXgqv50J+zBIFC95JR
Cc: netconf 
Subject: Re: [Netconf] Operational State: Re: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Sep 2012 19:17:51 -0000

On Wed, Sep 5, 2012 at 12:09 PM, Ladislav Lhotka  wrote:
>
> On Sep 5, 2012, at 5:46 PM, Benoit Claise  wrote:
>
>> Andy,
>>
>> I cut and pasted your answer into the right email thread, for readabilit=
y:
>> Andy> I hope we follow a process where we articulate and agree on
>> the problems we are attempting to solve, instead of the usual
>> "here's my solution draft, standardize it".
>>
>>
>> No disagreement here. For the people interested in writing a draft on th=
e operational data (I believe I've seen some interest from Martin and Lada)=
, that's a good advice: let's define the problem statement.
>> Andy> We also learned a thing or 2 about operational state with MIBs
>> over 20+ years and I hope we don't ignore that.  E.g., we have to
>> pick our discontinuity timestamp, such as /system/clock/current-datetime=
.
>> Some NETCONF systems have no SNMP agent, so sysUpTime
>> is not appropriate. Also  returns everything. That was a mistake
>> from the start. We could have  return just config=3Dfalse.  Simple=
.
>>
>> IMO the WG is looking for an ocean to boil wrt/ operational state,
>> and ignoring the little details that could make a difference right away.
>>
>>
>> Personally, one problem I see is: a WG charter including a entry for man=
agement
>> They might look at NETCONF/YANG, but then the next question is: I have c=
onfig data, but also operational state and counters. So is NETCONF/YANG sui=
table?
>
> Right, and it is also the problem statement you are asking for: The exist=
ing NETMOD core modules do not model, for the most part, operational state =
data, mainly because there is no easy way to do so with the existing YANG s=
emantics.
>
> For one, there has has to be a way for finding out, via NETCONF, IP addre=
sses that are in operational use on an interface.
>

Why can't you just write a YANG list for that, or add a config=3Dfalse
boolean leaf 'operational-use' to the config list?



> Lada

Andy

>
>>
>> Regards, Benoit
>>
>>> + 1
>>>
>>> Regards, Benoit.
>>>> We had agreed in our last f2f meeting that people would submit
>>>> individual I-Ds, and based on that we would potentially
>>>> consider work in this space. So by all means do submit
>>>> such individual drafts and discuss them on the mailing list.
>>>>
>>>> But we do not have a good problem statement or starting I-D
>>>> to base this work on, so cannot put it on the current charter.
>>>>
>>>> Bert Wijnen
>>>>
>>>> On 8/17/12 11:04 AM, Ladislav Lhotka wrote:
>>>>> Hi,
>>>>>
>>>>> I had the impression that there was a reasonable agreement that work =
on operational state data is needed. Although this problem lies somewhere b=
etween NETCONF and NETMOD, I think the NETCONF WG is now in a better positi=
on to start this work because apparently NETMOD WG will have to continue th=
e work on the core data models for some time.
>>>>>
>>>>> So I propose the following fourth item for the charter:
>>>>>
>>>>> 4. The WG will investigate the relationship and interactions between =
configurations and
>>>>>     operational state data, propose their appropriate representation =
and semantics, and
>>>>>     devise methods for effective data modeling of both configurations=
 and operational state data.
>>>>>     It is expected that this work will be carried out in a close soop=
eration with the NETMOD WG.
>>>>>
>>>>> Lada
>>>>>
>>>>> "Bert Wijnen (IETF)"  writes:
>>>>>
>>>>>> Based on the comments and feedback and the positions
>>>>>> expressed on the mailing list, it is clear that after all
>>>>>> we did NOT have consensus on the new WG charter.
>>>>>>
>>>>>> Without further ado, this is another proposed WG charter.
>>>>>> It focuses on the things that we do seme to have agreement on.
>>>>>>
>>>>>> Pls comment and/or express your support or objections
>>>>>> no later than August 31, 2012.
>>>>>>
>>>>>> OK, new chapter text (omitting the description of what we have
>>>>>> achieved sofar):
>>>>>>
>>>>>>     In the current phase of the incremental development of NETCONF t=
he
>>>>>>     workgroup will focus on following items:
>>>>>>
>>>>>>     1. Advance NETCONF over TLS to be in-line with NETCONF 1:1.
>>>>>>        This means that RFC5593 needs to be updated.
>>>>>>
>>>>>>     2. Based on the implementation, deployment experience and intero=
perability
>>>>>>        testing, the WG will document the status of NETCONF in a repo=
rt.
>>>>>>        Based on this, the WG may decide to make some clarifications =
to
>>>>>>        RFC6241 and RFC6242 (then also fixing any reported errata).
>>>>>>
>>>>>>     3. Since Netconf over BEEP and over SOAP seem not being deployed
>>>>>>        the WG will write a document that makes those 2 protocols
>>>>>>        (RFC4743 and RFC4744) HISTORIC.
>>>>>>
>>>>>> Goals and Milestones:
>>>>>>     done     - Send with-defaults to IESG for consideration as Propo=
sed Standard
>>>>>>     done     - WG Last Call on rfc4741bis
>>>>>>     done     - rfc4741bis to IESG for consideration as Proposed Stan=
dard
>>>>>>     done     - Send rfc4742bis to IESG for consideration as proposed=
 Standard.
>>>>>>     done     - first WG draft (rev 00) on NACM posted
>>>>>>     done     - first WG draft (rev 00) on NETCONF specific YANG modu=
les posted
>>>>>>     done     - WGLC for NACM document
>>>>>>     done     - WGLC for NETCONF specific notifications document
>>>>>>     done     - submit NACM document to IESG for consideration as Pro=
posed Standard
>>>>>>     done     - submit NETCONF specific notifications  document to IE=
SG for
>>>>>>                consideration as Proposed Standard
>>>>>>     Aug 2012 - submit initial WG draft for rfc5539bis
>>>>>>     Aug 2012 - submit initial WG draft for making RFC4743 and RFC474=
4 historic.
>>>>>>     Sep 2012 - WGLC for rfc5539bis
>>>>>>     Sep 2012 - WGLC for RFC4743 and 4743 to historic
>>>>>>     Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Pro=
posed Standard
>>>>>>     Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 hi=
storic
>>>>>>     Nov 2012 - Collect Implementation/Deployment reports for RFC6241=
 and 6242
>>>>>>     Dec 2012 - Initial I-D for RFC6241/6242 implementation/deploymen=
t experience
>>>>>>     Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experi=
ence
>>>>>>     Feb 2013 - submit RFC6241/6242 implementation/deployment experie=
nce doc
>>>>>>                to IESG for publication as Informational RFC.
>>>>>>     Mar 2013 - Evaluate if more work needs to be done by NETCONF WG =
or close WG
>>>>>>
>>>>>> Bert and Mehmet
>>>>>> _______________________________________________
>>>>>> Netconf mailing list
>>>>>> Netconf@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>>>
>>>> _______________________________________________
>>>> Netconf mailing list
>>>> Netconf@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>>>
>>>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>

From lhotka@nic.cz  Thu Sep  6 00:12:42 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654A321F844F for ; Thu,  6 Sep 2012 00:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.425
X-Spam-Level: 
X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[AWL=0.374,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SmWb7ducD8v for ; Thu,  6 Sep 2012 00:12:41 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4D02521F845B for ; Thu,  6 Sep 2012 00:12:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 4DDE354021F; Thu,  6 Sep 2012 09:12:38 +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 8XqSRm4+Imxc; Thu,  6 Sep 2012 09:12:31 +0200 (CEST)
Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 0A88F5401E6; Thu,  6 Sep 2012 09:12:29 +0200 (CEST)
From: Ladislav Lhotka 
To: Andy Bierman 
In-Reply-To: 
References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net>  <502E0A3B.9010008@bwijnen.net> <504763E9.3040600@cisco.com> <504773E2.1080807@cisco.com> <11650CFE-67D8-4382-8CF7-A143D96F6663@nic.cz> 
User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0)
Date: Thu, 06 Sep 2012 09:12:28 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: netconf 
Subject: Re: [Netconf] Operational State: Re: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Sep 2012 07:12:42 -0000

Andy Bierman  writes:

> On Wed, Sep 5, 2012 at 12:09 PM, Ladislav Lhotka  wrote:
>>
>> On Sep 5, 2012, at 5:46 PM, Benoit Claise  wrote:
>>
>>> Andy,
>>>
>>> I cut and pasted your answer into the right email thread, for readability:
>>> Andy> I hope we follow a process where we articulate and agree on
>>> the problems we are attempting to solve, instead of the usual
>>> "here's my solution draft, standardize it".
>>>
>>>
>>> No disagreement here. For the people interested in writing a draft on the operational data (I believe I've seen some interest from Martin and Lada), that's a good advice: let's define the problem statement.
>>> Andy> We also learned a thing or 2 about operational state with MIBs
>>> over 20+ years and I hope we don't ignore that.  E.g., we have to
>>> pick our discontinuity timestamp, such as /system/clock/current-datetime.
>>> Some NETCONF systems have no SNMP agent, so sysUpTime
>>> is not appropriate. Also  returns everything. That was a mistake
>>> from the start. We could have  return just config=false.  Simple.
>>>
>>> IMO the WG is looking for an ocean to boil wrt/ operational state,
>>> and ignoring the little details that could make a difference right away.
>>>
>>>
>>> Personally, one problem I see is: a WG charter including a entry for management
>>> They might look at NETCONF/YANG, but then the next question is: I have config data, but also operational state and counters. So is NETCONF/YANG suitable?
>>
>> Right, and it is also the problem statement you are asking for: The existing NETMOD core modules do not model, for the most part, operational state data, mainly because there is no easy way to do so with the existing YANG semantics.
>>
>> For one, there has has to be a way for finding out, via NETCONF, IP addresses that are in operational use on an interface.
>>
>
> Why can't you just write a YANG list for that, or add a config=false
> boolean leaf 'operational-use' to the config list?

You can, but then you have some addresses in the configuration and some addresses in state data and the data model doesn't give you any information about how they are related, except perhaps in descriptions.

It is often the case that data nodes appear in pairs - once as configuration and once as state data, and these two may or may not be the same, depending on other circumstances. We could indeed model such a pair as two separate nodes, one being config=true and the other config=false, but then the data model would (i) get clumsy, and (ii) fail to communicate the important fact that the two nodes are closely related.

Lada

>
>
>
>> Lada
>
> Andy
>
>>
>>>
>>> Regards, Benoit
>>>
>>>> + 1
>>>>
>>>> Regards, Benoit.
>>>>> We had agreed in our last f2f meeting that people would submit
>>>>> individual I-Ds, and based on that we would potentially
>>>>> consider work in this space. So by all means do submit
>>>>> such individual drafts and discuss them on the mailing list.
>>>>>
>>>>> But we do not have a good problem statement or starting I-D
>>>>> to base this work on, so cannot put it on the current charter.
>>>>>
>>>>> Bert Wijnen
>>>>>
>>>>> On 8/17/12 11:04 AM, Ladislav Lhotka wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I had the impression that there was a reasonable agreement that work on operational state data is needed. Although this problem lies somewhere between NETCONF and NETMOD, I think the NETCONF WG is now in a better position to start this work because apparently NETMOD WG will have to continue the work on the core data models for some time.
>>>>>>
>>>>>> So I propose the following fourth item for the charter:
>>>>>>
>>>>>> 4. The WG will investigate the relationship and interactions between configurations and
>>>>>>     operational state data, propose their appropriate representation and semantics, and
>>>>>>     devise methods for effective data modeling of both configurations and operational state data.
>>>>>>     It is expected that this work will be carried out in a close sooperation with the NETMOD WG.
>>>>>>
>>>>>> Lada
>>>>>>
>>>>>> "Bert Wijnen (IETF)"  writes:
>>>>>>
>>>>>>> Based on the comments and feedback and the positions
>>>>>>> expressed on the mailing list, it is clear that after all
>>>>>>> we did NOT have consensus on the new WG charter.
>>>>>>>
>>>>>>> Without further ado, this is another proposed WG charter.
>>>>>>> It focuses on the things that we do seme to have agreement on.
>>>>>>>
>>>>>>> Pls comment and/or express your support or objections
>>>>>>> no later than August 31, 2012.
>>>>>>>
>>>>>>> OK, new chapter text (omitting the description of what we have
>>>>>>> achieved sofar):
>>>>>>>
>>>>>>>     In the current phase of the incremental development of NETCONF the
>>>>>>>     workgroup will focus on following items:
>>>>>>>
>>>>>>>     1. Advance NETCONF over TLS to be in-line with NETCONF 1:1.
>>>>>>>        This means that RFC5593 needs to be updated.
>>>>>>>
>>>>>>>     2. Based on the implementation, deployment experience and interoperability
>>>>>>>        testing, the WG will document the status of NETCONF in a report.
>>>>>>>        Based on this, the WG may decide to make some clarifications to
>>>>>>>        RFC6241 and RFC6242 (then also fixing any reported errata).
>>>>>>>
>>>>>>>     3. Since Netconf over BEEP and over SOAP seem not being deployed
>>>>>>>        the WG will write a document that makes those 2 protocols
>>>>>>>        (RFC4743 and RFC4744) HISTORIC.
>>>>>>>
>>>>>>> Goals and Milestones:
>>>>>>>     done     - Send with-defaults to IESG for consideration as Proposed Standard
>>>>>>>     done     - WG Last Call on rfc4741bis
>>>>>>>     done     - rfc4741bis to IESG for consideration as Proposed Standard
>>>>>>>     done     - Send rfc4742bis to IESG for consideration as proposed Standard.
>>>>>>>     done     - first WG draft (rev 00) on NACM posted
>>>>>>>     done     - first WG draft (rev 00) on NETCONF specific YANG modules posted
>>>>>>>     done     - WGLC for NACM document
>>>>>>>     done     - WGLC for NETCONF specific notifications document
>>>>>>>     done     - submit NACM document to IESG for consideration as Proposed Standard
>>>>>>>     done     - submit NETCONF specific notifications  document to IESG for
>>>>>>>                consideration as Proposed Standard
>>>>>>>     Aug 2012 - submit initial WG draft for rfc5539bis
>>>>>>>     Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 historic.
>>>>>>>     Sep 2012 - WGLC for rfc5539bis
>>>>>>>     Sep 2012 - WGLC for RFC4743 and 4743 to historic
>>>>>>>     Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard
>>>>>>>     Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic
>>>>>>>     Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242
>>>>>>>     Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience
>>>>>>>     Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience
>>>>>>>     Feb 2013 - submit RFC6241/6242 implementation/deployment experience doc
>>>>>>>                to IESG for publication as Informational RFC.
>>>>>>>     Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or close WG
>>>>>>>
>>>>>>> Bert and Mehmet
>>>>>>> _______________________________________________
>>>>>>> Netconf mailing list
>>>>>>> Netconf@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>>>>
>>>>> _______________________________________________
>>>>> Netconf mailing list
>>>>> Netconf@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Netconf mailing list
>>>> Netconf@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>

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

From bclaise@cisco.com  Thu Sep  6 04:50:34 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446BC21F8594 for ; Thu,  6 Sep 2012 04:50:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.64
X-Spam-Level: 
X-Spam-Status: No, score=-8.64 tagged_above=-999 required=5 tests=[AWL=1.959,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBpF5Zb5iwOa for ; Thu,  6 Sep 2012 04:50:33 -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 4546921F8581 for ; Thu,  6 Sep 2012 04:50:32 -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 q86BoUkV008730; Thu, 6 Sep 2012 13:50:30 +0200 (CEST)
Received: from [10.60.67.92] (ams-bclaise-89111.cisco.com [10.60.67.92]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q86BoTn0027013; Thu, 6 Sep 2012 13:50:29 +0200 (CEST)
Message-ID: <50488E05.7020503@cisco.com>
Date: Thu, 06 Sep 2012 13:50:29 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: "Bert Wijnen (IETF)" 
References: <504612E6.5080104@bwijnen.net>
In-Reply-To: <504612E6.5080104@bwijnen.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: netconf 
Subject: Re: [Netconf] Requesting AD/IESG approval: new/revised NETCONF WG charter
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Sep 2012 11:50:34 -0000

Hi Bert, Mehmet,

Thanks for your effortssss on getting some consensus on this charter. I 
will now progress it

One note regarding this item:
   2. Based on the implementation, deployment experience and 
interoperability
      testing, the WG will document the status of NETCONF in a report.
      Based on this, the WG may decide to make some clarifications to
      RFC6241 and RFC6242 (then also fixing any reported errata).

We should evaluate if the clarifications to RFC6241 and RFC6242 impact 
RFC 6244. In other words, if RFC6244 is still correct. What I have in 
mind is section 4.3 and 4.4 related to configuration data, operational 
data, and statistical data. To be discussed in the WG.

At this point, I believe the item 2 text is sufficient.

Regards, Benoit.
> Benoit, hope you had a good vacation.
>
> Below is the new WG charter that we have WG consensus
> on. Pls get it approved by IESG.
>
> We go from the assumption that IESG will approve and
> we will start moving the documents as per the WG charter.
> Hope that is OK.
>
> Bert and Mehmet
> Network Configuration (netconf)
> -------------------------------
>
>  Charter
>
>  Current Status: Active
>
>  Chairs:
>      Bert Wijnen 
>      Mehmet Ersue 
>
>  Operations and Management Area Directors:
>      Ronald Bonica 
>      Benoit Claise 
>
>  Operations and Management Area Advisor:
>      Benoit Claise 
>
>  Mailing Lists:
>      General Discussion: netconf@ietf.org
>      To Subscribe:       netconf-request@ietf.org
>         or: https://www.ietf.org/mailman/listinfo/netconf
>      Archive: http://www.ietf.org/mail-archive/web/netconf/
>
> Description of Working Group:
>
>   Configuration of networks of devices has become a critical requirement
>   for operators in today's highly interoperable networks. Operators from
>   large to small have developed their own mechanisms or used vendor
>   specific mechanisms to transfer configuration data to and from a
>   device, and for examining device state information which may impact
>   the configuration. Each of these mechanisms may be different in
>   various aspects, such as session establishment, user authentication,
>   configuration data exchange, and error responses.
>
>   The NETCONF Working Group has produced a protocol suitable for
>   network configuration, with the following characteristics:
>
>   - Provides retrieval mechanisms which can differentiate between
>     configuration data and non-configuration data
>   - Is extensible enough so that vendors can provide access to all
>     configuration data on the device using a single protocol
>   - Has a programmatic interface (avoids screen scraping and
>     formatting-related changes between releases)
>   - Uses an XML-based data representation, that can be easily manipulated
>     using non-specialized XML manipulation tools.
>   - Supports integration with existing user authentication methods
>   - Supports integration with existing configuration database systems
>   - Supports multiple (e.g. candidate and running) data-stores to
>     optimize configuration preparation and activation
>   - Supports network wide configuration transactions (with features such
>     as locking and rollback capability)
>   - Runs over a secure transport; SSH is mandatory to implement while 
> TLS,
>     BEEP, and SOAP are optional transports.
>   - Provides support for asynchronous notifications.
>   - Supports an Access Control Model and a YANG module for configuring
>     the Access Control parameters.
>   - Supports a YANG module for System Notifications
>
>   The NETCONF protocol has been designed independent of the data modeling
>   language.  The IETF recommends to use YANG as the NETCONF modeling
>   language, which introduces advanced language features for configuration
>   management.
>
>   In the current phase of the incremental development of NETCONF the
>   workgroup will focus on following items:
>
>   1. Advance NETCONF over TLS to be in-line with NETCONF 1:1.
>      This means that RFC5593 needs to be updated.
>
>   2. Based on the implementation, deployment experience and 
> interoperability
>      testing, the WG will document the status of NETCONF in a report.
>      Based on this, the WG may decide to make some clarifications to
>      RFC6241 and RFC6242 (then also fixing any reported errata).
>
>   3. Since Netconf over BEEP and over SOAP seem not being deployed
>      the WG will write a document that makes those 2 protocols
>      (RFC4743 and RFC4744) HISTORIC.
>
> Goals and Milestones:
>   done     - Send with-defaults to IESG for consideration as Proposed 
> Standard
>   done     - WG Last Call on rfc4741bis
>   done     - rfc4741bis to IESG for consideration as Proposed Standard
>   done     - Send rfc4742bis to IESG for consideration as proposed 
> Standard.
>   done     - first WG draft (rev 00) on NACM posted
>   done     - first WG draft (rev 00) on NETCONF specific YANG modules 
> posted
>   done     - WGLC for NACM document
>   done     - WGLC for NETCONF specific notifications document
>   done     - submit NACM document to IESG for consideration as 
> Proposed Standard
>   done     - submit NETCONF specific notifications  document to IESG for
>              consideration as Proposed Standard
>   Sep 2012 - submit initial WG draft for rfc5539bis
>   Sep 2012 - submit initial WG draft for making RFC4743 and RFC4744 
> historic.
>   Sep 2012 - WGLC for rfc5539bis
>   Sep 2012 - WGLC for RFC4743 and 4743 to historic
>   Okt 2012 - submit rfc5539bis to AD/IESG for consideration as 
> Proposed Standard
>   Okt 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic
>   Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and 
> 6242
>   Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment 
> experience
>   Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience
>   Feb 2013 - possibly submit RFC6241/6242 implementation/deployment 
> experience doc
>              to IESG for publication as Informational RFC.
>   Mar 2013 - Evaluate if more work needs to be done by NETCONF WG
>
>


From bertietf@bwijnen.net  Thu Sep  6 04:54:33 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D916221F8587 for ; Thu,  6 Sep 2012 04:54:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level: 
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaaU-f-dlYn6 for ; Thu,  6 Sep 2012 04:54:32 -0700 (PDT)
Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 95D9121F847C for ; Thu,  6 Sep 2012 04:54:32 -0700 (PDT)
Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T9afF-0004uK-HE; Thu, 06 Sep 2012 13:54:31 +0200
Received: from dog.ripe.net ([193.0.1.217] helo=guest4.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1T9afF-0000Vc-CH; Thu, 06 Sep 2012 13:54:29 +0200
Message-ID: <50488EF5.9080102@bwijnen.net>
Date: Thu, 06 Sep 2012 13:54:29 +0200
From: "Bert Wijnen (IETF)" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: Benoit Claise 
References: <504612E6.5080104@bwijnen.net> <50488E05.7020503@cisco.com>
In-Reply-To: <50488E05.7020503@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120906 clean
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points:   -2.9 points pts rule name              description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4398333b4e2c32af018410fbf36681e2c
Cc: netconf 
Subject: Re: [Netconf] Requesting AD/IESG approval: new/revised NETCONF WG charter
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Sep 2012 11:54:34 -0000

ack

Bert

On 9/6/12 1:50 PM, Benoit Claise wrote:
> Hi Bert, Mehmet,
>
> Thanks for your effortssss on getting some consensus on this charter. I will now progress it
>
> One note regarding this item:
>    2. Based on the implementation, deployment experience and interoperability
>       testing, the WG will document the status of NETCONF in a report.
>       Based on this, the WG may decide to make some clarifications to
>       RFC6241 and RFC6242 (then also fixing any reported errata).
>
> We should evaluate if the clarifications to RFC6241 and RFC6242 impact RFC 6244. In other words, if RFC6244 is still correct. What I
> have in mind is section 4.3 and 4.4 related to configuration data, operational data, and statistical data. To be discussed in the WG.
>
> At this point, I believe the item 2 text is sufficient.
>
> Regards, Benoit.
>> Benoit, hope you had a good vacation.
>>
>> Below is the new WG charter that we have WG consensus
>> on. Pls get it approved by IESG.
>>
>> We go from the assumption that IESG will approve and
>> we will start moving the documents as per the WG charter.
>> Hope that is OK.
>>
>> Bert and Mehmet
>> Network Configuration (netconf)
>> -------------------------------
>>
>>  Charter
>>
>>  Current Status: Active
>>
>>  Chairs:
>>      Bert Wijnen 
>>      Mehmet Ersue 
>>
>>  Operations and Management Area Directors:
>>      Ronald Bonica 
>>      Benoit Claise 
>>
>>  Operations and Management Area Advisor:
>>      Benoit Claise 
>>
>>  Mailing Lists:
>>      General Discussion: netconf@ietf.org
>>      To Subscribe:       netconf-request@ietf.org
>>         or: https://www.ietf.org/mailman/listinfo/netconf
>>      Archive: http://www.ietf.org/mail-archive/web/netconf/
>>
>> Description of Working Group:
>>
>>   Configuration of networks of devices has become a critical requirement
>>   for operators in today's highly interoperable networks. Operators from
>>   large to small have developed their own mechanisms or used vendor
>>   specific mechanisms to transfer configuration data to and from a
>>   device, and for examining device state information which may impact
>>   the configuration. Each of these mechanisms may be different in
>>   various aspects, such as session establishment, user authentication,
>>   configuration data exchange, and error responses.
>>
>>   The NETCONF Working Group has produced a protocol suitable for
>>   network configuration, with the following characteristics:
>>
>>   - Provides retrieval mechanisms which can differentiate between
>>     configuration data and non-configuration data
>>   - Is extensible enough so that vendors can provide access to all
>>     configuration data on the device using a single protocol
>>   - Has a programmatic interface (avoids screen scraping and
>>     formatting-related changes between releases)
>>   - Uses an XML-based data representation, that can be easily manipulated
>>     using non-specialized XML manipulation tools.
>>   - Supports integration with existing user authentication methods
>>   - Supports integration with existing configuration database systems
>>   - Supports multiple (e.g. candidate and running) data-stores to
>>     optimize configuration preparation and activation
>>   - Supports network wide configuration transactions (with features such
>>     as locking and rollback capability)
>>   - Runs over a secure transport; SSH is mandatory to implement while TLS,
>>     BEEP, and SOAP are optional transports.
>>   - Provides support for asynchronous notifications.
>>   - Supports an Access Control Model and a YANG module for configuring
>>     the Access Control parameters.
>>   - Supports a YANG module for System Notifications
>>
>>   The NETCONF protocol has been designed independent of the data modeling
>>   language.  The IETF recommends to use YANG as the NETCONF modeling
>>   language, which introduces advanced language features for configuration
>>   management.
>>
>>   In the current phase of the incremental development of NETCONF the
>>   workgroup will focus on following items:
>>
>>   1. Advance NETCONF over TLS to be in-line with NETCONF 1:1.
>>      This means that RFC5593 needs to be updated.
>>
>>   2. Based on the implementation, deployment experience and interoperability
>>      testing, the WG will document the status of NETCONF in a report.
>>      Based on this, the WG may decide to make some clarifications to
>>      RFC6241 and RFC6242 (then also fixing any reported errata).
>>
>>   3. Since Netconf over BEEP and over SOAP seem not being deployed
>>      the WG will write a document that makes those 2 protocols
>>      (RFC4743 and RFC4744) HISTORIC.
>>
>> Goals and Milestones:
>>   done     - Send with-defaults to IESG for consideration as Proposed Standard
>>   done     - WG Last Call on rfc4741bis
>>   done     - rfc4741bis to IESG for consideration as Proposed Standard
>>   done     - Send rfc4742bis to IESG for consideration as proposed Standard.
>>   done     - first WG draft (rev 00) on NACM posted
>>   done     - first WG draft (rev 00) on NETCONF specific YANG modules posted
>>   done     - WGLC for NACM document
>>   done     - WGLC for NETCONF specific notifications document
>>   done     - submit NACM document to IESG for consideration as Proposed Standard
>>   done     - submit NETCONF specific notifications  document to IESG for
>>              consideration as Proposed Standard
>>   Sep 2012 - submit initial WG draft for rfc5539bis
>>   Sep 2012 - submit initial WG draft for making RFC4743 and RFC4744 historic.
>>   Sep 2012 - WGLC for rfc5539bis
>>   Sep 2012 - WGLC for RFC4743 and 4743 to historic
>>   Okt 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard
>>   Okt 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic
>>   Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242
>>   Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience
>>   Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience
>>   Feb 2013 - possibly submit RFC6241/6242 implementation/deployment experience doc
>>              to IESG for publication as Informational RFC.
>>   Mar 2013 - Evaluate if more work needs to be done by NETCONF WG
>>
>>
>
>

From internet-drafts@ietf.org  Fri Sep  7 00:51:32 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B402D21F8738; Fri,  7 Sep 2012 00:51:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.412
X-Spam-Level: 
X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4x4cb+kcMCVu; Fri,  7 Sep 2012 00:51:32 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3524F21F8720; Fri,  7 Sep 2012 00:51:32 -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.34
Message-ID: <20120907075132.24495.71807.idtracker@ietfa.amsl.com>
Date: Fri, 07 Sep 2012 00:51:32 -0700
Cc: netconf@ietf.org
Subject: [Netconf] I-D Action: draft-ietf-netconf-rfc4743-rfc4744-to-historic-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Sep 2012 07:51:33 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Network Configuration Working Group of th=
e IETF.

	Title           : RFC4743 and RFC4744 to Historic status
	Author(s)       : Bert Wijnen
	Filename        : draft-ietf-netconf-rfc4743-rfc4744-to-historic-00.txt
	Pages           : 4
	Date            : 2012-09-07

Abstract:
   This document moves RFC4743 (Using NETCONF over the Simple Object
   Access Protocol (SOAP)) and RFC4744 (Using the NETCONF Protocol over
   the Blocks Extensible Exchange Protocol (BEEP)) to HISTORIC status to
   reflect the fact that those two documents have shown very little (if
   any) implementations and deployment.  Furthermore, no-one in the
   NETCONF WG is interested or volunteering to work on them anymore.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc4743-rfc4744-to-hist=
oric

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netconf-rfc4743-rfc4744-to-historic-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From mehmet.ersue@nsn.com  Fri Sep  7 04:13:22 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D2321F8712 for ; Fri,  7 Sep 2012 04:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RX+Z-bf7T7Ey for ; Fri,  7 Sep 2012 04:13:21 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 53C0621F8751 for ; Fri,  7 Sep 2012 04:13:21 -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 q87BDHXF015366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 7 Sep 2012 13:13:17 +0200
Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q87BDDS8019382 for ; Fri, 7 Sep 2012 13:13:17 +0200
Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 7 Sep 2012 13:13:14 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Fri, 7 Sep 2012 13:13:11 +0200
Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64042F9E9B@DEMUEXC006.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Help the NomCom: Nominations and Feedback
Thread-Index: Ac2M6cR20w0FsmoeRx2b93VORgR14g==
From: "Ersue, Mehmet (NSN - DE/Munich)" 
To: "netconf" 
X-OriginalArrivalTime: 07 Sep 2012 11:13:14.0048 (UTC) FILETIME=[C5FB9400:01CD8CE9]
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: 2970
X-purgate-ID: 151667::1347016397-00006F5F-47B5E8F3/0-0/0-0
Subject: [Netconf] FW: Help the NomCom: Nominations and Feedback
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Sep 2012 11:13:22 -0000

UGxlYXNlIGhlbHAgTm9tQ29tIHdpdGggeW91ciBub21pbmF0aW9ucyBhbmQgY29tbWVudHMuDQoN
CkNoZWVycywgDQpNZWhtZXQgDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206
IHdnY2hhaXJzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp3Z2NoYWlycy1ib3VuY2VzQGlldGYu
b3JnXSBPbiBCZWhhbGYgT2YgTm9tQ29tIENoYWlyDQpTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVy
IDA2LCAyMDEyIDI6MjEgQU0NClRvOiBXb3JraW5nIEdyb3VwIENoYWlycw0KU3ViamVjdDogSGVs
cCB0aGUgTm9tQ29tOiBOb21pbmF0aW9ucyBhbmQgRmVlZGJhY2sNCg0KVGhlIElFVEYgTm9taW5h
dGlvbnMgQ29tbWl0dGVlIChOb21Db20pIGlzIGN1cnJlbnRseSBzZWVraW5nIA0Kbm9taW5hdGlv
bnMgZm9yIGluZGl2aWR1YWxzIHRvIHNlcnZlIG9uIHRoZSBJRVNHLCBJQUIsIGFuZCBJQU9DLiAN
CkFkZGl0aW9uYWxseSwgdGhpcyBpcyBhbiBhbm5vdW5jZW1lbnQgdGhhdCB0aGUgTm9tQ29tIGlz
IHNlZWtpbmcgDQpmZWVkYmFjayBvbiBpbmRpdmlkdWFscyB3aG8gaGF2ZSBhY2NlcHRlZCBub21p
bmF0aW9ucyBmb3IgSUVURiANCmxlYWRlcnNoaXAgcG9zaXRpb25zLiANCg0KSXQgaXMgdmVyeSBp
bXBvcnRhbnQgdG8gdGhlIE5vbUNvbSBwcm9jZXNzIHRoYXQgd2UgZ2V0IGlucHV0IGZyb20gYSAN
CmJyb2FkIHNwZWN0cnVtIG9mIHRoZSBjb21tdW5pdHkuIFRoZXJlZm9yZSwgaW4gY2FzZSBtZW1i
ZXJzIG9mIHlvdXIgDQp3b3JraW5nIGdyb3VwIGRvIG5vdCByZWFkIHRoZSBJRVRGIGFubm91bmNl
bWVudCBhbmQgZGlzY3Vzc2lvbiBsaXN0cywgDQp0aGUgTm9tQ29tIHdvdWxkIGFwcHJlY2lhdGUg
eW91ciBoZWxwIGluIGRpc3NlbWluYXRpbmcgdGhlIGZvbGxvd2luZyANCmluZm9ybWF0aW9uLg0K
DQpUaGUgTm9tQ29tIHdlYnNpdGUgY29udGFpbnMgaW5mb3JtYXRpb24gYWJvdXQgdGhpcyB5ZWFy
J3MgTm9tQ29tIA0KaW5jbHVkaW5nIHRoZSBwb3NpdGlvbnMgd2UgYXJlIHNlZWtpbmcgdG8gZmls
bCwgYW5kIHRoZSBxdWFsaWZpY2F0aW9ucyANCnJlcXVpcmVkIGZvciB0aGVzZSBwb3NpdGlvbnM6
DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2dyb3VwL25vbWNvbS8yMDEyLw0KDQpUaGUgTm9tQ29t
IGlzIGFjY2VwdGluZyBub21pbmF0aW9ucyB1bnRpbCBTZXB0ZW1iZXIgMjQuIE5vbWluYXRpb25z
IA0KZm9yIGFueSBwb3NpdGlvbiBjYW4gYmUgbWFkZSB1c2luZyB0aGUgZm9sbG93aW5nIHdlYiB0
b29sOg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9ncm91cC9ub21jb20vMjAxMi9ub21pbmF0ZQ0K
DQpGZWVkYmFjayBhYm91dCBpbmRpdmlkdWFscyB3aG8gdGhlIE5vbUNvbSBpcyBjb25zaWRlcmlu
ZyBjYW4gYmUgDQpwcm92aWRpbmcgdXNpbmcgdGhlIGZvbGxvd2luZyB3ZWIgdG9vbDoNCg0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvZ3JvdXAvbm9tY29tLzIwMTIvaW5wdXQNCg0KVGhlIGZlZWRiYWNr
IHRvb2wgcHJvdmlkZXMgYSBsaXN0IG9mIGluZGl2aWR1YWxzIHdobyBoYXZlIGFncmVlZCB0byBi
ZSANCmNvbnNpZGVyZWQgZm9yIGVhY2ggcG9zaXRpb24uIFdlIHdpbGwgYmUgdXBkYXRpbmcgdGhp
cyBsaXN0IGluIHRoZSBjb21pbmcgDQp3ZWVrcyBhcyBtb3JlIGluZGl2aWR1YWxzIGFjY2VwdCBu
b21pbmF0aW9ucy4NCg0KRmVlZGJhY2sgcHJvdmlkZWQgdG8gdGhlIE5vbUNvbSBpcyBrZXB0IHN0
cmljdGx5IGNvbmZpZGVudGlhbCENCg0KTm90ZSB0aGF0IHVzZSBvZiB0aGUgTm9tQ29tIHdlYiB0
b29scyByZXF1aXJlIGFuIGlldGYub3JnIChpLmUuLA0KZGF0YXRyYWNrZXIpIGFjY291bnQuIFlv
dSBjYW4gY3JlYXRlIGFuIGlldGYub3JnIGFjY291bnQgYnkgdmlzaXRpbmcgdGhlDQpmb2xsb3dp
bmcgVVJMOg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2FjY291bnRzL2NyZWF0ZS8N
Cg0KQXMgYW4gYWx0ZXJuYXRpdmUgdG8gdXNpbmcgdGhlIHdlYiB0b29scywgIHlvdSBjYW4gc2Vu
ZCBlbWFpbCB0byB0aGUNCk5vbUNvbSBhdCBub21jb20xMkBpZXRmLm9yZyB0byBtYWtlIGEgbm9t
aW5hdGlvbiBvciBwcm92aWRlIGlucHV0IHRvDQp0aGUgY29tbWl0dGVlLg0KDQpUaGFuayB5b3Ug
Zm9yIHlvdXIgaGVscCwNCi0gTWF0dCBMZXBpbnNraQ0KICBub21jb20tY2hhaXJAaWV0Zi5vcmcN
Cg==

From mehmet.ersue@nsn.com  Fri Sep  7 04:15:25 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC18C21F8751 for ; Fri,  7 Sep 2012 04:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RI62QOKr82Rt for ; Fri,  7 Sep 2012 04:15:25 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id D705721F8712 for ; Fri,  7 Sep 2012 04:15:24 -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 q87BFNbd019594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 7 Sep 2012 13:15:23 +0200
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q87BFKsd029400 for ; Fri, 7 Sep 2012 13:15:23 +0200
Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 7 Sep 2012 13:15:10 +0200
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: Fri, 7 Sep 2012 13:15:09 +0200
Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64042F9E9E@DEMUEXC006.nsn-intra.net>
In-Reply-To: <20120907075132.24495.71807.idtracker@ietfa.amsl.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Netconf] I-D Action:draft-ietf-netconf-rfc4743-rfc4744-to-historic-00.txt
Thread-Index: Ac2Mza/rAA7GjshkS7edKGyh2w9pEgAGrXZg
References: <20120907075132.24495.71807.idtracker@ietfa.amsl.com>
From: "Ersue, Mehmet (NSN - DE/Munich)" 
To: 
X-OriginalArrivalTime: 07 Sep 2012 11:15:10.0501 (UTC) FILETIME=[0B64E550:01CD8CEA]
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: 2145
X-purgate-ID: 151667::1347016523-00006F5F-7714516F/0-0/0-0
Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-rfc4743-rfc4744-to-historic-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Sep 2012 11:15:25 -0000

Hi All,

as discussed Bert submitted
draft-ietf-netconf-rfc4743-rfc4744-to-historic (see below) addressing
item 3 (Netconf over BEEP and over SOAP to historic) in the approved
charter.

If anybody has immediate comments please bring it into discussion soon.
If there are no substantial objections by September 14, 2012 EOB PT we
are going to issue a WG LC.

Mehmet=20


> -----Original Message-----
> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On
Behalf Of ext
> internet-drafts@ietf.org
> Sent: Friday, September 07, 2012 9:52 AM
> To: i-d-announce@ietf.org
> Cc: netconf@ietf.org
> Subject: [Netconf] I-D
Action:draft-ietf-netconf-rfc4743-rfc4744-to-historic-00.txt
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>  This draft is a work item of the Network Configuration Working Group
of the IETF.
>=20
> 	Title           : RFC4743 and RFC4744 to Historic status
> 	Author(s)       : Bert Wijnen
> 	Filename        :
draft-ietf-netconf-rfc4743-rfc4744-to-historic-00.txt
> 	Pages           : 4
> 	Date            : 2012-09-07
>=20
> Abstract:
>    This document moves RFC4743 (Using NETCONF over the Simple Object
>    Access Protocol (SOAP)) and RFC4744 (Using the NETCONF Protocol
over
>    the Blocks Extensible Exchange Protocol (BEEP)) to HISTORIC status
to
>    reflect the fact that those two documents have shown very little
(if
>    any) implementations and deployment.  Furthermore, no-one in the
>    NETCONF WG is interested or volunteering to work on them anymore.
>=20
>=20
> The IETF datatracker status page for this draft is:
>
https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc4743-rfc4744-to-h
istoric
>=20
> There's also a htmlized version available at:
>
http://tools.ietf.org/html/draft-ietf-netconf-rfc4743-rfc4744-to-histori
c-00
>=20
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

From mbadra@gmail.com  Sat Sep  8 17:16:54 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43C121F84D7 for ; Sat,  8 Sep 2012 17:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Level: 
X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9iZdSFHmj2F for ; Sat,  8 Sep 2012 17:16:54 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB1A621F84D3 for ; Sat,  8 Sep 2012 17:16:53 -0700 (PDT)
Received: by lahm15 with SMTP id m15so456585lah.31 for ; Sat, 08 Sep 2012 17:16:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E1IxyG+birM3GolH9Y2X9LsS+bYFlAua4OjeCUCC1Zo=; b=YHO+asBH6LijuWVmmkCe0+Hc5fYgGH8IUnyRXOZv2KLAU7SVhBQjC+hhyvrnpeJq68 kVXR7RQnR07Glex/77Nq533imLXtcXHB58DX5sjqidY3sn9UdZ7JB7wilc3i0gl6wpli XO7//pWKXohmPQ5pYa9/jxK/2vaFfh3ihz+T0w2HRUnnjw1hYtORBBmO4+TdYfWds4v2 SD1ahNyFLiQznB6wHKX0OR5T2nKRNxGIu9tYTTpwa2Rvw0VyukGf/9kGBGOeowpeIFxb 47bSO4aKAwumwlDjyhSQ+Z56EUjS8IyUq074Xo2JQSECZv7pHzJA7gVlEbMO5iNL19bo 8M6A==
MIME-Version: 1.0
Received: by 10.112.8.100 with SMTP id q4mr3533289lba.86.1347149812499; Sat, 08 Sep 2012 17:16:52 -0700 (PDT)
Received: by 10.114.11.196 with HTTP; Sat, 8 Sep 2012 17:16:52 -0700 (PDT)
In-Reply-To: <01ef01cd7092$02c4cb00$4001a8c0@gateway.2wire.net>
References:  <01ef01cd7092$02c4cb00$4001a8c0@gateway.2wire.net>
Date: Sun, 9 Sep 2012 02:16:52 +0200
Message-ID: 
From: Mohamad Badra 
To: "t.petch" 
Content-Type: multipart/alternative; boundary=90e6ba308fd208869404c939c2cb
Cc: netconf@ietf.org
Subject: Re: [Netconf] Netconf over TLS (rfc5539bis)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 09 Sep 2012 00:16:55 -0000

--90e6ba308fd208869404c939c2cb
Content-Type: text/plain; charset=ISO-8859-1

Dear Tom,

Do you mean the following paragraph?

           Maps a subjectAltName's rfc822Name to a NETCONF username.
           The local part of the rfc822Name is passed unaltered but
           the host-part of the name MUST be passed in lowercase.
           This mapping results in a 1:1 correspondence between
           equivalent subjectAltName rfc822Name values and NETCONF
           username values except that the host-part of the name
           MUST be passed in lowercase.

           Example rfc822Name Field:  FooBar@Example.COM
           is mapped to NETCONF username: FooBar@example.com.


And do you mean to change it to be

           Maps a subjectAltName's rfc822Name to a NETCONF username.
           The local part of the rfc822Name is passed unaltered but
           the domain-part of the name MUST be passed in lowercase.
               ^^^^^^^

           This mapping results in a 1:1 correspondence between
           equivalent subjectAltName rfc822Name values and NETCONF
           username values except that the domain-part of the name

                                           ^^^^^^
           MUST be passed in lowercase.

           Example rfc822Name Field:  FooBar@Example.COM
           is mapped to NETCONF username: FooBar@example.com.


Thank you
Best regards
Badra

On Thu, Aug 2, 2012 at 11:34 AM, t.petch  wrote:

> Badra
>
> Your description of RFC822 names makes reference to a host part.
>
> This is incorrect - it should be a domain part, as per RFC822.
>
> Tom Petch
>
>
> ----- Original Message -----
> From: "Mohamad Badra" 
> To: 
> Sent: Saturday, April 28, 2012 1:43 PM
>
> > Dear All,
> >
> > I just posted a revised version of the
> > document draft-badra-netconf-rfc5539bis
> >
> > http://www.ietf.org/id/draft-badra-netconf-rfc5539bis-02.txt
> >
> > Your comments are highly appreciated.
> >
> > Best regards,
> > Badra
> >
>
>
> ------------------------------------------------------------------------
> --------
>
>
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> >
>
>
>

--90e6ba308fd208869404c939c2cb
Content-Type: text/html; charset=ISO-8859-1

Dear Tom,

Do you mean the following paragraph?

           Maps a subjectAltName's rfc822Name to a NETCONF username.
           The local part of the rfc822Name is passed unaltered but
           the host-part of the name MUST be passed in lowercase.
           This mapping results in a 1:1 correspondence between
           equivalent subjectAltName rfc822Name values and NETCONF
           username values except that the host-part of the name
           MUST be passed in lowercase.

           Example rfc822Name Field:  FooBar@Example.COM
           is mapped to NETCONF username: FooBar@example.com.

And do you mean to change it to be

           Maps a subjectAltName's rfc822Name to a NETCONF username.
           The local part of the rfc822Name is passed unaltered but
           the domain-part of the name MUST be passed in lowercase.
               ^^^^^^^
           This mapping results in a 1:1 correspondence between
           equivalent subjectAltName rfc822Name values and NETCONF
           username values except that the domain-part of the name
                                           ^^^^^^
           MUST be passed in lowercase.

           Example rfc822Name Field:  FooBar@Example.COM
           is mapped to NETCONF username: FooBar@example.com.

Thank you
Best regards

Badra

On Thu, Aug 2, 2012 at 11:34 AM, t.petch <ietfc@btconnect.com> wrote:


Badra



Your description of RFC822 names makes reference to a host part.



This is incorrect - it should be a domain part, as per RFC822.



Tom Petch






----- Original Message -----

From: "Mohamad Badra" <mbadra@gmail.com>

To: <netconf@ietf.org>

Sent: Saturday, April 28, 2012 1:43 PM



> Dear All,

>

> I just posted a revised version of the

> document draft-badra-netconf-rfc5539bis

>

> http://www.ietf.org/id/draft-badra-netconf-rfc5539bis-02.txt

>

> Your comments are highly appreciated.

>

> Best regards,

> Badra

>






------------------------------------------------------------------------

--------





> _______________________________________________

> Netconf mailing list

> Netconf@ietf.org

> https://www.ietf.org/mailman/listinfo/netconf

>









--90e6ba308fd208869404c939c2cb--

From andy@yumaworks.com  Sat Sep  8 19:57:19 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AEE21F84DC for ; Sat,  8 Sep 2012 19:57:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.477
X-Spam-Level: 
X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.500,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-5szTCh3pgv for ; Sat,  8 Sep 2012 19:57:18 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 46F6321F84C2 for ; Sat,  8 Sep 2012 19:57:18 -0700 (PDT)
Received: by qcac10 with SMTP id c10so562858qca.31 for ; Sat, 08 Sep 2012 19:57:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=LWe1R1gDMf54PBM7I7BjAQvV5frXo3t7XH/+ar0mIJ4=; b=C7xudjCiJFIPpJMn6iTiL6IeRW8qGUmRz464guU0mlRno4hx67TBnzhpgqq4DTanMb JOUrspfsEXaZLjmA/rtVbGOCPaFI1w0VJ6X+mJ29dBqa4MZtv9clHJblNfs3cbyStEvJ VKSyRcrSB0wIhRfBgfqRt5InI6zkNHaCGbPRdXoMs0FKxo3UeVVnXlNfOLFs5dmEl6e4 5OdrWceLjqeuheS0fWHelUqmp+8xnNR3ez7GIl3LbgDC4B2+7aPC53/3dvPmzaJLm5Bj xqWpzXFomFMIOnXvigK0V6RcwKfaKqXLSJrIe9ZoMR30ccLeY8UalyYxMJMX74icy3sY tOcg==
MIME-Version: 1.0
Received: by 10.224.191.130 with SMTP id dm2mr3702695qab.98.1347159437564; Sat, 08 Sep 2012 19:57:17 -0700 (PDT)
Received: by 10.49.35.230 with HTTP; Sat, 8 Sep 2012 19:57:17 -0700 (PDT)
In-Reply-To: <20120909025307.5206.71632.idtracker@ietfa.amsl.com>
References: <20120909025307.5206.71632.idtracker@ietfa.amsl.com>
Date: Sat, 8 Sep 2012 19:57:17 -0700
Message-ID: 
From: Andy Bierman 
To: Netconf 
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQmSQba7oDCBc2trWbB9JfEWP0XZx/QyRWw+unV6c9Q6iGKeGPye+WYAjF6jb+t7akMxqqZB
Subject: [Netconf] Fwd: I-D Action: draft-bierman-netconf-get2-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 09 Sep 2012 02:57:19 -0000

FYI,

I wrote this draft to address NETCONF data retrieval deficiencies.
It is related to operational data, but not limited in scope to
operational data.



Andy



---------- Forwarded message ----------
From:  
Date: Sat, Sep 8, 2012 at 7:53 PM
Subject: I-D Action: draft-bierman-netconf-get2-00.txt
To: i-d-announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : The NETCONF  Operation
        Author(s)       : Andy Bierman
        Filename        : draft-bierman-netconf-get2-00.txt
        Pages           : 26
        Date            : 2012-09-08

Abstract:
   This document describes NETCONF protocol enhancements to improve data
   retrieval capabilities.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bierman-netconf-get2

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bierman-netconf-get2-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

From bertietf@bwijnen.net  Mon Sep 10 03:02:44 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A46121F852A for ; Mon, 10 Sep 2012 03:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.359
X-Spam-Level: 
X-Spam-Status: No, score=-102.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zDwHxqyM+Pb for ; Mon, 10 Sep 2012 03:02:40 -0700 (PDT)
Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5C821F84E6 for ; Mon, 10 Sep 2012 03:02:40 -0700 (PDT)
Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TB0pB-0003b8-LZ; Mon, 10 Sep 2012 12:02:39 +0200
Received: from dog.ripe.net ([193.0.1.217] helo=guest4.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1TB0pB-00043p-Hw; Mon, 10 Sep 2012 12:02:37 +0200
Message-ID: <504DBABD.70402@bwijnen.net>
Date: Mon, 10 Sep 2012 12:02:37 +0200
From: "Bert Wijnen (IETF)" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: Andy Bierman 
References: <20120909025307.5206.71632.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120910 clean
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points:   -2.9 points pts rule name              description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4f0f223a40d336feebe1cc5bde1cafe3c
Cc: Netconf 
Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-get2-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Sep 2012 10:02:44 -0000

Thanks Andy!
This is constructive.

First I would like to ask people to specifically read the
problem statement sections and post comments on that.
Specifically, do you agree with the problems listed and
that we (WG) need to work on a solution.
Do you see any other problems that are not yet listed
and that must be solved by the WG.

Of course you can discuss Andy's solution paragraphs too.
But for the WG to decide if we want to work on this, we
need to get agreement on the problem statement/problem space.

Bert

On 9/9/12 4:57 AM, Andy Bierman wrote:
> FYI,
>
> I wrote this draft to address NETCONF data retrieval deficiencies.
> It is related to operational data, but not limited in scope to
> operational data.
>
>
>
> Andy
>
>
>
> ---------- Forwarded message ----------
> From:  
> Date: Sat, Sep 8, 2012 at 7:53 PM
> Subject: I-D Action: draft-bierman-netconf-get2-00.txt
> To: i-d-announce@ietf.org
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>          Title           : The NETCONF  Operation
>          Author(s)       : Andy Bierman
>          Filename        : draft-bierman-netconf-get2-00.txt
>          Pages           : 26
>          Date            : 2012-09-08
>
> Abstract:
>     This document describes NETCONF protocol enhancements to improve data
>     retrieval capabilities.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-bierman-netconf-get2
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-bierman-netconf-get2-00
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

From internet-drafts@ietf.org  Thu Sep 13 07:41:58 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF4E21F85A0; Thu, 13 Sep 2012 07:41: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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mMvyu951muA; Thu, 13 Sep 2012 07:41:58 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C2F21F848F; Thu, 13 Sep 2012 07:41:58 -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.34
Message-ID: <20120913144158.920.27613.idtracker@ietfa.amsl.com>
Date: Thu, 13 Sep 2012 07:41:58 -0700
Cc: netconf@ietf.org
Subject: [Netconf] I-D Action: draft-ietf-netconf-rfc5539bis-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Sep 2012 14:41:58 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Network Configuration Working Group of th=
e IETF.

	Title           : NETCONF Over Transport Layer Security (TLS)
	Author(s)       : Mohamad Badra
	Filename        : draft-ietf-netconf-rfc5539bis-00.txt
	Pages           : 19
	Date            : 2012-09-13

Abstract:
   The Network Configuration Protocol (NETCONF) provides mechanisms to
   install, manipulate, and delete the configuration of network devices.
   This document describes how to use the Transport Layer Security (TLS)
   protocol to secure NETCONF exchanges.  This document obsoletes RFC
   5539.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From mbadra@gmail.com  Thu Sep 13 08:05:55 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB55D21F85C6 for ; Thu, 13 Sep 2012 08:05:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level: 
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbQt7ftTfeEY for ; Thu, 13 Sep 2012 08:05:55 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBEE721F853C for ; Thu, 13 Sep 2012 08:05:54 -0700 (PDT)
Received: by lbky2 with SMTP id y2so2192654lbk.31 for ; Thu, 13 Sep 2012 08:05:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Sgl+hzp5iZz+USQRCxQkcO8JO1vJAoO94PuLgAOSFsM=; b=dBXsdo+snQoGz4aVfkFd2TUiHmoHxgIWrGC9X9Bk0CfyCdlzoCI6noCJgfZkfEsR0H N/I1W5yM/xx5/d5YKlyK+4DYsafdcNKoF3PYAOQ4cq2IEJ+TBQveobE0wW5ZSX6tiFcw CbjyX5HFhZAB3YoqGwEuPjkSSDh6S4PD7/6lVv/oE8AsNmPbGxQ5fTEiNj+ZwlNamJk0 WPsak9LxNx9I5XLM7pGCqpUIWH83/Ux06pLqx1KsvYUHH1TZkhdrf31rzThQSRLJhn1V Hx2DhDM40GzDLDA5h3XUWL8QU0h6kIrVhxIHL4l/YaHG0j30rgt+F50+pOfOI6uPesSn T4gQ==
MIME-Version: 1.0
Received: by 10.152.124.76 with SMTP id mg12mr2255122lab.10.1347548753596; Thu, 13 Sep 2012 08:05:53 -0700 (PDT)
Received: by 10.114.11.196 with HTTP; Thu, 13 Sep 2012 08:05:53 -0700 (PDT)
In-Reply-To: <20120913144158.920.10395.idtracker@ietfa.amsl.com>
References: <20120913144158.920.10395.idtracker@ietfa.amsl.com>
Date: Thu, 13 Sep 2012 17:05:53 +0200
Message-ID: 
From: Mohamad Badra 
To: netconf@ietf.org
Content-Type: multipart/alternative; boundary=f46d043bd88ac6906004c996a4cc
Subject: [Netconf] Fwd: New Version Notification for draft-ietf-netconf-rfc5539bis-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Sep 2012 15:05:55 -0000

--f46d043bd88ac6906004c996a4cc
Content-Type: text/plain; charset=ISO-8859-1

Dear all

I have posted a revised version of the document "NETCONF over TLS" with two
minor changes:

1) remove any reference to BEEP
2) replace host-name with domain-name in the rfc228 description

Best regards
Badra

---------- Forwarded message ----------
From: 
Date: Thu, Sep 13, 2012 at 4:41 PM
Subject: New Version Notification for draft-ietf-netconf-rfc5539bis-00.txt
To: mbadra@gmail.com



A new version of I-D, draft-ietf-netconf-rfc5539bis-00.txt
has been successfully submitted by Mohamad Badra and posted to the
IETF repository.

Filename:        draft-ietf-netconf-rfc5539bis
Revision:        00
Title:           NETCONF Over Transport Layer Security (TLS)
Creation date:   2012-09-13
WG ID:           netconf
Number of pages: 19
URL:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-rfc5539bis-00.txt
Status:
http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis
Htmlized:        http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-00


Abstract:
   The Network Configuration Protocol (NETCONF) provides mechanisms to
   install, manipulate, and delete the configuration of network devices.
   This document describes how to use the Transport Layer Security (TLS)
   protocol to secure NETCONF exchanges.  This document obsoletes RFC
   5539.




The IETF Secretariat

--f46d043bd88ac6906004c996a4cc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Dear all

I have posted a revised version of the document=
 "NETCONF over TLS" with two minor changes:

<=
div>1) remove any reference to BEEP
2) replace host-name with dom=
ain-name in the rfc228 description



Best regards
Badra

---------- Forwarded message ----------
From:  <internet-drafts@ietf.org>

Date: Thu, Sep 13, 2012 at 4:41 PM
Subject: New Version Notification for=
 draft-ietf-netconf-rfc5539bis-00.txt
To: mbadra@gmail.com




A new version of I-D, draft-ietf-netconf-rfc5539bis-00.txt

has been successfully submitted by Mohamad Badra and posted to the

IETF repository.



Filename: =A0 =A0 =A0 =A0draft-ietf-netconf-rfc5539bis

Revision: =A0 =A0 =A0 =A000

Title: =A0 =A0 =A0 =A0 =A0 NETCONF Over Transport Layer Security (TLS)

Creation date: =A0 2012-09-13

WG ID: =A0 =A0 =A0 =A0 =A0 netconf

Number of pages: 19

URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.or=
g/internet-drafts/draft-ietf-netconf-rfc5539bis-00.txt

Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc=
/draft-ietf-netconf-rfc5539bis

Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-ie=
tf-netconf-rfc5539bis-00





Abstract:

=A0 =A0The Network Configuration Protocol (NETCONF) provides mechanisms to<=
br>
=A0 =A0install, manipulate, and delete the configuration of network devices=
.

=A0 =A0This document describes how to use the Transport Layer Security (TLS=
)

=A0 =A0protocol to secure NETCONF exchanges. =A0This document obsoletes RFC=


=A0 =A05539.









The IETF Secretariat







--f46d043bd88ac6906004c996a4cc--

From mehmet.ersue@nsn.com  Fri Sep 14 04:12:17 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C9021F8514 for ; Fri, 14 Sep 2012 04:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBYsQR8ixUOE for ; Fri, 14 Sep 2012 04:12:16 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDA321F850D for ; Fri, 14 Sep 2012 04:12:16 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q8EBCCMx028128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Sep 2012 13:12:12 +0200
Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q8EBC9Ed003011; Fri, 14 Sep 2012 13:12:12 +0200
Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 14 Sep 2012 13:11:27 +0200
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: Fri, 14 Sep 2012 13:11:25 +0200
Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640433BD3B@DEMUEXC006.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: WGLC for draft-ietf-netconf-rfc5539bis-00.txt
Thread-Index: Ac2Saa4rBrh95h0ERw6mxs3XcPWMZQ==
From: "Ersue, Mehmet (NSN - DE/Munich)" 
To: 
X-OriginalArrivalTime: 14 Sep 2012 11:11:27.0620 (UTC) FILETIME=[AF703440:01CD9269]
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: 1903
X-purgate-ID: 151667::1347621132-00003184-D8A8F9C3/0-0/0-0
Subject: [Netconf] WGLC for draft-ietf-netconf-rfc5539bis-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Sep 2012 11:12:17 -0000

Dear NETCONF WG,

Badra submitted the document draft-ietf-netconf-rfc5539bis-00.txt
addressing item 1 in the new charter
(http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-00).

This is a new WGLC for the RFC5539bis document, which is going to be
published on the standards track and will obsolete RFC 5539.=20

Please review the document and comment by September 28, 2012 (any
timezone). Thank you.

Mehmet & Bert


-----Original Message-----
From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On
Behalf Of ext internet-drafts@ietf.org
Sent: Thursday, September 13, 2012 4:42 PM
To: i-d-announce@ietf.org
Cc: netconf@ietf.org
Subject: [Netconf] I-D Action: draft-ietf-netconf-rfc5539bis-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
 This draft is a work item of the Network Configuration Working Group of
the IETF.

	Title           : NETCONF Over Transport Layer Security (TLS)
	Author(s)       : Mohamad Badra
	Filename        : draft-ietf-netconf-rfc5539bis-00.txt
	Pages           : 19
	Date            : 2012-09-13

Abstract:
   The Network Configuration Protocol (NETCONF) provides mechanisms to
   install, manipulate, and delete the configuration of network devices.
   This document describes how to use the Transport Layer Security (TLS)
   protocol to secure NETCONF exchanges.  This document obsoletes RFC
   5539.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


From mbj@tail-f.com  Fri Sep 14 04:27:42 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539CE21F843E for ; Fri, 14 Sep 2012 04:27:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.946
X-Spam-Level: 
X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aeqFT10wymJ for ; Fri, 14 Sep 2012 04:27:42 -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 CDC8D21F842C for ; Fri, 14 Sep 2012 04:27:41 -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 EB1DD1200054; Fri, 14 Sep 2012 13:27:40 +0200 (CEST)
Date: Fri, 14 Sep 2012 13:27:40 +0200 (CEST)
Message-Id: <20120914.132740.177060122.mbj@tail-f.com>
To: mehmet.ersue@nsn.com
From: Martin Bjorklund 
In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640433BD3B@DEMUEXC006.nsn-intra.net>
References: <80A0822C5E9A4440A5117C2F4CD36A640433BD3B@DEMUEXC006.nsn-intra.net>
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: netconf@ietf.org
Subject: Re: [Netconf] WGLC for draft-ietf-netconf-rfc5539bis-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Sep 2012 11:27:42 -0000

Hi,

"Ersue, Mehmet (NSN - DE/Munich)"  wrote:
> Dear NETCONF WG,
> 
> Badra submitted the document draft-ietf-netconf-rfc5539bis-00.txt
> addressing item 1 in the new charter
> (http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-00).
> 
> This is a new WGLC for the RFC5539bis document, which is going to be
> published on the standards track and will obsolete RFC 5539. 

I have reviewed this document twice (the last one was
http://www.ietf.org/mail-archive/web/netconf/current/msg07683.html).

I have not seen a reply / comment from the editor on this review.

I don't think this document is ready for WGLC.  It is not a trivial
update from RFC 5539 - it contains a new YANG data model that hasn't
really been discussed in the WG.  See my review above for initial
comments.


/martin

From mbj@tail-f.com  Fri Sep 14 04:32:37 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A3E21F84B5 for ; Fri, 14 Sep 2012 04:32:37 -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.090,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7F0qMQ69TPu for ; Fri, 14 Sep 2012 04:32: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 B28C021F8495 for ; Fri, 14 Sep 2012 04:32:36 -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 872AB1200054; Fri, 14 Sep 2012 13:32:35 +0200 (CEST)
Date: Fri, 14 Sep 2012 13:32:34 +0200 (CEST)
Message-Id: <20120914.133234.345863490.mbj@tail-f.com>
To: bertietf@bwijnen.net
From: Martin Bjorklund 
In-Reply-To: <504DBABD.70402@bwijnen.net>
References: <20120909025307.5206.71632.idtracker@ietfa.amsl.com>  <504DBABD.70402@bwijnen.net>
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: netconf@ietf.org
Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-get2-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Sep 2012 11:32:37 -0000

Hi,

"Bert Wijnen (IETF)"  wrote:
> First I would like to ask people to specifically read the
> problem statement sections and post comments on that.

Ok, here are my comments on this section.  I have not reviewed the
entire document yet.

1.1.1.  Too Much Data Returned

  I agree that it is probably a bug that  returns both the
  running config and the operational state.  However, the reason is
  not that you get too much data; the problem is that you get wrong
  data.


1.1.2.  No Last-Modified Indication or Time Filtering

  This would be nice to solve, but not very high prio.


1.1.3.  No Simple Instance Discovery Mechanism

  I think subtree filtering works fine for this purpose.  In fact, we
  rely on this heavily in our prodcuts.


1.1.4.  No Subtree Depth Control

  I agree that this is a real problem, and I would like to see a
  solution.  I would label this as "Too Much Data Returned".

  An example is how you check if a P-container exists or not, without
  returning the entire subtree under the P-container.   This is
  non-trivial today.


1.1.5.  Content Filter Specification is not Extensible

  This is a nice to have, imo.


1.1.6.  Subtree Filtering is Mandatory

  I guess this goes back to the discussion about NC/Lite.



/martin

From ietfc@btconnect.com  Fri Sep 14 05:03:10 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D442A21F847B for ; Fri, 14 Sep 2012 05:03:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.37
X-Spam-Level: 
X-Spam-Status: No, score=-3.37 tagged_above=-999 required=5 tests=[AWL=0.229,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-46bicPyeKc for ; Fri, 14 Sep 2012 05:03:10 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 322C921F843F for ; Fri, 14 Sep 2012 05:03:09 -0700 (PDT)
Received: from mail218-ch1-R.bigfish.com (10.43.68.233) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.23; Fri, 14 Sep 2012 12:03:08 +0000
Received: from mail218-ch1 (localhost [127.0.0.1])	by mail218-ch1-R.bigfish.com (Postfix) with ESMTP id 96A0D3000D7; Fri, 14 Sep 2012 12:03:08 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -25
X-BigFish: PS-25(zf7Iz9371I936eI542M1432I1418Id6f1izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh1315h304l1155h)
Received: from mail218-ch1 (localhost.localdomain [127.0.0.1]) by mail218-ch1 (MessageSwitch) id 134762418677581_509; Fri, 14 Sep 2012 12:03:06 +0000 (UTC)
Received: from CH1EHSMHS006.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238])	by mail218-ch1.bigfish.com (Postfix) with ESMTP id 1044B220293;	Fri, 14 Sep 2012 12:03:06 +0000 (UTC)
Received: from AMSPRD0710HT004.eurprd07.prod.outlook.com (157.56.249.85) by CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 14 Sep 2012 12:03:04 +0000
Received: from BY2PRD0510HT003.namprd05.prod.outlook.com (157.56.236.101) by pod51017.outlook.com (10.255.160.167) with Microsoft SMTP Server (TLS) id 14.16.190.9; Fri, 14 Sep 2012 12:02:42 +0000
Message-ID: <019901cd9270$ed53d8a0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Mohamad Badra , 
References: <20120913144158.920.10395.idtracker@ietfa.amsl.com> 
Date: Fri, 14 Sep 2012 13:03:07 +0100
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.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.236.101]
X-OriginatorOrg: btconnect.com
Subject: Re: [Netconf] Fwd: New Version Notification fordraft-ietf-netconf-rfc5539bis-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Sep 2012 12:03:11 -0000

----- Original Message -----
From: "Mohamad Badra" 
To: 
Sent: Thursday, September 13, 2012 4:05 PM

> Dear all
>
> I have posted a revised version of the document "NETCONF over TLS"
with two
> minor changes:
>
> 1) remove any reference to BEEP
> 2) replace host-name with domain-name in the rfc228 description
>

Badra

I think that you mean rfc822; and when I look at that description, I see
still see host-name, which is incorrect.

Tom Petch
> Best regards
> Badra
>
> ---------- Forwarded message ----------
> From: 
> Date: Thu, Sep 13, 2012 at 4:41 PM
> Subject: New Version Notification for
draft-ietf-netconf-rfc5539bis-00.txt
> To: mbadra@gmail.com
>
>
>
> A new version of I-D, draft-ietf-netconf-rfc5539bis-00.txt
> has been successfully submitted by Mohamad Badra and posted to the
> IETF repository.
>
> Filename:        draft-ietf-netconf-rfc5539bis
> Revision:        00
> Title:           NETCONF Over Transport Layer Security (TLS)
> Creation date:   2012-09-13
> WG ID:           netconf
> Number of pages: 19
> URL:
>
http://www.ietf.org/internet-drafts/draft-ietf-netconf-rfc5539bis-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis
> Htmlized:
http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-00
>
>
> Abstract:
>    The Network Configuration Protocol (NETCONF) provides mechanisms to
>    install, manipulate, and delete the configuration of network
devices.
>    This document describes how to use the Transport Layer Security
(TLS)
>    protocol to secure NETCONF exchanges.  This document obsoletes RFC
>    5539.
>
>
>
>
> The IETF Secretariat
>


------------------------------------------------------------------------
--------


> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>



From mehmet.ersue@nsn.com  Fri Sep 14 06:07:10 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0BFC21F84FD for ; Fri, 14 Sep 2012 06:07:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 219+QVQ3MJoZ for ; Fri, 14 Sep 2012 06:07:10 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 06FE321F8432 for ; Fri, 14 Sep 2012 06:07:09 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q8ED727B004349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Sep 2012 15:07:02 +0200
Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q8ED6xBT020791; Fri, 14 Sep 2012 15:07:02 +0200
Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 14 Sep 2012 15:06:51 +0200
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: Fri, 14 Sep 2012 15:06:50 +0200
Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640433BDCB@DEMUEXC006.nsn-intra.net>
In-Reply-To: <20120914.132740.177060122.mbj@tail-f.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Netconf] WGLC for draft-ietf-netconf-rfc5539bis-00.txt
Thread-Index: Ac2Sa/bzAsDwxIuvQa+mvdeLn3aNhQABMfRw
References: <80A0822C5E9A4440A5117C2F4CD36A640433BD3B@DEMUEXC006.nsn-intra.net> <20120914.132740.177060122.mbj@tail-f.com>
From: "Ersue, Mehmet (NSN - DE/Munich)" 
To: "ext Martin Bjorklund" 
X-OriginalArrivalTime: 14 Sep 2012 13:06:51.0474 (UTC) FILETIME=[CE607B20:01CD9279]
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: 1646
X-purgate-ID: 151667::1347628025-00006F5F-269B4018/0-0/0-0
Cc: netconf@ietf.org
Subject: Re: [Netconf] WGLC for draft-ietf-netconf-rfc5539bis-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Sep 2012 13:07:11 -0000

Hi Martin,

we discussed the -02 document in Vancouver and agreed to accept it as WG
item and to move the revision to WG last call. Your comments on the YANG
module did not seem to be blocking at that time.=20

We believe your comments are valuable and should/will be addressed
seriously as soon as possible. We would suggest to see them as part of
the WGLC together with others. Please be sure, the issues will be
tracked now with special caution.

Mehmet & Bert


> -----Original Message-----
> From: ext Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Friday, September 14, 2012 1:28 PM
> To: Ersue, Mehmet (NSN - DE/Munich)
> Cc: netconf@ietf.org
> Subject: Re: [Netconf] WGLC for draft-ietf-netconf-rfc5539bis-00.txt
>=20
> Hi,
>=20
> "Ersue, Mehmet (NSN - DE/Munich)"  wrote:
> > Dear NETCONF WG,
> >
> > Badra submitted the document draft-ietf-netconf-rfc5539bis-00.txt
> > addressing item 1 in the new charter
> > (http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-00).
> >
> > This is a new WGLC for the RFC5539bis document, which is going to be
> > published on the standards track and will obsolete RFC 5539.
>=20
> I have reviewed this document twice (the last one was
> http://www.ietf.org/mail-archive/web/netconf/current/msg07683.html).
>=20
> I have not seen a reply / comment from the editor on this review.
>=20
> I don't think this document is ready for WGLC.  It is not a trivial
> update from RFC 5539 - it contains a new YANG data model that hasn't
> really been discussed in the WG.  See my review above for initial
> comments.
>=20
>=20
> /martin

From andy@yumaworks.com  Fri Sep 14 08:35:52 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A171C21F850D for ; Fri, 14 Sep 2012 08:35:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.380,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TJJrW0NwOrJ for ; Fri, 14 Sep 2012 08:35:52 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD8A21F851E for ; Fri, 14 Sep 2012 08:35:51 -0700 (PDT)
Received: by ieak13 with SMTP id k13so7817947iea.31 for ; Fri, 14 Sep 2012 08:35:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=C4yommAjfBQLB8Bh9FnpIGDtwF2EJ96e6OQhKEEgwBM=; b=MgLZIf5cdPUxZDPu1wUXqbs8e2BDBOLlW7hKJlPdcUcbESqyRyPCnmwt2wy72Tu18y J5GmVjXByfz0B3QZ98HqNG/vEXBIa0LCoPixwIklOyUzXzct/kjH8hQ6/8zvbNcys6bA NbzkYCA6hG3JQyl3HPciH3dddaYUWulPMwDlYI2hcAd6cqRBDz4x8jxKisgrBFoTjFBT cpTuOJO0kNF6rZt2xIZ2gEiuLrzJXEDHip8IxW6EyBa7/zSQ44vOb3ON/FRryqYPpJWt +StyXl3qYyqGxqnJF3z29WHprVv96MjJlxmikEloKKvswd9c9cKBoYkTXSRoOCBKD9TD o8Rw==
MIME-Version: 1.0
Received: by 10.50.15.168 with SMTP id y8mr28541783igc.21.1347636950664; Fri, 14 Sep 2012 08:35:50 -0700 (PDT)
Received: by 10.50.7.35 with HTTP; Fri, 14 Sep 2012 08:35:50 -0700 (PDT)
In-Reply-To: <20120914.133234.345863490.mbj@tail-f.com>
References: <20120909025307.5206.71632.idtracker@ietfa.amsl.com>  <504DBABD.70402@bwijnen.net> <20120914.133234.345863490.mbj@tail-f.com>
Date: Fri, 14 Sep 2012 08:35:50 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQnfcSBbacGZslaPnkjp+e44N8VERmyS3+wPC+G+ZBcrBSCdRlQMtW4laTn+GK6bT7zQ+qp8
Cc: netconf@ietf.org
Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-get2-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Sep 2012 15:35:52 -0000

On Fri, Sep 14, 2012 at 4:32 AM, Martin Bjorklund  wrote:
> Hi,
>
> "Bert Wijnen (IETF)"  wrote:
>> First I would like to ask people to specifically read the
>> problem statement sections and post comments on that.
>
> Ok, here are my comments on this section.  I have not reviewed the
> entire document yet.
>
> 1.1.1.  Too Much Data Returned
>
>   I agree that it is probably a bug that  returns both the
>   running config and the operational state.  However, the reason is
>   not that you get too much data; the problem is that you get wrong
>   data.
>

It is all unwanted data adding to the size of the response.

>
> 1.1.2.  No Last-Modified Indication or Time Filtering
>
>   This would be nice to solve, but not very high prio.
>

IMO high priority because large configs take real resources to process.


>
> 1.1.3.  No Simple Instance Discovery Mechanism
>
>   I think subtree filtering works fine for this purpose.  In fact, we
>   rely on this heavily in our prodcuts.
>

It is complicated to construct all the subtree filters in an app,
and every list has to be known to the application.
Simply asking the server for  is 100 times easier.


>
> 1.1.4.  No Subtree Depth Control
>
>   I agree that this is a real problem, and I would like to see a
>   solution.  I would label this as "Too Much Data Returned".
>
>   An example is how you check if a P-container exists or not, without
>   returning the entire subtree under the P-container.   This is
>   non-trivial today.
>
>
> 1.1.5.  Content Filter Specification is not Extensible
>
>   This is a nice to have, imo.
>
>
> 1.1.6.  Subtree Filtering is Mandatory
>
>   I guess this goes back to the discussion about NC/Lite.
>

That discussion was subtree vs. nothing.
This is a different discussion because  is mandatory
and 'operational' is a separate datastore.  There are also other
optional types of filtering that are much less expensive
to implement than subtree filtering.


>
>
> /martin

Andy

From andy@yumaworks.com  Fri Sep 14 08:57:22 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4139821F84F8 for ; Fri, 14 Sep 2012 08:57:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=0.356,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZdb+i9WtY74 for ; Fri, 14 Sep 2012 08:57:21 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C097D21F84C4 for ; Fri, 14 Sep 2012 08:57:21 -0700 (PDT)
Received: by ieak13 with SMTP id k13so7860512iea.31 for ; Fri, 14 Sep 2012 08:57:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=Nf5CLo4NdSLhaE/mXggrn2WVm2G6AwSRe1FBXjJR2qA=; b=GVE3bZvAT09vwdxnSD6gBftP1XOTgwWXiejpZN9nRFOq6pVBXiDm0V8UIj1fRnLuWQ Zq0ZR5DamV9gsw7x0IMcRzsUf9oZI5UKPcQGt04Al9orISzpJeNFXeuauqDvYVlIlUzZ ofBeJ6KeLvBtRBrC5kfd4KH1jWqEIlzO8LvLDq7XijYg454XibkJma0+UjOlJZHy3O8d JrXVmi8Kpn7BajcSuCAl1ETWugnwRxwrEGv4FTswW61wkgFSS31Vp/yCT4mx5zqfrrJt 8WNoKQ2MHqy22QLYqy/tb5rJUtCoEJAekvYFM6F225zJnu/SsAVJeQw4+WLeor8HXEiQ PbJA==
MIME-Version: 1.0
Received: by 10.50.87.164 with SMTP id az4mr3474625igb.71.1347638241239; Fri, 14 Sep 2012 08:57:21 -0700 (PDT)
Received: by 10.50.7.35 with HTTP; Fri, 14 Sep 2012 08:57:21 -0700 (PDT)
Date: Fri, 14 Sep 2012 08:57:21 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQkbXJLUuFwdGeYtVvf8+YltWKcIq6UPS96NIvtEe7Xhuk+DIHZ+BDgOAq9Neymj9t65+rtV
Cc: netconf@ietf.org
Subject: [Netconf] subtree filtering (was Re: Fwd: I-D Action: draft-bierman-netconf-get2-00.txt)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Sep 2012 15:57:22 -0000

> 1.1.6.  Subtree Filtering is Mandatory
>
>   I guess this goes back to the discussion about NC/Lite.
>

IMO there are a few legitimate reasons for not supporting
subtree filtering (SHOULD instead of MUST is what get2 says):

  1) device does not have many data nodes to return
  2) device uses time-filtering to support polling updates
  3) NETCONF supports offline editing (get-config + copy-config)
      and filtering is not used in this editing mode

>
>
> /martin

Andy

From kwatsen@juniper.net  Fri Sep 14 09:40:22 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3872021F8503 for ; Fri, 14 Sep 2012 09:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cs5PZWsChVT for ; Fri, 14 Sep 2012 09:40:21 -0700 (PDT)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 97CC921F84C4 for ; Fri, 14 Sep 2012 09:40:21 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUFNd8GwU4jiYTEpIHY2A9NQ/QsGC25lE@postini.com; Fri, 14 Sep 2012 09:40:21 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; Fri, 14 Sep 2012 09:37:11 -0700
From: Kent Watsen 
To: Martin Bjorklund , "bertietf@bwijnen.net" 
Date: Fri, 14 Sep 2012 09:37:11 -0700
Thread-Topic: [Netconf] Fwd: I-D Action: draft-bierman-netconf-get2-00.txt
Thread-Index: Ac2Sly/OBk/oAV4zSxec/zYh0EEtxg==
Message-ID: 
In-Reply-To: <20120914.133234.345863490.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-get2-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Sep 2012 16:40:22 -0000

On 9/14/12 7:32 AM, "Martin Bjorklund"  wrote:

>1.1.1.  Too Much Data Returned
>
>  I agree that it is probably a bug that  returns both the
>  running config and the operational state.  However, the reason is
>  not that you get too much data; the problem is that you get wrong
>  data.


Martin, can you say some more about how wrong data is returned?

I think the first question needs to be if there is any value in keeping
 in any form.  If it not possible to prevent wrong data from being
returned, then maybe it should go away completely.

All the NETCONF servers I know return operational data via RPCs only,
perhaps an indication that putting operational data in the tree is not
what vendors want to do

Is there a limit to how much operational state can be put into the tree?
It seems reasonable to have a flag indicating if an interface is up/down,
but what about interface statistics or a routing table?  Of course it's
possible to put these things into the tree, but it seems that they would
always be leaf-nodes and would always be selected by themselves, at which
point they're no different than RPCs=8A

Thanks,
Kent


From mbadra@gmail.com  Fri Sep 14 10:00:14 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C45C21F851A for ; Fri, 14 Sep 2012 10:00:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9xVL0ZvmQKb for ; Fri, 14 Sep 2012 10:00:13 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8166F21F851E for ; Fri, 14 Sep 2012 10:00:12 -0700 (PDT)
Received: by lahm15 with SMTP id m15so3060586lah.31 for ; Fri, 14 Sep 2012 10:00:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wPINiwWEtK8tEf/y5TAleupl8Sq8sJUZhf44Om78pyo=; b=Vc6qwbXaf+IGGde8OpkA2x3zTATSwOy74cD98vI4phaFcSRSXGu9KTLzjRgB6izrQo le0BccCo597j+LCiFNFVVDw/xxkxzHjUbZjZR91FaU1nLZ+motL4iOuKOPgTe8w8kgg8 rCGxhagOPmEn5duKppsGBMV3AID3og2kEx1C09nXFvgZw0cmeFrM1OomuOTPFG0MNQ6P ZzfcYTTyZohUX6i5mvfccbuleE8yYGl6gslxI54Qb6Je8oebiOorqTTX3FZoc+O3mQiI 7XITR5lMHNvGmswS256/ym1BE9qbpARdtxtxWsY8J3vZMOMaRFkQt+KEyZcH4v+RHWpO /PFw==
MIME-Version: 1.0
Received: by 10.152.112.233 with SMTP id it9mr2921694lab.40.1347642010599; Fri, 14 Sep 2012 10:00:10 -0700 (PDT)
Sender: mbadra@gmail.com
Received: by 10.114.11.196 with HTTP; Fri, 14 Sep 2012 10:00:10 -0700 (PDT)
In-Reply-To: <20120914.132740.177060122.mbj@tail-f.com>
References: <80A0822C5E9A4440A5117C2F4CD36A640433BD3B@DEMUEXC006.nsn-intra.net> <20120914.132740.177060122.mbj@tail-f.com>
Date: Fri, 14 Sep 2012 19:00:10 +0200
X-Google-Sender-Auth: gSOqzWMdG80lrGvHSlmwrLUYoQc
Message-ID: 
From: Badra 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=f46d040838d35380e604c9ac5b1d
Cc: netconf@ietf.org
Subject: Re: [Netconf] WGLC for draft-ietf-netconf-rfc5539bis-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Sep 2012 17:00:14 -0000

--f46d040838d35380e604c9ac5b1d
Content-Type: text/plain; charset=ISO-8859-1

Dear Martin,

My apologies, I don't have any reason not to include your comments.

I will include all of your valuable comments after checking with Alan
regarding the YANG module.

Thank you!
Best regards
Badra



On Fri, Sep 14, 2012 at 1:27 PM, Martin Bjorklund  wrote:

> Hi,
>
> "Ersue, Mehmet (NSN - DE/Munich)"  wrote:
> > Dear NETCONF WG,
> >
> > Badra submitted the document draft-ietf-netconf-rfc5539bis-00.txt
> > addressing item 1 in the new charter
> > (http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-00).
> >
> > This is a new WGLC for the RFC5539bis document, which is going to be
> > published on the standards track and will obsolete RFC 5539.
>
> I have reviewed this document twice (the last one was
> http://www.ietf.org/mail-archive/web/netconf/current/msg07683.html).
>
> I have not seen a reply / comment from the editor on this review.
>
> I don't think this document is ready for WGLC.  It is not a trivial
> update from RFC 5539 - it contains a new YANG data model that hasn't
> really been discussed in the WG.  See my review above for initial
> comments.
>
>
> /martin
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

--f46d040838d35380e604c9ac5b1d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Dear Martin,

My apologies, I don't have any reason n=
ot to include your comments.

I will include all of=
 your valuable comments after checking with Alan regarding the YANG module.=




Thank you!
Best regards
Badra





O=
n Fri, Sep 14, 2012 at 1:27 PM, Martin Bjorklund <mbj@tail-f.com> wrote:


Hi,




"Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com> wrote:

> Dear NETCONF WG,

>

> Badra submitted the document draft-ietf-netconf-rfc5539bis-00.txt

> addressing item 1 in the new charter

> (http://tools.ietf.org/html/draft-ietf-netconf-rfc5539b=
is-00).

>

> This is a new WGLC for the RFC5539bis document, which is going to be
> published on the standards track and will obsolete RFC 5539.




I have reviewed this document twice (the last one was

http://www.ietf.org/mail-archive/web/netconf/current/=
msg07683.html).



I have not seen a reply / comment from the editor on this review.



I don't think this document is ready for WGLC. =A0It is not a trivial
update from RFC 5539 - it contains a new YANG data model that hasn't
really been discussed in the WG. =A0See my review above for initial

comments.





/martin


_____________________=
__________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf





--f46d040838d35380e604c9ac5b1d--

From andy@yumaworks.com  Fri Sep 14 10:06:32 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEDC21F8526 for ; Fri, 14 Sep 2012 10:06:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.042
X-Spam-Level: 
X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKtyV+hljskl for ; Fri, 14 Sep 2012 10:06:32 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC6721F851C for ; Fri, 14 Sep 2012 10:06:31 -0700 (PDT)
Received: by iabz21 with SMTP id z21so3581355iab.31 for ; Fri, 14 Sep 2012 10:06:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=aLIj/iR/vqNRdgaYYf7cnU+FuLJbu8qg93LVgvAz1n8=; b=Uo22YjgzrR/brWxQ1thLEiOl5hTMUt615sqn1H86qIFB+1zWaJZJTw5f3QyXo7Xo26 ksY9Sl+hw/9FuU7H4Pu9dwJ9XjCETst8YgcWm1hPPllYbBDajfWUdL0SbjnKb92Wrkl7 2PQLUm+B5tBigKWWlstArDYpaP0GNbrZgjptrWnVDIbU0XYNTj/pmwNstT+brOGFK6/3 689At78yRnBkRi4C2Rundb5fmseax8t8MmvsFRJIfdnSKUWXyE2WtdpMIs29Fru2Y+mm Xb8V9/RR/t13HsxIMC+YtNyoFvmGKKZLnwMtZ2pNIvzhDIsEMOO4Hou1vGxj5Sifr1nn 1L5g==
MIME-Version: 1.0
Received: by 10.42.145.66 with SMTP id e2mr3049922icv.18.1347642391268; Fri, 14 Sep 2012 10:06:31 -0700 (PDT)
Received: by 10.50.7.35 with HTTP; Fri, 14 Sep 2012 10:06:31 -0700 (PDT)
In-Reply-To: 
References: <20120914.133234.345863490.mbj@tail-f.com> 
Date: Fri, 14 Sep 2012 10:06:31 -0700
Message-ID: 
From: Andy Bierman 
To: Kent Watsen 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmgbcLWnxFsu3nPT1PQEs63kcs81hsMOleX5lwY8GgFpciDnmD/soqkI6ldvKlEhPSGXQXQ
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-get2-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Sep 2012 17:06:32 -0000

On Fri, Sep 14, 2012 at 9:37 AM, Kent Watsen  wrote:
>
>
> On 9/14/12 7:32 AM, "Martin Bjorklund"  wrote:
>
>>1.1.1.  Too Much Data Returned
>>
>>  I agree that it is probably a bug that  returns both the
>>  running config and the operational state.  However, the reason is
>>  not that you get too much data; the problem is that you get wrong
>>  data.
>
>
> Martin, can you say some more about how wrong data is returned?
>
> I think the first question needs to be if there is any value in keeping
>  in any form.  If it not possible to prevent wrong data from being
> returned, then maybe it should go away completely.
>

You mean 'deprecated' for a couple years, then 'obsolete'?
That might be OK.


> All the NETCONF servers I know return operational data via RPCs only,
> perhaps an indication that putting operational data in the tree is not
> what vendors want to do

Many servers are capable of supporting .

But there does seem to be a strong tendency not to
mix config=3Dtrue and config=3Dfalse nodes in the same YANG modules.
Keeping all the data separate duplicates all the 'framing' nodes
and keys.

The  operation defines config=3Dfalse + ancestor nodes + keys
to be the 'operational datastore'.  It is never mixed with config=3Dtrue
nodes.

There are problems with 1000 different  operations:
  - no input parameter consistency
  - less common code on the client
  - no common features like filtering
  - more complex access control rules; not sure
    what data is returned in each 
 - there is no standard mechanism to associate
   a  operation with any config=3Dtrue data


>
> Is there a limit to how much operational state can be put into the tree?


This seems like an implementation detail.
There is no limit -- it is up to the server.

> It seems reasonable to have a flag indicating if an interface is up/down,
> but what about interface statistics or a routing table?  Of course it's
> possible to put these things into the tree, but it seems that they would
> always be leaf-nodes and would always be selected by themselves, at which
> point they're no different than RPCs=C5=A0
>

I don't see any problem with mixing config=3Dtrue and config=3Dfalse
in the same conceptual tree.  The counters themselves do not
have to be stored in "the tree" -- another implementation detail.



> Thanks,
> Kent

Andy

From mbadra@gmail.com  Fri Sep 14 11:22:20 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C148721F8540 for ; Fri, 14 Sep 2012 11:22:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level: 
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvNGqy7bydt3 for ; Fri, 14 Sep 2012 11:22:19 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D223521F853C for ; Fri, 14 Sep 2012 11:22:16 -0700 (PDT)
Received: by lbky2 with SMTP id y2so3171838lbk.31 for ; Fri, 14 Sep 2012 11:22:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J2yXWM+MALUuORCywfukQqMtlyOOdrMrIC+ht6TvdZk=; b=ijwrc4Uj5tfBknnydPZW1yRmURfCXLZ/I/UZZpdrb4o2gd0DiLYykZm/KEAiNrpSQS q3oksMBgX/0hLgdl/YAiPxQHdPgbCq4EE1wDEIqzWqhvW6rzPW2XUhlmZUCrnl764wvS 8eOYdIAcHI2YBKtFpV8Bm++n72gxbSAcXx0ZhAmu0BOlRh6a8LqcIY29rsePUGQOeoeM lZ+Gi8qDRHDLBo+KgjWwS7kEOp3BH2uN9pjYe0HbVDG9kn1FMdyB40524o8oUe23yInI 6tGUzZ1I/8oOsMINM18fjMVb08cbKgnoIjwCxL48bADEs8Fn0zsNYDBzq9759OM+Mtyl LXWA==
MIME-Version: 1.0
Received: by 10.112.9.3 with SMTP id v3mr1422397lba.32.1347646935778; Fri, 14 Sep 2012 11:22:15 -0700 (PDT)
Received: by 10.114.11.196 with HTTP; Fri, 14 Sep 2012 11:22:15 -0700 (PDT)
In-Reply-To: <019901cd9270$ed53d8a0$4001a8c0@gateway.2wire.net>
References: <20120913144158.920.10395.idtracker@ietfa.amsl.com>  <019901cd9270$ed53d8a0$4001a8c0@gateway.2wire.net>
Date: Fri, 14 Sep 2012 20:22:15 +0200
Message-ID: 
From: Mohamad Badra 
To: "t.petch" 
Content-Type: multipart/alternative; boundary=e0cb4efe2b18e3c78d04c9ad80c4
Cc: netconf@ietf.org
Subject: Re: [Netconf] Fwd: New Version Notification fordraft-ietf-netconf-rfc5539bis-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Sep 2012 18:22:21 -0000

--e0cb4efe2b18e3c78d04c9ad80c4
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Sep 14, 2012 at 2:03 PM, t.petch  wrote:

> I think that you mean rfc822; and when I look at that description, I see
> still see host-name, which is incorrect.
>
> Tom Petch
>

My mistake!
I will make the change
Best regards
Badra

--e0cb4efe2b18e3c78d04c9ad80c4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Fri, Sep 14, 2012 at 2:03 PM, t.petch=
 <ietfc@btconnect.com> wrote:


I think that you mean rfc822; and when I look at that des=
cription, I see

still see host-name, which is incorrect.



Tom Petch

My mistake!
I will =
make the change
Best regards
Badra


--e0cb4efe2b18e3c78d04c9ad80c4--

From mbj@tail-f.com  Fri Sep 14 13:09:43 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3116621F8532 for ; Fri, 14 Sep 2012 13:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.971
X-Spam-Level: 
X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSPA05JVn702 for ; Fri, 14 Sep 2012 13:09:42 -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 A2E3421F852C for ; Fri, 14 Sep 2012 13:09:42 -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 966DB1200D78; Fri, 14 Sep 2012 22:09:40 +0200 (CEST)
Date: Fri, 14 Sep 2012 22:09:40 +0200 (CEST)
Message-Id: <20120914.220940.302691683.mbj@tail-f.com>
To: kwatsen@juniper.net
From: Martin Bjorklund 
In-Reply-To: 
References: <20120914.133234.345863490.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: netconf@ietf.org
Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-get2-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Sep 2012 20:09:43 -0000

Kent Watsen  wrote:
> 
> 
> On 9/14/12 7:32 AM, "Martin Bjorklund"  wrote:
> 
> >1.1.1.  Too Much Data Returned
> >
> >  I agree that it is probably a bug that  returns both the
> >  running config and the operational state.  However, the reason is
> >  not that you get too much data; the problem is that you get wrong
> >  data.
> 
> 
> Martin, can you say some more about how wrong data is returned?

Actually, there will be draft around this RSN.  So let us get back to
this when we're done with that draft.

> I think the first question needs to be if there is any value in keeping
>  in any form.  If it not possible to prevent wrong data from being
> returned, then maybe it should go away completely.
> 
> All the NETCONF servers I know return operational data via RPCs only,
> perhaps an indication that putting operational data in the tree is not
> what vendors want to do

All NETCONF servers I know, except Junos, put the operational data in
the tree.  This is also how SNMP does it.

> Is there a limit to how much operational state can be put into the tree?

No.  The tree is conceptual.  Noone pushes all counters into a db as
they are incremented.  They are typically fetched upon request.  Just
like your typical SNMP agent.

> It seems reasonable to have a flag indicating if an interface is up/down,
> but what about interface statistics or a routing table?  Of course it's
> possible to put these things into the tree, but it seems that they would
> always be leaf-nodes and would always be selected by themselves, at which
> point they're no different than RPCs.

I agree 100% with Andy's reply to this.  I can add that with
different RPCs it also becomes more tricky to do aggregation on a
higher level (reading a value here and a value there and combine
them).


/martin

From calle@tail-f.com  Sun Sep 16 10:11:22 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5D321F8528 for ; Sun, 16 Sep 2012 10:11:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.827
X-Spam-Level: 
X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFRnmis5jnHv for ; Sun, 16 Sep 2012 10:11:22 -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 21CFE21F8527 for ; Sun, 16 Sep 2012 10:11:22 -0700 (PDT)
Received: from [192.168.1.155] (c83-251-191-8.bredband.comhem.se [83.251.191.8]) by mail.tail-f.com (Postfix) with ESMTPSA id A83981200045; Sun, 16 Sep 2012 19:11:19 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
From: Carl Moberg 
In-Reply-To: 
Date: Fri, 14 Sep 2012 19:24:19 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <91EA56E9-2294-4087-B88B-E70E09AB1E07@tail-f.com>
References: 
To: Kent Watsen 
X-Mailer: Apple Mail (2.1486)
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-get2-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 16 Sep 2012 17:11:22 -0000

On Sep 14, 2012, at 9:37 AM, Kent Watsen  wrote:

> All the NETCONF servers I know return operational data via RPCs only,
> perhaps an indication that putting operational data in the tree is not
> what vendors want to do

 The two widely available server implementations I know of does not have =
this arbitrary limitation. I also know of at least 10 products shipping =
without the limitation and several more hitting the market over the =
coming quarters.

 I don't see that indication.

--
Carl Moberg
mailto:calle@tail-f.com
twitter: @cmoberg
http://www.tail-f.com/
=20
Tail-f Developer Days Silicon Valley is coming up:
 http://www.tail-f.com/tail-f-developer-days-silicon-valley



From iesg-secretary@ietf.org  Mon Sep 17 11:13:22 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAD721F8735; Mon, 17 Sep 2012 11:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.529
X-Spam-Level: 
X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAEAcldrxR1I; Mon, 17 Sep 2012 11:13:22 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBAC21F8723; Mon, 17 Sep 2012 11:13:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: IESG Secretary 
To: IETF Announcement List 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20120917181322.28209.40172.idtracker@ietfa.amsl.com>
Date: Mon, 17 Sep 2012 11:13:22 -0700
Cc: netconf@ietf.org
Subject: [Netconf] Last Call: RFC 4743 (Using NETCONF over the Simple Object Access	Protocol (SOAP)) to HISTORIC RFC
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Sep 2012 18:13:22 -0000

The IESG has received a request from an individual to reclassify =

RFC 4743 (Using NETCONF over the Simple Object Access Protocol (SOAP)) =

to HISTORIC. =


The IESG plans to make a decision in the next few weeks, and =

solicits final comments on this action. Please send substantive =

comments to the ietf at ietf.org mailing lists by 2012-10-01. =

Exceptionally, comments may be sent to iesg at ietf.org instead. =

In either case, please retain the beginning of the Subject line =

to allow automated sorting.

From iesg-secretary@ietf.org  Mon Sep 17 11:14:24 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E965921F873B; Mon, 17 Sep 2012 11:14:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.53
X-Spam-Level: 
X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkiEIODmjt6I; Mon, 17 Sep 2012 11:14:24 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C6421F8735; Mon, 17 Sep 2012 11:14:24 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: IESG Secretary 
To: IETF Announcement List 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20120917181424.5651.79343.idtracker@ietfa.amsl.com>
Date: Mon, 17 Sep 2012 11:14:24 -0700
Cc: netconf@ietf.org
Subject: [Netconf] Last Call: RFC 4744 (NETCONF Protocol over the Blocks Extensible	Exchange Protocol (BEEP)) to HISTORIC RFC
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Sep 2012 18:14:25 -0000

The IESG has received a request from an individual to reclassify =

RFC 4744 (NETCONF Protocol over the Blocks Extensible Exchange Protocol =

(BEEP)) to HISTORIC. =


The IESG plans to make a decision in the next few weeks, and =

solicits final comments on this action. Please send substantive =

comments to the ietf at ietf.org mailing lists by 2012-10-01. =

Exceptionally, comments may be sent to iesg at ietf.org instead. =

In either case, please retain the beginning of the Subject line =

to allow automated sorting.

From bertietf@bwijnen.net  Mon Sep 17 13:11:55 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C93021F8616 for ; Mon, 17 Sep 2012 13:11:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.399
X-Spam-Level: 
X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbL8m0TOtyDE for ; Mon, 17 Sep 2012 13:11:54 -0700 (PDT)
Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 7165721E8048 for ; Mon, 17 Sep 2012 13:11:52 -0700 (PDT)
Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TDhfa-00051G-NX for netconf@ietf.org; Mon, 17 Sep 2012 22:11:51 +0200
Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1TDhfa-0007nY-IP for netconf@ietf.org; Mon, 17 Sep 2012 22:11:50 +0200
Message-ID: <50578405.6070305@bwijnen.net>
Date: Mon, 17 Sep 2012 22:11:49 +0200
From: "Bert Wijnen (IETF)" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: netconf@ietf.org
References: <20120917181322.28209.40172.idtracker@ietfa.amsl.com>
In-Reply-To: <20120917181322.28209.40172.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120917 clean
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points:   -2.9 points pts rule name              description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd49b3dd258937d4d2eb1ff0bcaa943bd72
Subject: Re: [Netconf] Last Call: RFC 4743 (Using NETCONF over the Simple Object Access	Protocol (SOAP)) to HISTORIC RFC
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Sep 2012 20:11:55 -0000

You may wonder why the IESG all of sudden does an IETF Last Call.

The explanation is as follows:
- during the WG charter review by the IESG it was pointed
   out that the rules were changed/clarified here:
       http://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html

So that means we do not need to create an informational document
in the WG. Mehmet and I believe we had consensus in the WG to take this
action.

So our AD as requested the following from the secretariat:

According to http://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html (*)
the NETCONF WG would like to move RFC 4743 and RFC 4744 to  HISTORIC status
Here is the justification:

     These two documents have seen very little (if any) implementations or deployment,
     and none of the initial proponents are active in the NETCONF space anymore.
     No-one (else) in the WG is interested or willing to pick up responsibility
     for these documents. Therefore, the WG decided in the meeting session at
     IETF 84 to make them historic and approved this decision on the WG mailing list.

Hope this explains.
Same for RFC4744.

Bert


On 9/17/12 8:13 PM, IESG Secretary wrote:
> The IESG has received a request from an individual to reclassify
> RFC 4743 (Using NETCONF over the Simple Object Access Protocol (SOAP))
> to HISTORIC.
>
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action. Please send substantive
> comments to the ietf at ietf.org mailing lists by 2012-10-01.
> Exceptionally, comments may be sent to iesg at ietf.org instead.
> In either case, please retain the beginning of the Subject line
> to allow automated sorting.
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

From luchuk@snmp.com  Wed Sep 19 07:33:31 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9749221F8504 for ; Wed, 19 Sep 2012 07:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+BUwHvAe5Bu for ; Wed, 19 Sep 2012 07:33:30 -0700 (PDT)
Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id B0CA821F84FA for ; Wed, 19 Sep 2012 07:33:29 -0700 (PDT)
Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA26383; Wed, 19 Sep 2012 10:33:26 -0400 (EDT)
Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id KAA04808; Wed, 19 Sep 2012 10:33:25 -0400 (EDT)
Date: Wed, 19 Sep 2012 10:33:25 -0400 (EDT)
From: Alan Luchuk 
Message-Id: <201209191433.KAA04808@adminfs.snmp.com>
To: netconf@ietf.org
Subject: Re: [Netconf] Comments on draft-badra-netconf-rfc5539bis-02.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Sep 2012 14:33:31 -0000

Hello,

Regarding Martin's comments about draft-badra-netconf-rfc5539bis-02.txt, 
available at:

   http://www.ietf.org/mail-archive/web/netconf/current/msg07683.html

I've gathered and replied to the comments starting with the ones that 
should require little or no discussion, then progressing to the ones 
that may require more discussion.


Thanks to Martin for the following proposed changes.  These clarify the
specification and should require very little or no disussion, so I 
agree these changes should be added:

>  o  3.2
>
>   OLD:
> 
>    The server MUST verify the identity of the client to ensure that the
>    incoming client request is legitimate before any configuration or
>    state data is sent to or received from the client.
> 
>   NEW:
> 
>    The server MUST verify the identity of the client to ensure that the
>    incoming client request is legitimate before the NETCONF session is
>    started.
> 
> 
> 
> o  3.2.1
> 
>   OLD:
> 
>    The NETCONF server MUST implement the algorithms for deriving NETCONF
>    usernames from presented certificates that are documented in the
>    ietf-netconf-tls YANG module.
>
>   Add a forward reference, like:
>
>   NEW:
> 
>    The NETCONF server MUST implement the algorithms for deriving NETCONF
>    usernames from presented certificates that are documented in the
>    ietf-netconf-tls YANG module, defined in Section 3.2.1.3.
>                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> 
> 
> o  3.2.1.2
> 
>   OLD:
> 
>     For details on how the PSK
>     identity MAY be encoded in UTF-8, see section 5.1. of RFC [RFC6241].
> 
>   NEW:
> 
>     For details on how the PSK
>     identity MAY be encoded in UTF-8, see section 5.1. of RFC [RFC4279].
> 
> 
> 
> o  YANG module
>
>    The YANG module is not valid:
>  
>    ietf-netconf-tls.yang:389: error: unexpected keyword "pattern"
>  
>    (pattern should be a substatement to string)
>
>    OLD:
>
>      leaf valid-not-after {
>        type yang:date-and-time;
>        description
>          "This PSK identity is not valid before the given data
>           and time.";
>      }
> 
>      leaf key {
>        type string;
>        pattern '([0-9a-fA-F]){2}(:([0-9a-fA-F]){2})*';
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>        nacm:default-deny-all;
>        description
>          "The key associated with the PSK identity";
>      }
>

Proposed new:

     leaf valid-not-after {
       type yang:date-and-time;
       description
         "This PSK identity is not valid before the given data
          and time.";
     }

     leaf key {
       type string {
         pattern '([0-9a-fA-F]){2}(:([0-9a-fA-F]){2})*';
       }
       nacm:default-deny-all;
       description
         "The key associated with the PSK identity";
     }



>     o  feature map-certificates
> 
>       OLD:
> 
>         "The :map-certificates capability implements mapping X.509
>          certificates to NETCONF user names.";
> 
>       This is not a capability, and the ":" notation is confusing.
> 
>       NEW:
> 
>         "The map-certificates feature indicates that the server implements
>          mapping X.509 certificates to NETCONF user names.";
> 
> 
>     
>     o  feature map-pre-shared-keys
> 
>       OLD:
> 
>         "The :map-pre-shared-keys capability implements mapping TLS
>          pre-shared keys to NETCONF user names.";
> 
>       This is not a capability, and the ":" notation is confusing.
> 
>       NEW:
> 
>         "The map-pre-shared-keys feature indicates that the server 
>          implements mapping TLS pre-shared keys to NETCONF user names.";
>                                                                   ^^^^ 
>


The following proposed changes affect the content and may require more 
discussion.


>  
> o  3.2.1
> 
>     The NETCONF server MAY
>     use any of the following algorithms to produce the NETCONF username
>     from the certificate presented by the NETCONF client:
> 
>   This sounds as the server also may use some other algorithm?  Is
>   this intentional?
>

Proposed new text:

    The NETCONF server uses one of the following algorithms to produce a
    NETCONF username from the certificate presented by the NETCONF client:

> 
> o  3.2.1.1
> 
>    A client certificate has an identity: the certificate.  The TLS and
>    corresponding protocols provide an identity.
> 
>   Did you mean "The TLS and corresponding protocols provides this
>   identity"?  If not, please clarify.
> 
> 
> o  3.2.1.1
> 
>     If a locally held copy of a trusted CA certificate is configured in
>     the transformation container,
> 
>   What is "the transformation container"?
> 
>     and that CA certificate was used to
>     validate the path to the presented certificate, then the NETCONF
>     server SHOULD use that list entry in the transformation container.
> 
>   What should the server use that list entry for?   And since this is
>   a SHOULD, it seems it doesn't have to use it?  During which
>   circumstances can it choose not to use it?
> 

The first two paragraphs of section 3.2.1.1 do not clarify the specification,
so I propose deleting them.  I propose merging the last paragraph of section 
3.2.1.1 as the last paragraph of section 3.2.1.  Thus, the current sectioon 
3.2.1.1 will disappear.  After these changes, the last two paragraphs of 
section 3.2.1 should be fixed.  


OLD:

   The NETCONF server MUST implement all of these algorithms, and allow
   the deployer to choose the algorithm used.  The certificate-to-
   username-transforms container in the ietf-netconf-tls YANG module
   specifies how a NETCONF server transforms a certificate into a
   NETCONF username.

   If a locally held copy of a trusted CA certificate is configured in
   the transformation container, and that CA certificate was used to
   validate the path to the presented certificate, then the NETCONF
   server SHOULD use that list entry in the transformation container.
   All presented certificates validated by the configured CA certificate
   will be transformed to NETCONF usernames using the same
   transformation algorithm.


Proposed last two paragraphs of section 3.2.1:

   The NETCONF server MUST implement all of these algorithms, and allow
   the deployer to choose the algorithm used.  The cert-map list in the
   ietf-netconf-tls YANG module specifies how a NETCONF server transforms 
   a certificate into a NETCONF username.

   If the fingerprint of locally held copy of a trusted CA certificate is 
   configured in the cert-map list in the ietf-netconf-tls YANG module, 
   and that CA certificate is used to validate the certificate presented
   by the client, then the NETCONF server uses that cert-map list entry 
   to produce the NETCONF username.  This allows multiple client certificates 
   (all signed by the same trusted CA certificate) to be mapped to a NETCONF 
   username by a single entry in the cert-map list.


> 
> o  3.2.1.2
> 
>   OLD:
> 
>    On the server side, this PSK identity is used to look up the key 
>    corresponding to the presented PSK identity.  
> 
>    If the selected pre-shared keys match and the key is
>    valid, then the client is authenticated and the NETCONF username
>    associated with the PSK identity.
> 
>   Bad sentence.
>

Proposed new text:

   On the server side, this PSK identity is used to look up the key 
   corresponding to the PSK identity presented by the client.
   The server iterates through the psk list in the psk-map container in
   the ietf-netconf-tls YANG module.  It searches for a psk list entry 
   with a psk-identity leaf that matches the PSK identity presented by 
   the client.  If the server finds a matching entry, and the pre-shared 
   keys match, then this authenticates the client.  The server uses the 
   value from the user-name leaf in the psk list as the NETCONF username.
   If the server cannot find a psk-identity leaf that matches the PSK 
   identity presented by the client, or if the pre-shared keys do not
   match, then the server terminates the connection.



> 
> o  YANG module
> 
>    o  container cert-mappings
> 
>    OLD:
> 
>      On an incoming TLS connection, the client's presented certificate
>      MUST either be validated based on an established trust anchor, or
>      it MUST directly match a fingerprint in this container.  This
>      container does not provide any mechanisms for configuring the
>      trust anchors;
> 
>   NEW:
> 
>      On an incoming TLS connection, the client's presented certificate
>      MUST either be validated based on an established trust anchor, or
>      it MUST directly match a fingerprint in the 'cert-map' list.  This
>      module does not provide any mechanisms for configuring the
>      trust anchors;
> 
>   The term "this container" is used several times in this text where
>   the list 'cert-map' is meant.  Please check the text and rephrase.
> 
>      However, this container is
>      flexible to allow for situations where existing deployed
>      certificate infrastructures do not provide adequate subjectAltName
>      values for use as NETCONF usernames."
> 
>   How is this flexibility done?  This needs to be clarified.


I believe the following replacement text for the description of the 
cert-mappings container addresses the comments above:

    OLD:

     description
       "This container is used by a NETCONF server to map the NETCONF
        client's presented X.509 certificate to a NETCONF username.

        On an incoming TLS connection, the client's presented certificate
        MUST either be validated based on an established trust anchor, or
        it MUST directly match a fingerprint in this container.  This
        container does not provide any mechanisms for configuring the
        trust anchors; the transfer of any needed trusted certificates
        for certificate chain validation is expected to occur through an
        out-of-band transfer.

        Once the certificate has been found acceptable (either by
        certificate chain validation or directly matching a fingerprint
        in this container), this container is consulted to determine the
        appropriate NETCONF username to associate with the remote
        connection.  This is done by considering each list entry from
        this container in prioritized order according to its index value.
        Each list entry's fingerprint value determines whether the list
        entry is a match for the incoming connection:

            1) If the list entry's fingerprint value matches that
               of the presented certificate, then consider the list entry
               as a successful match.

            2) If the list entry's fingerprint value matches that
               of a locally held copy of a trusted CA certificate, and
               that CA certificate was part of the CA certificate chain
               to the presented certificate, then consider the list entry
               as a successful match.

               This feature lets the NETCONF server derive NETCONF
               usernames from all certificates signed by the trusted
               CA certificate.  The NETCONF server will derive all
               NETCONF usernames using the same derivation algorithm.
               The NETCONF server requires only a single list entry
               to configure this behavior.

        Once a matching list entry has been found, the NETCONF server
        uses the map-type value to determine how the NETCONF username
        associated with the session should be determined.  See the map-
        type leaf's description for details on determining the NETCONF
        username value.  If it is impossible to determine a NETCONF
        username from the list entry's data combined with the data
        presented in the certificate, then additional list entries MUST
        be searched looking for another potential match.  If a resulting
        NETCONF username mapped from a given list entry is not compatible
        with the needed requirements of a NETCONF username, then it MUST
        be considered an invalid match and additional list entries MUST
        be searched looking for another potential match.

        If no matching and valid list entry can be found, then the
        NETCONF server MUST close the connection, and MUST NOT accept
        NETCONF messages over it.

        Non-consecutive values of index are acceptable and implementations
        should continue to the next highest numbered list entry.  It is
        recommended that administrators skip index values to leave room
        for the insertion of future list entries (for example, use values
        of 10 and 20 when creating initial list entries).

        Security administrators are encouraged to make use of certificates
        with subjectAltName fields that can be used as NETCONF usernames
        so that a single root CA certificate can allow all child
        certificate's subjectAltName to map directly to a NETCONF
        usernames via a 1:1 transformation.  However, this container is
        flexible to allow for situations where existing deployed
        certificate infrastructures do not provide adequate subjectAltName
        values for use as NETCONF usernames.";


    NEW:

     description
       "The cert-mappings container is used by a NETCONF server to map the 
        NETCONF client's presented X.509 certificate to a NETCONF username.

        On an incoming TLS connection, the client's presented certificate
        MUST either be validated based on an established trust anchor, or
        it MUST directly match a fingerprint in the 'cert-map' list.  This
        module does not provide any mechanisms for configuring the
        trust anchors; the transfer of any needed trusted certificates
        for certificate chain validation is expected to occur through an
        out-of-band transfer.

        Once the certificate has been found acceptable (either by
        certificate chain validation or directly matching a fingerprint
        in the cert-map list), the cert-map list is consulted to determine 
        the appropriate NETCONF username to associate with the remote
        connection.  This is done by considering each cert-map list entry 
        in prioritized order according to its index value.  The cert-map
        entry's fingerprint determines whether the list entry is a match 
        for the incoming connection:

            1) If the cert-map list entry's fingerprint value matches that
               of the presented certificate, then consider the list entry
               as a successful match.

            2) If the cert-map list entry's fingerprint value matches that
               of a locally held copy of a trusted CA certificate, and
               that CA certificate was part of the CA certificate chain
               to the presented certificate, then consider the list entry
               as a successful match.

        Once a matching cert-map list entry has been found, the NETCONF 
        server uses the map-type leaf to determine how the NETCONF username
        associated with the session should be determined.  See the map-
        type leaf's description for details on determining the NETCONF
        username value.  If it is impossible to determine a NETCONF
        username from the cert-map list entry's data combined with the data
        presented in the certificate, then additional cert-map list entries 
        MUST be searched looking for another potential match.  If a resulting
        NETCONF username mapped from a given cert-map list entry is not 
        compatible with the needed requirements of a NETCONF username, 
        then it MUST be considered an invalid match and additional cert-map
        list entries MUST be searched looking for another potential match.

        If no matching and valid cert-map list entry can be found, then the
        NETCONF server MUST close the connection, and MUST NOT accept
        NETCONF messages over it.

        Non-consecutive values of index are acceptable and implementations
        should continue to the next highest numbered cert-map list entry.  
        It is recommended that administrators skip index values to leave 
        room for the insertion of future list entries (for example, use 
        values of 10 and 20 when creating initial list entries).

        Security administrators are encouraged to make use of certificates
        with subjectAltName fields that can be used as NETCONF usernames
        so that a single root CA certificate can allow all child
        certificate's subjectAltName to map directly to a NETCONF
        usernames via a 1:1 transformation.";


> 
> o  YANG module
>
> o  list cert-map
> 
>   Instead of using an integer key, I suggest you use an ordered-by
>   user list with an arbitratry string as key.   This use case is why
>   ordered-by user lists exist.
> 
> 
> o leaf map-type {
> 
>   Instead of enumerating all different combinations, I suggest you use
>   an ordered-by user leaf-list.  Also, I think the following structure
>   would be more natural:
> 
>     choice map-type {
>       leaf specified {
>         type nacm:user-name-type;  // note the new type
>         // replaces your "data" leaf
>       }
>       leaf-list from-certificate {
>         type enumeration {
>           enum rfc822Name;
>           enum dNSName;
>           enum ipAddress;
>         }
>         ordered-by user;
>       }
>     }
> 
>   Then you can use for example:
> 
>     bob
> 
>   or
> 
>     dnsName
>     rfc822Name

I prefer to leave the YANG objects as proposed.


I believe Badra has already or, or is in process of addressing
the following comment:

>
> Your description of RFC822 names makes reference to a host part.
>
> This is incorrect - it should be a domain part, as per RFC822.
>

Regards,
--Alan



From mbj@tail-f.com  Thu Sep 20 01:23:47 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7932D21F845E for ; Thu, 20 Sep 2012 01:23:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level: 
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jj-idOzLyfu for ; Thu, 20 Sep 2012 01:23:46 -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 C477721F8545 for ; Thu, 20 Sep 2012 01:23:45 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A559E1200D40; Thu, 20 Sep 2012 10:23:43 +0200 (CEST)
Date: Thu, 20 Sep 2012 10:23:43 +0200 (CEST)
Message-Id: <20120920.102343.171186924193685996.mbj@tail-f.com>
To: luchuk@snmp.com
From: Martin Bjorklund 
In-Reply-To: <201209191433.KAA04808@adminfs.snmp.com>
References: <201209191433.KAA04808@adminfs.snmp.com>
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: netconf@ietf.org
Subject: Re: [Netconf] Comments on draft-badra-netconf-rfc5539bis-02.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Sep 2012 08:23:47 -0000

Hi Alan,



Alan Luchuk  wrote:
> Proposed new:
> 
>      leaf valid-not-after {
>        type yang:date-and-time;
>        description
>          "This PSK identity is not valid before the given data
>           and time.";


s/data/date/

> >  
> > o  3.2.1
> > 
> >     The NETCONF server MAY
> >     use any of the following algorithms to produce the NETCONF username
> >     from the certificate presented by the NETCONF client:
> > 
> >   This sounds as the server also may use some other algorithm?  Is
> >   this intentional?
> >
> 
> Proposed new text:
> 
>     The NETCONF server uses one of the following algorithms to produce a
>     NETCONF username from the certificate presented by the NETCONF client:

Ok.

> > o  3.2.1.1
> > 
> >    A client certificate has an identity: the certificate.  The TLS and
> >    corresponding protocols provide an identity.
> > 
> >   Did you mean "The TLS and corresponding protocols provides this
> >   identity"?  If not, please clarify.
> > 
> > 
> > o  3.2.1.1
> > 
> >     If a locally held copy of a trusted CA certificate is configured in
> >     the transformation container,
> > 
> >   What is "the transformation container"?
> > 
> >     and that CA certificate was used to
> >     validate the path to the presented certificate, then the NETCONF
> >     server SHOULD use that list entry in the transformation container.
> > 
> >   What should the server use that list entry for?   And since this is
> >   a SHOULD, it seems it doesn't have to use it?  During which
> >   circumstances can it choose not to use it?
> > 
> 
> The first two paragraphs of section 3.2.1.1 do not clarify the specification,
> so I propose deleting them.  I propose merging the last paragraph of section 
> 3.2.1.1 as the last paragraph of section 3.2.1.  Thus, the current sectioon 
> 3.2.1.1 will disappear.  After these changes, the last two paragraphs of 
> section 3.2.1 should be fixed.  
> 
> 
> OLD:
> 
>    The NETCONF server MUST implement all of these algorithms, and allow
>    the deployer to choose the algorithm used.  The certificate-to-
>    username-transforms container in the ietf-netconf-tls YANG module
>    specifies how a NETCONF server transforms a certificate into a
>    NETCONF username.
> 
>    If a locally held copy of a trusted CA certificate is configured in
>    the transformation container, and that CA certificate was used to
>    validate the path to the presented certificate, then the NETCONF
>    server SHOULD use that list entry in the transformation container.
>    All presented certificates validated by the configured CA certificate
>    will be transformed to NETCONF usernames using the same
>    transformation algorithm.
> 
> 
> Proposed last two paragraphs of section 3.2.1:
> 
>    The NETCONF server MUST implement all of these algorithms, and allow
>    the deployer to choose the algorithm used.  The cert-map list in the
>    ietf-netconf-tls YANG module specifies how a NETCONF server transforms 
>    a certificate into a NETCONF username.
> 
>    If the fingerprint of locally held copy of a trusted CA certificate is 
>    configured in the cert-map list in the ietf-netconf-tls YANG module, 
>    and that CA certificate is used to validate the certificate presented
>    by the client, then the NETCONF server uses that cert-map list entry 
>    to produce the NETCONF username.  This allows multiple client certificates 
>    (all signed by the same trusted CA certificate) to be mapped to a NETCONF 
>    username by a single entry in the cert-map list.

Ok.

> > o  3.2.1.2
> > 
> >   OLD:
> > 
> >    On the server side, this PSK identity is used to look up the key 
> >    corresponding to the presented PSK identity.  
> > 
> >    If the selected pre-shared keys match and the key is
> >    valid, then the client is authenticated and the NETCONF username
> >    associated with the PSK identity.
> > 
> >   Bad sentence.
> >
> 
> Proposed new text:
> 
>    On the server side, this PSK identity is used to look up the key 
>    corresponding to the PSK identity presented by the client.
>    The server iterates through the psk list in the psk-map container in
>    the ietf-netconf-tls YANG module.  It searches for a psk list entry 
>    with a psk-identity leaf that matches the PSK identity presented by 
>    the client.  If the server finds a matching entry, and the pre-shared 
>    keys match, then this authenticates the client.  The server uses the 
>    value from the user-name leaf in the psk list as the NETCONF username.
>    If the server cannot find a psk-identity leaf that matches the PSK 
>    identity presented by the client, or if the pre-shared keys do not
>    match, then the server terminates the connection.

Since the 'psk-identity' is the key in the 'psk', I think the text
about iterating and matching is confusing.  It makes it sound as if
there are potentially multiple matching entries.  I suggest:

    On the server side, this PSK identity is used to look up an
    entry in the psk list.  If such an entry is found, and the pre-shared 
    keys match, then the client is authenticated.  The server uses the 
    value from the user-name leaf in the psk list as the NETCONF username.
    If the server cannot find an entry in the psk list, or if the
    pre-shared keys do not match, then the server terminates the
    connection.


> > o  YANG module
> > 
> >    o  container cert-mappings
> > 
> >    OLD:
> > 
> >      On an incoming TLS connection, the client's presented certificate
> >      MUST either be validated based on an established trust anchor, or
> >      it MUST directly match a fingerprint in this container.  This
> >      container does not provide any mechanisms for configuring the
> >      trust anchors;
> > 
> >   NEW:
> > 
> >      On an incoming TLS connection, the client's presented certificate
> >      MUST either be validated based on an established trust anchor, or
> >      it MUST directly match a fingerprint in the 'cert-map' list.  This
> >      module does not provide any mechanisms for configuring the
> >      trust anchors;
> > 
> >   The term "this container" is used several times in this text where
> >   the list 'cert-map' is meant.  Please check the text and rephrase.
> > 
> >      However, this container is
> >      flexible to allow for situations where existing deployed
> >      certificate infrastructures do not provide adequate subjectAltName
> >      values for use as NETCONF usernames."
> > 
> >   How is this flexibility done?  This needs to be clarified.
> 
> 
> I believe the following replacement text for the description of the 
> cert-mappings container addresses the comments above:
> 
>     OLD:
> 
>      description
>        "This container is used by a NETCONF server to map the NETCONF
>         client's presented X.509 certificate to a NETCONF username.
> 
>         On an incoming TLS connection, the client's presented certificate
>         MUST either be validated based on an established trust anchor, or
>         it MUST directly match a fingerprint in this container.  This
>         container does not provide any mechanisms for configuring the
>         trust anchors; the transfer of any needed trusted certificates
>         for certificate chain validation is expected to occur through an
>         out-of-band transfer.
> 
>         Once the certificate has been found acceptable (either by
>         certificate chain validation or directly matching a fingerprint
>         in this container), this container is consulted to determine the
>         appropriate NETCONF username to associate with the remote
>         connection.  This is done by considering each list entry from
>         this container in prioritized order according to its index value.
>         Each list entry's fingerprint value determines whether the list
>         entry is a match for the incoming connection:
> 
>             1) If the list entry's fingerprint value matches that
>                of the presented certificate, then consider the list entry
>                as a successful match.
> 
>             2) If the list entry's fingerprint value matches that
>                of a locally held copy of a trusted CA certificate, and
>                that CA certificate was part of the CA certificate chain
>                to the presented certificate, then consider the list entry
>                as a successful match.
> 
>                This feature lets the NETCONF server derive NETCONF
>                usernames from all certificates signed by the trusted
>                CA certificate.  The NETCONF server will derive all
>                NETCONF usernames using the same derivation algorithm.
>                The NETCONF server requires only a single list entry
>                to configure this behavior.
> 
>         Once a matching list entry has been found, the NETCONF server
>         uses the map-type value to determine how the NETCONF username
>         associated with the session should be determined.  See the map-
>         type leaf's description for details on determining the NETCONF
>         username value.  If it is impossible to determine a NETCONF
>         username from the list entry's data combined with the data
>         presented in the certificate, then additional list entries MUST
>         be searched looking for another potential match.  If a resulting
>         NETCONF username mapped from a given list entry is not compatible
>         with the needed requirements of a NETCONF username, then it MUST
>         be considered an invalid match and additional list entries MUST
>         be searched looking for another potential match.
> 
>         If no matching and valid list entry can be found, then the
>         NETCONF server MUST close the connection, and MUST NOT accept
>         NETCONF messages over it.
> 
>         Non-consecutive values of index are acceptable and implementations
>         should continue to the next highest numbered list entry.  It is
>         recommended that administrators skip index values to leave room
>         for the insertion of future list entries (for example, use values
>         of 10 and 20 when creating initial list entries).
> 
>         Security administrators are encouraged to make use of certificates
>         with subjectAltName fields that can be used as NETCONF usernames
>         so that a single root CA certificate can allow all child
>         certificate's subjectAltName to map directly to a NETCONF
>         usernames via a 1:1 transformation.  However, this container is
>         flexible to allow for situations where existing deployed
>         certificate infrastructures do not provide adequate subjectAltName
>         values for use as NETCONF usernames.";
> 
> 
>     NEW:
> 
>      description
>        "The cert-mappings container is used by a NETCONF server to map the 
>         NETCONF client's presented X.509 certificate to a NETCONF username.
> 
>         On an incoming TLS connection, the client's presented certificate
>         MUST either be validated based on an established trust anchor, or
>         it MUST directly match a fingerprint in the 'cert-map' list.  This
>         module does not provide any mechanisms for configuring the
>         trust anchors; the transfer of any needed trusted certificates
>         for certificate chain validation is expected to occur through an
>         out-of-band transfer.
> 
>         Once the certificate has been found acceptable (either by
>         certificate chain validation or directly matching a fingerprint
>         in the cert-map list), the cert-map list is consulted to determine 
>         the appropriate NETCONF username to associate with the remote
>         connection.  This is done by considering each cert-map list entry 
>         in prioritized order according to its index value.  The cert-map
>         entry's fingerprint determines whether the list entry is a match 
>         for the incoming connection:
> 
>             1) If the cert-map list entry's fingerprint value matches that
>                of the presented certificate, then consider the list entry
>                as a successful match.
> 
>             2) If the cert-map list entry's fingerprint value matches that
>                of a locally held copy of a trusted CA certificate, and
>                that CA certificate was part of the CA certificate chain
>                to the presented certificate, then consider the list entry
>                as a successful match.
> 
>         Once a matching cert-map list entry has been found, the NETCONF 
>         server uses the map-type leaf to determine how the NETCONF username
>         associated with the session should be determined.  See the map-
>         type leaf's description for details on determining the NETCONF
>         username value.  If it is impossible to determine a NETCONF
>         username from the cert-map list entry's data combined with the data
>         presented in the certificate, then additional cert-map list entries 
>         MUST be searched looking for another potential match.  If a resulting
>         NETCONF username mapped from a given cert-map list entry is not 
>         compatible with the needed requirements of a NETCONF username, 
>         then it MUST be considered an invalid match and additional cert-map
>         list entries MUST be searched looking for another potential match.
> 
>         If no matching and valid cert-map list entry can be found, then the
>         NETCONF server MUST close the connection, and MUST NOT accept
>         NETCONF messages over it.
> 
>         Non-consecutive values of index are acceptable and implementations
>         should continue to the next highest numbered cert-map list entry.  
>         It is recommended that administrators skip index values to leave 
>         room for the insertion of future list entries (for example, use 
>         values of 10 and 20 when creating initial list entries).
> 
>         Security administrators are encouraged to make use of certificates
>         with subjectAltName fields that can be used as NETCONF usernames
>         so that a single root CA certificate can allow all child
>         certificate's subjectAltName to map directly to a NETCONF
>         usernames via a 1:1 transformation.";

Ok, but see below.

I also beleive that anvert-map entry must have a fingerprint, right?
If so, the choice should be mandatory:

    container fingerprint {
      choice algorithm-and-hash {
        mandatory true;
        ...


> > o  YANG module
> >
> > o  list cert-map
> > 
> >   Instead of using an integer key, I suggest you use an ordered-by
> >   user list with an arbitratry string as key.   This use case is why
> >   ordered-by user lists exist.
> > 
> > 
> > o leaf map-type {
> > 
> >   Instead of enumerating all different combinations, I suggest you use
> >   an ordered-by user leaf-list.  Also, I think the following structure
> >   would be more natural:
> > 
> >     choice map-type {
> >       leaf specified {
> >         type nacm:user-name-type;  // note the new type
> >         // replaces your "data" leaf
> >       }
> >       leaf-list from-certificate {
> >         type enumeration {
> >           enum rfc822Name;
> >           enum dNSName;
> >           enum ipAddress;
> >         }
> >         ordered-by user;
> >       }
> >     }
> > 
> >   Then you can use for example:
> > 
> >     bob
> > 
> >   or
> > 
> >     dnsName
> >     rfc822Name
> 
> I prefer to leave the YANG objects as proposed.

Can you provide some motivation for this?  To me, this looks like a
rather direct translation from a MIB structure (which the document
also says it is).  I think it would be unfortunate to not use YANG's
more expressive constructs to make a nicer model.  Of course, what
makes a nice design is somewhat subjective, so I would like to hear
other people's opinion on this as well.

Note that there are three separate issues:

  1.  The use of a leaf-list instead of an
      enumeration-with-some-but-not-all-combinations.

  2.  Make the list 'ordered-by user' instead of using an integer
      value as a priority leaf.

  3.  Use a specific leaf for per-map-type data, instead of a generic
     'data' leaf that contains an opaque string.



I (pyang) also found a syntax error in the current version of the
module:

 revision "2012-09-13" {
   description
     "rename host-part to domain-part in the description of RFC822".

The '.' above should be ';'.


/martin

From balazs.lengyel@ericsson.com  Thu Sep 20 02:57:44 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3439721F8551 for ; Thu, 20 Sep 2012 02:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bn4hPlGivVSn for ; Thu, 20 Sep 2012 02:57:43 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1210221F853A for ; Thu, 20 Sep 2012 02:57:42 -0700 (PDT)
X-AuditID: c1b4fb25-b7f046d00000644c-84-505ae895d291
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 09.61.25676.598EA505; Thu, 20 Sep 2012 11:57:41 +0200 (CEST)
Received: from [159.107.230.122] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.1; Thu, 20 Sep 2012 11:57:41 +0200
Message-ID: <505AE894.7000003@ericsson.com>
Date: Thu, 20 Sep 2012 11:57:40 +0200
From: Balazs Lengyel 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Andy Bierman 
References: <20120909025307.5206.71632.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM+Jvre7UF1EBBs2PLS0eHJnFbjF1021W ByaPJUt+Mnm09F9kCWCK4rJJSc3JLEst0rdL4MpY9WUHa8Fe0Yqz56YzNTBeEuhi5OSQEDCR 2PC8lxnCFpO4cG89WxcjF4eQwClGiSNde5ggnLWMEg/2zAKr4hXQluj+dp8RxGYRUJXoap7J BGKzCRhJTO0/zwJiiwoES5zbuI0Nol5Q4uTMJ2BxEaD6C3Mngs1hFpCTWPyjB6xXWMBT4uOH aewQy1oZJbavmgK2gFMgUKLn6x1GiAZbiQtzrrNA2PIS29/OARskJKAh8fDCX9YJjIKzkOyb haRlFpKWBYzMqxiFcxMzc9LLjfRSizKTi4vz8/SKUzcxAsP14JbfqjsY75wTOcQozcGiJM5r vXWPv5BAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG+x9XZr6d9VJxzrHOuXlCp85qXWzZIXej 81fihKRKTdNtuW4hZyT0PNb03Fy09kDGlbrGjxtLNpyr8u5UX7PERXHTIYNuGbv86z9YlcOC Za94b9x7cVfVpzp1byOt3zcs2cyNTzBp7Pu7X7DEeu7VDaW6z3Z9DjFUlPTn4T8yoSLnhP49 D65AJZbijERDLeai4kQA8MgCFSUCAAA=
Cc: Netconf 
Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-get2-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Sep 2012 09:57:44 -0000

Hello,
I like your draft, it is interesting, should become a WG item.

1.1.2.  No Last-Modified Indication or Time Filtering -   Important

1.1.3.  No Simple Instance Discovery Mechanism -   Important

1.1.4.  No Subtree Depth Control - Most important

  1.1.5.  Content Filter Specification is not Extensible - We already 
have an own mechanism, but we can handle that internally

1.1.6.  Subtree Filtering is Mandatory  - unknown

We often also have a requirement, to be able to specify which leafs to 
return. We have lists with big numbers of leafs. Do others see this 
requirement?

-------------------------------------

  It seems strange that non-presence containers are not on a separate 
level. Why?

leaf names inside the filter-specshould be more expresive. A fileter 
called "filter"  is to generic -> subtree-filter

Balazs



On 2012-09-09 04:57, Andy Bierman wrote:
> FYI,
>
> I wrote this draft to address NETCONF data retrieval deficiencies.
> It is related to operational data, but not limited in scope to
> operational data.
>
>
>
> Andy
>
>
>
> ---------- Forwarded message ----------
> From:  
> Date: Sat, Sep 8, 2012 at 7:53 PM
> Subject: I-D Action: draft-bierman-netconf-get2-00.txt
> To: i-d-announce@ietf.org
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>          Title           : The NETCONF  Operation
>          Author(s)       : Andy Bierman
>          Filename        : draft-bierman-netconf-get2-00.txt
>          Pages           : 26
>          Date            : 2012-09-08
>
> Abstract:
>     This document describes NETCONF protocol enhancements to improve data
>     retrieval capabilities.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-bierman-netconf-get2
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-bierman-netconf-get2-00
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From mbj@tail-f.com  Thu Sep 20 03:35:24 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1B521F87DD for ; Thu, 20 Sep 2012 03:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=0.037,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1LI4px2qLnK for ; Thu, 20 Sep 2012 03:35: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 828AC21F87D8 for ; Thu, 20 Sep 2012 03:35:23 -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 569191200D48; Thu, 20 Sep 2012 12:35:21 +0200 (CEST)
Date: Thu, 20 Sep 2012 12:35:21 +0200 (CEST)
Message-Id: <20120920.123521.2161082953077082950.mbj@tail-f.com>
To: balazs.lengyel@ericsson.com
From: Martin Bjorklund 
In-Reply-To: <505AE894.7000003@ericsson.com>
References: <20120909025307.5206.71632.idtracker@ietfa.amsl.com>  <505AE894.7000003@ericsson.com>
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: netconf@ietf.org
Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-get2-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Sep 2012 10:35:24 -0000

Hi,

Balazs Lengyel  wrote:
> We often also have a requirement, to be able to specify which leafs to
> return.

You can do this already with subtree filtering:

  
     eth0
         
       
     ...
  


Or did you mean something else?


/martin

From andy@yumaworks.com  Thu Sep 20 06:24:27 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5917321F87A9 for ; Thu, 20 Sep 2012 06:24:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.627
X-Spam-Level: 
X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.350,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qu5mqXzDmlbu for ; Thu, 20 Sep 2012 06:24:26 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F10021F879C for ; Thu, 20 Sep 2012 06:24:26 -0700 (PDT)
Received: by qaec10 with SMTP id c10so380957qae.10 for ; Thu, 20 Sep 2012 06:24:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=D//qD5lQbQvp4THjDZ4rMCI6EL1+lKHNXU3Xyn78IJk=; b=B6h2WCdIuAFjSK+RiqwLyMjHSHUg/1mghrs27MUO7Hnt7c1ESJ2pm6EtsILPbadxEO OKvrKpIY4R5Yh+UnJvCIlZU2HqHyh+fZsUSKy3MRR91inRokjpAxKETTnf9FEwd4yRcI nWw2g9VSsO1vY3CGuTjnp05LVRGutTTsh5DzMtN4kOjJNoMEaTHLq+EPSwYuQ5ClCkLL y7PHT6RcL6MSoNJEMislSJpKSztaKJ11eIHjwHMNOjrGLpMNDerbuojJLV4b5ksRBSPJ lrt5ToN9UKeEOHDv0svm8vo/sq7YTPxdJFTHiHKA4qcKCRSGsq0J4/o6/yTRIj7NwQRw 4VxA==
MIME-Version: 1.0
Received: by 10.224.185.5 with SMTP id cm5mr4507836qab.87.1348147465933; Thu, 20 Sep 2012 06:24:25 -0700 (PDT)
Received: by 10.49.108.231 with HTTP; Thu, 20 Sep 2012 06:24:25 -0700 (PDT)
In-Reply-To: <505AE894.7000003@ericsson.com>
References: <20120909025307.5206.71632.idtracker@ietfa.amsl.com>  <505AE894.7000003@ericsson.com>
Date: Thu, 20 Sep 2012 06:24:25 -0700
Message-ID: 
From: Andy Bierman 
To: Balazs Lengyel 
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQlApikfmkjnnvUNqo2t78NJNey8Ehl6nctxHPiaQyj7+CO0teEPMibAoIWQ9NiQ3tX6/e2Y
Cc: Netconf 
Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-get2-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Sep 2012 13:24:27 -0000

On Thu, Sep 20, 2012 at 2:57 AM, Balazs Lengyel
 wrote:
> Hello,
> I like your draft, it is interesting, should become a WG item.
>

thanks

> 1.1.2.  No Last-Modified Indication or Time Filtering -   Important
>
> 1.1.3.  No Simple Instance Discovery Mechanism -   Important
>
> 1.1.4.  No Subtree Depth Control - Most important
>
>  1.1.5.  Content Filter Specification is not Extensible - We already have an
> own mechanism, but we can handle that internally
>
> 1.1.6.  Subtree Filtering is Mandatory  - unknown
>
> We often also have a requirement, to be able to specify which leafs to
> return. We have lists with big numbers of leafs. Do others see this
> requirement?

select leafs by name?  sub-tree filtering does that.
Filter by name prefix?  XPath can do that (starts-with(.) = 'foo')
Not sure this is a new requirement.


>
> -------------------------------------
>
>  It seems strange that non-presence containers are not on a separate level.
> Why?

I was thinking that they should be ignored for layering because
they are transparent, but maybe that is too complicated and
not how NP containers should be retrieved.  It would be simpler
to treat every child node as the 'next layer'.

>
> leaf names inside the filter-specshould be more expresive. A fileter called
> "filter"  is to generic -> subtree-filter

OK

>
> Balazs
>


Andy

>
>
> On 2012-09-09 04:57, Andy Bierman wrote:
>>
>> FYI,
>>
>> I wrote this draft to address NETCONF data retrieval deficiencies.
>> It is related to operational data, but not limited in scope to
>> operational data.
>>
>>
>>
>> Andy
>>
>>
>>
>> ---------- Forwarded message ----------
>> From:  
>> Date: Sat, Sep 8, 2012 at 7:53 PM
>> Subject: I-D Action: draft-bierman-netconf-get2-00.txt
>> To: i-d-announce@ietf.org
>>
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>>          Title           : The NETCONF  Operation
>>          Author(s)       : Andy Bierman
>>          Filename        : draft-bierman-netconf-get2-00.txt
>>          Pages           : 26
>>          Date            : 2012-09-08
>>
>> Abstract:
>>     This document describes NETCONF protocol enhancements to improve data
>>     retrieval capabilities.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-bierman-netconf-get2
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-bierman-netconf-get2-00
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> System Manager
> ECN: 831 7320                        Tel: +36-1-437-7320
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>

From iesg-secretary@ietf.org  Thu Sep 20 08:44:23 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D86021F8703; Thu, 20 Sep 2012 08:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.537
X-Spam-Level: 
X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHn4Ab66G+x3; Thu, 20 Sep 2012 08:44:22 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9AC21F8712; Thu, 20 Sep 2012 08:44:22 -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.34
Message-ID: <20120920154422.13167.74604.idtracker@ietfa.amsl.com>
Date: Thu, 20 Sep 2012 08:44:22 -0700
Cc: netconf WG 
Subject: [Netconf] WG Action: Rechartered Network Configuration (netconf)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Sep 2012 15:44:23 -0000

The Network Configuration (netconf) working group in the Operations and
Management Area of the IETF has been rechartered. For additional
information please contact the Area Directors or the WG Chairs.

Network Configuration (netconf)
------------------------------------------------
Current Status: Active Working Group

Chairs:
  Bert Wijnen 
  Mehmet Ersue 

Technical advisors:
  Tim Polk 

Assigned Area Director:
  Benoit Claise 

Mailing list
  Address: netconf@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/netconf
  Archive: http://www.ietf.org/mail-archive/web/netconf/

Charter of Working Group:

Configuration of networks of devices has become a critical requirement 
for operators in today's highly interconnected networks. Large and small 
operators alike have developed their own mechanisms or have used vendor 
specific mechanisms to transfer configuration data to and from a device 
and to examine device state information which may impact the 
configuration. Each of these mechanisms may be different in various 
aspects, such as session establishment, user authentication, 
configuration data exchange, and error responses.

The NETCONF protocol has the following characteristics:

- Provides retrieval mechanisms which can differentiate between 
configuration data and non-configuration data
- Is extensible enough so that vendors can provide access to all 
configuration data on the device using a single protocol
- Has a programmatic interface (avoids screen scraping and formatting-
related changes between releases)
- Uses an XML-based data representation, that can be easily manipulated 
using non-specialized XML manipulation tools.
- Supports integration with existing user authentication methods
- Supports integration with existing configuration database systems
- Supports multiple (e.g. candidate and running) data-stores to optimize 
configuration preparation and activation
- Supports network wide configuration transactions (with features such 
as locking and rollback capability)
- Runs over a secure transport; SSH is mandatory to implement while TLS, 
BEEP, and SOAP are optional transports.
- Provides support for asynchronous notifications.
- Supports an Access Control Model and a YANG module for configuring the 
Access Control parameters.
- Supports a YANG module for System Notifications

The NETCONF protocol is data modeling language independent, but YANG is 
the recommended NETCONF modeling language, which introduces advanced 
language features for configuration management.

In the current phase of NETCONF's incremental development the workgroup 
will focus on following items:

1. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., update 
RFC 5539).

2. Based on the implementation, deployment experience and 
interoperability testing, the WG will produce a NETCONF status report. 
The result may be clarifications for RFC6241 and RFC6242 and addressing  
any reported errata.

Milestones:
  Done     - WG Last Call on rfc4741bis
  Done     - Send with-defaults to IESG for consideration as Proposed
Standard
  Done     - first WG draft (rev 00) on NACM posted
  Done     - rfc4741bis to IESG for consideration as Proposed Standard
  Done     - Send rfc4742bis to IESG for consideration as proposed
Standard
  Done     - first WG draft (rev 00) on NETCONF specific YANG modules
posted
  Done     - WGLC for NACM document
  Done     - WGLC for NETCONF specific notifications document
  Done     - submit NACM document to IESG for consideration as Proposed
Standard
  Done     - submit NETCONF specific notifications document to IESG for
consideration as Proposed Standard
  Sep 2012 - WGLC for rfc5539bis
  Sep 2012 - submit initial WG draft for rfc5539bis
  Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed
Standard
  Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and
6242
  Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment
experience
  Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience
  Feb 2013 - possibly submit RFC6241/6242 implementation/deployment
experience doc to IESG for publication as Informational RFC
  Mar 2013 - Evaluate if more work needs to be done by NETCONF WG



From luchuk@snmp.com  Mon Sep 24 10:21:17 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7129021F8835 for ; Mon, 24 Sep 2012 10:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fN9RZanjtzZP for ; Mon, 24 Sep 2012 10:21:13 -0700 (PDT)
Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 45D3021F8841 for ; Mon, 24 Sep 2012 10:21:11 -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 NAA27701; Mon, 24 Sep 2012 13:21:08 -0400 (EDT)
Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id NAA26165; Mon, 24 Sep 2012 13:21:06 -0400 (EDT)
Date: Mon, 24 Sep 2012 13:21:06 -0400 (EDT)
From: Alan Luchuk 
Message-Id: <201209241721.NAA26165@adminfs.snmp.com>
To: netconf@ietf.org
Subject: Re: [Netconf] Comments on draft-badra-netconf-rfc5539bis-02.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2012 17:21:17 -0000

Hello,

I've deleted the text for nested replies to items that probably do not
need further discussion.


>Alan Luchuk  wrote:
>
>> > o  3.2.1.2
>> > 
>> >   OLD:
>> > 
>> >    On the server side, this PSK identity is used to look up the key 
>> >    corresponding to the presented PSK identity.  
>> > 
>> >    If the selected pre-shared keys match and the key is
>> >    valid, then the client is authenticated and the NETCONF username
>> >    associated with the PSK identity.
>> > 
>> >   Bad sentence.
>> >
>> 
>> Proposed new text:
>> 
>>    On the server side, this PSK identity is used to look up the key 
>>    corresponding to the PSK identity presented by the client.
>>    The server iterates through the psk list in the psk-map container in
>>    the ietf-netconf-tls YANG module.  It searches for a psk list entry 
>>    with a psk-identity leaf that matches the PSK identity presented by 
>>    the client.  If the server finds a matching entry, and the pre-shared 
>>    keys match, then this authenticates the client.  The server uses the 
>>    value from the user-name leaf in the psk list as the NETCONF username.
>>    If the server cannot find a psk-identity leaf that matches the PSK 
>>    identity presented by the client, or if the pre-shared keys do not
>>    match, then the server terminates the connection.
>
>Since the 'psk-identity' is the key in the 'psk', I think the text
>about iterating and matching is confusing.  It makes it sound as if
>there are potentially multiple matching entries.  I suggest:
>
>    On the server side, this PSK identity is used to look up an
>    entry in the psk list.  If such an entry is found, and the pre-shared 
>    keys match, then the client is authenticated.  The server uses the 
>    value from the user-name leaf in the psk list as the NETCONF username.
>    If the server cannot find an entry in the psk list, or if the
>    pre-shared keys do not match, then the server terminates the
>    connection.

Sounds good.


>>         NETCONF messages over it.
>> 
>>         Non-consecutive values of index are acceptable and implementations
>>         should continue to the next highest numbered cert-map list entry.  
>>         It is recommended that administrators skip index values to leave 
>>         room for the insertion of future list entries (for example, use 
>>         values of 10 and 20 when creating initial list entries).
>> 
>>         Security administrators are encouraged to make use of certificates
>>         with subjectAltName fields that can be used as NETCONF usernames
>>         so that a single root CA certificate can allow all child
>>         certificate's subjectAltName to map directly to a NETCONF
>>         usernames via a 1:1 transformation.";
>
>Ok, but see below.
>
>I also beleive that anvert-map entry must have a fingerprint, right?
>If so, the choice should be mandatory:
>
>    container fingerprint {
>      choice algorithm-and-hash {
>        mandatory true;
>        ...


Good point.

Not sure, but I think the map-type from the cert-map entry, and the 
psk-identity, user-name, and key from the psk-map all should be 
mandatory as well.


>
>
>> > o  YANG module
>> >
>> > o  list cert-map
>> > 
>> >   Instead of using an integer key, I suggest you use an ordered-by
>> >   user list with an arbitratry string as key.   This use case is why
>> >   ordered-by user lists exist.
>> > 
>> > 
>> > o leaf map-type {
>> > 
>> >   Instead of enumerating all different combinations, I suggest you use
>> >   an ordered-by user leaf-list.  Also, I think the following structure
>> >   would be more natural:
>> > 
>> >     choice map-type {
>> >       leaf specified {
>> >         type nacm:user-name-type;  // note the new type
>> >         // replaces your "data" leaf
>> >       }
>> >       leaf-list from-certificate {
>> >         type enumeration {
>> >           enum rfc822Name;
>> >           enum dNSName;
>> >           enum ipAddress;
>> >         }
>> >         ordered-by user;
>> >       }
>> >     }
>> > 
>> >   Then you can use for example:
>> > 
>> >     bob
>> > 
>> >   or
>> > 
>> >     dnsName
>> >     rfc822Name
>> 
>> I prefer to leave the YANG objects as proposed.
>
>Can you provide some motivation for this?  To me, this looks like a
>rather direct translation from a MIB structure (which the document
>also says it is).  

That's pretty much the reason.  I prefer making the newer standard 
similar to the existing standard to ease the transition to the newer 
standard.



>I (pyang) also found a syntax error in the current version of the
>module:
>
> revision "2012-09-13" {
>   description
>     "rename host-part to domain-part in the description of RFC822".
>
>The '.' above should be ';'.


Thanks.  Another revision statement should probably be added as well.


Regards,
--Alan



From j.schoenwaelder@jacobs-university.de  Mon Sep 24 10:41:45 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A520E21F87C9 for ; Mon, 24 Sep 2012 10:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.213
X-Spam-Level: 
X-Spam-Status: No, score=-103.213 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMYDECelumyJ for ; Mon, 24 Sep 2012 10:41:45 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A7C9B21F8527 for ; Mon, 24 Sep 2012 10:41:44 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 45EC120C0C; Mon, 24 Sep 2012 19:41:43 +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 d3_ZLGLFaWWX; Mon, 24 Sep 2012 19:41:43 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DCB2620C0B; Mon, 24 Sep 2012 19:41:42 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id AF56F21F6AEC; Mon, 24 Sep 2012 19:41:38 +0200 (CEST)
Date: Mon, 24 Sep 2012 19:41:38 +0200
From: Juergen Schoenwaelder 
To: Alan Luchuk 
Message-ID: <20120924174138.GA51382@elstar.local>
Mail-Followup-To: Alan Luchuk , netconf@ietf.org
References: <201209241721.NAA26165@adminfs.snmp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201209241721.NAA26165@adminfs.snmp.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netconf@ietf.org
Subject: Re: [Netconf] Comments on draft-badra-netconf-rfc5539bis-02.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2012 17:41:45 -0000

On Mon, Sep 24, 2012 at 01:21:06PM -0400, Alan Luchuk wrote:
> >> I prefer to leave the YANG objects as proposed.
> >
> >Can you provide some motivation for this?  To me, this looks like a
> >rather direct translation from a MIB structure (which the document
> >also says it is).  
> 
> That's pretty much the reason.  I prefer making the newer standard 
> similar to the existing standard to ease the transition to the newer 
> standard.

I think it is most important that we do here is consistent with
what will be in draft-ietf-netmod-snmp-cfg.

/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 Sep 24 14:54:22 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34FB221F88A6 for ; Mon, 24 Sep 2012 14:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IysDf9bVn437 for ; Mon, 24 Sep 2012 14:54:21 -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 A02FE21F88A3 for ; Mon, 24 Sep 2012 14:54:21 -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 BCAF61200048 for ; Mon, 24 Sep 2012 23:54:19 +0200 (CEST)
Date: Mon, 24 Sep 2012 23:54:19 +0200 (CEST)
Message-Id: <20120924.235419.451387775.mbj@tail-f.com>
To: netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <201209241716.NAA25603@adminfs.snmp.com>
References: <201209241716.NAA25603@adminfs.snmp.com>
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
Subject: Re: [Netconf] Comments on draft-badra-netconf-rfc5539bis-02.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2012 21:54:22 -0000

Alan Luchuk  wrote:
> >> > o  YANG module
> >> >
> >> > o  list cert-map
> >> > 
> >> >   Instead of using an integer key, I suggest you use an ordered-by
> >> >   user list with an arbitratry string as key.   This use case is why
> >> >   ordered-by user lists exist.
> >> > 
> >> > 
> >> > o leaf map-type {
> >> > 
> >> >   Instead of enumerating all different combinations, I suggest you use
> >> >   an ordered-by user leaf-list.  Also, I think the following structure
> >> >   would be more natural:
> >> > 
> >> >     choice map-type {
> >> >       leaf specified {
> >> >         type nacm:user-name-type;  // note the new type
> >> >         // replaces your "data" leaf
> >> >       }
> >> >       leaf-list from-certificate {
> >> >         type enumeration {
> >> >           enum rfc822Name;
> >> >           enum dNSName;
> >> >           enum ipAddress;
> >> >         }
> >> >         ordered-by user;
> >> >       }
> >> >     }
> >> > 
> >> >   Then you can use for example:
> >> > 
> >> >     bob
> >> > 
> >> >   or
> >> > 
> >> >     dnsName
> >> >     rfc822Name
> >> 
> >> I prefer to leave the YANG objects as proposed.
> >
> >Can you provide some motivation for this?  To me, this looks like a
> >rather direct translation from a MIB structure (which the document
> >also says it is).  
> 
> That's pretty much the reason.  I prefer making the newer standard 
> similar to the existing standard to ease the transition to the newer 
> standard.

I am not sure I agree with this statement in general, but even with
the proposed changes to the data model, it is really very similar to
the MIB.


> >I (pyang) also found a syntax error in the current version of the
> >module:
> >
> > revision "2012-09-13" {
> >   description
> >     "rename host-part to domain-part in the description of RFC822".
> >
> >The '.' above should be ';'.
> 
> 
> Thanks.  Another revision statement should probably be added as well.

No, we add revision statement only when a module is published as an
RFC.  When it is still in an I-D, we just update the single revision
statement with a new data.  I-Ds are relly just work in progress.


/martin

From bwijnen@ripe.net  Wed Sep 26 01:24:29 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABFA21F881F for ; Wed, 26 Sep 2012 01:24:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTG3b2qG4drE for ; Wed, 26 Sep 2012 01:24:20 -0700 (PDT)
Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id D9DDA21F881D for ; Wed, 26 Sep 2012 01:24:18 -0700 (PDT)
Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TGmum-0005Tk-2F for netconf@ietf.org; Wed, 26 Sep 2012 10:24:17 +0200
Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1TGmul-0003IL-CA for netconf@ietf.org; Wed, 26 Sep 2012 10:24:16 +0200
Message-ID: <5062BBAF.2070500@ripe.net>
Date: Wed, 26 Sep 2012 10:24:15 +0200
From: Bert Wijnen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Netconf 
Content-Type: multipart/mixed; boundary="------------060202000002090807090308"
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120926 clean
X-RIPE-Spam-Level: ---
X-RIPE-Spam-Report: Spam Total Points:   -3.7 points pts rule name              description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.8 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e25c39cb649bdbc2a37ca524a4d23f0bb
Subject: [Netconf] Netconf Interoperability Testing Nov 3-4, 2012 in Atlanta
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2012 08:24:29 -0000

This is a multi-part message in MIME format.
--------------060202000002090807090308
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear NETCONF implementers,

We have secured a room at the IETF85 Hotel (Atlanta Hilton)
for 2 days for NETCONF interoperability testing.

This will be on
- Saturday Nov. 3rd from 9:00-18:00
- Sunday   Nov. 4th from 9:00-16:00

We are planning/trying to provide remote access for remote
participants. We're not sure yet if we can have it for both days
and how well it will work. We will focus on the participants
that show up at the event (after all they travel and make
expenses to be there) to maximize the high-bandwidth
interaction we can have in the f2f event.

If you want to participate, you can register here:
   http://doodle.com/nibe3k4c4zuq84mw

BUT, note that access to the event requires that you:
- sign an NDA and
- bring an implementation to test with the other participants
- send us a list of what NETCONF features/capabilitues and
   which YANG modules your server/client implements/supports.

The NDA we intend to use is attached. It is still called "draft",
but unless someone detect a fatal flaw in it, this will be the
one that we use.

Bert and Mehmet

--------------060202000002090807090308
Content-Type: application/pdf;
 name="AtlantaNetconfInteropNDA-draft-02.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="AtlantaNetconfInteropNDA-draft-02.pdf"

JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0
ZURlY29kZT4+CnN0cmVhbQp4nO1cy47sthHdz1f0OsB0SIoSJWDQQD8X2RkYwAsju9gBvDAQ
b/L7ER8SD1ksUtOPe2MnuECjRy2RxeKpqlNV1BV7ufv32792Yifmb/3U77vdqOV+2v3+8+7H
v+x+87/N/37/59vp8012417vjFH7Yff5j91fb3In9e7zl58+hDzID6EO792H6A7v6kPow/t8
pT+86+W6vzK4X429fTzM3yZ3x9H+fYo/nd1Vf+/FfeJIVzfS7dB9SGEvS+l+jJf9XFK5H708
7jN8d6NIlGc6mGUA2bvr/p4uzi0HkMmKLo278Zos9O+ff3u7fr79kGlOddPO9MO+z/VmVxsW
YaI8cgTZQJNyijLII9x/cpKf3efFfforV1agvrdbqcX8eedWzoPbX70At/khJeyGSnZKKWZk
GaVnlGVTHlct+GmUjNoPa77mQkgUjt/dTvsVhe1z6LjGjVMqXmjs4bx9484IsVdefLWTImhM
OKTNUliB5nF64/Si7f7az9FO4tex4H29cHKfZ6fXPmg9DLP+gffgUxcY8rKor1vuvMKVW5Tj
mg8mRTK9/65gaBgimJob6LwKOI/g5MRbUObCYri5dDInLlkvg0kVpU0mq6sAFactVtKNIQKF
oc/lySRdk+xhTjey3eZkGHfzNYzC4Uyq2RtToFkhPn9lkTmM497kyIzrm/GvCrKcAKWc4oKy
5k1Wra0pIDhoWhdgqv00TjSUUnOiSBwRMIgAcpe3IBlGuS0uhgDwChtbNUgwrVsmjde6NKuP
8At2A52DszLCOf0VaRMswM/rsNQl6va3GrI+7cc2AHiifP/YouoV2Qwm9TTMvptCrIVJY4i3
DNroQIMK1O/06JR0LCAG7BU8Wuo5YG8I3uWpsbtTtPwM7yCeIW7OC8yb+t1etGqqG9wpb6vM
mF4Bp4IuRzawq2439GIN6sr7nungiJINsp0dQOmZIISg3Nug/O5VOf/ip3ZWcXRfTwG/628X
7yJU+Aa/i2q8HtSwMJzoFYegCIS+/y6SHbuse1vfUwqj77HLM/1Tjv1ZxjOTM8fKlutKJI7l
2f5rHlwaR7SkeBRo2+2t6dXcYheVrCo4QdgJfojqA7SiWYSpaY7UFGItryj17EwzTCa7HPmj
1y/EbuLdEjZ0XgE6JwBZTFHudkd4VRdVprS77Hm3m9RfwXFZx/Ikp9h5w46jn7JnJNzHbDoQ
CD+DMge1rNFKqCb7cfyaZYIg6mSfP6/0ItzBMHxNNfdyQhk1ghbr4bDE2zqUCTJbUBYdda9V
2oV+pba8UwjBE8H44qOPK3OjYb7hq7Jp+SBJWMfChYcYFDS56wGuXdcdOOlL3NU1f0uWhvGo
iLMH8rnMqDCo3IHZ3LDSBDjVSAW+XQGNDfj2kySeOOUAcquDkhEW9cSU7CRcAP+G/NUZi64/
P2X7KFkwsBhLuDSMuuKLY9De055yOXgJyhnlNozzPFQLU9xRgZaA/IdA9ZIv4enlFA6/YpwT
JSp8C7+jIO73cfxyznILiB50BVtIxwMh/GmBG5MCL5RZNOedf3QEYf4rGQKyCy0FEJe0BFHy
3Q9qmYuAJLu+5jouSMRCupP7voDQFqSHkRpwbm6B5se6kScDy9YBxBdrYHk+rLldHcHwmbvI
jKZKAVEyPCqjqDAjRr5HYzK6TAgpHPNIbesrWcf3Tzn58mm3NwUYtXDXG8pkv5DPei1U8lla
zCyhCp2FJ0cqp7l34WKbA/9jIeDrRQd+k9ZE2Y2Y93Oiu74WIkXq4FmGqq07JChrwVL31B0m
RO0cXXeAw4ZmziMxNMl3oNCsCvdQ5rQx6r04C84COaSSeUxp15QTa/XEF136Zuq0YU8ajGYJ
V0OuDpMrhWCXDeK2109B2EJtp6kzRQbENGw2xtQntCLxYYRdLVBz9dhyNvMEANeMhTYw9erD
mM3sBnvAo7g38hU0239ubNZtI+Ucl178DOt87WkHuvIWjJWi5YG0nfnKZAjVSMk6ZCBJlobJ
OCmPYpIuyTjlmRgBKjWl7Z3Vzf3bBGR8va7dQnkq/YhqOMahWmSbLQE4jBLItTAqJTXnRysp
bmQ9jpscxQsLDia7B3sMjM18uWLxsJ+j6J2i2wbAfr1EEGa8xc/kfETS99CFziUa2oms25Vv
fcMHmhoaW+DUCwCmjs2DFpg/pBX1S5yD1JhYKmKPz1FQNuxDm4ES6D9FB7WSzGAVDbEVt7MC
xjKdedQgG1jelh4/JaD6pccML12oivtFWxI8v7Ago1BrYXPoqYeF/YIOJo3/Za8TkEYjJFgy
uo2kmZZyLYY2IKBX6CwbpC5U/lrJMYxzCtsW8QgGgykZw8CrXbMA5wy6ay6BeT0gqDoHVCI7
MEu0FzQ7pMNw+gmbiNuCFns6qyuiqQW/viOu8YFoiF7HW5EpWxEPldzRpeGO5BPxmME8KO5+
/SBolXkmsTXtyTfIdm5nsCSciytEbCrq1OnO3bkj3TrB9mPhKQFMZ41DFz6AW3xS0LVQqhXt
cVXICFYnE8W7VUCbr1ZKKNZjkZlhO4HpGt4dMTncnnP907bUSxPRtMj0nDY5JSZxh1gIgpvA
yW5kYkaU4FZ4d2pPwVDctYDaieX9jhjNQYLFQtAUUWS2/fSCzIVP/eTYp2vplsXL6uKFIYtX
V+LwvG8p1E6AVDgiXKr6QdJQaETwx8z/d3piX08imscwo3MopZ1JrJlSDUNEiMopOG62j2eK
uGpYYTcN5QPnIYQG6kX80AYYJmkV4YfPOEYyq4y4UBrUCNuPONCpC+ALZbD5wYOfIECi72e6
IHiw9L/hQAZyMMK5apXFBMj6Cd6K5z+W+eT4bMF51ExQoY5wQ9pfLNpW/epjtv1NFF5fRqKV
Ld6MjyR/2Eo4W3Ke9qYAsRYmTVc5vf79C+x1xVB+sLFavv2tw7qPwgBQrrVVDZKv3BUCMzw9
59voxe83WfLi1XHlVAuuE2W1nDIb/weCtBYwB8k5yzb7Y0pTtUoaqyKWVCXv+F2zNOvFZzUf
pthpEkaOHeOFMtXaZEJci1djHU/d1ppg8cBLq44cdRfB2z7dkdVaKo28EhZb4F3eoPsWJ3kf
aKx9sfgKJ9hzlpe0BFS+Y8m5nSV1rncsO9Uvr5vG1xBlCPzx07+TOLh3EaeDMcm7iOs91YmE
pO9av+IMhR+sE6W3XXVaHf0Ch6ZFJebNrvurV8QJvQTM+KieZ4j8FEMhMrh7oaVM4e36wo7T
2lSgy3GpXAZaeGubafw133crFO9QISoTIAkW365x7gTG58EplA4c1slV9eXERcP0JhyulBJQ
zgQdHFrYBwiW3l9f7K9ydlkVsNYIHWqgr9mvniMEyURgypG5qtc9/3/JU8FXOIlL9pUCIC/D
+wt3vaL6BN7PVeXZNxlTsvJkz064bPLuROsUhpIFuLXw2ffUeZLWzAP/cU7LeXdqk/Om+f0E
slwrLjkBaH3Dqr1JDmBLDXMtjtyINfvY0lCES/gXghSq9MY3Q97d6eXa03IagV6tbkYJ5w3d
ZjpNrGtqjTcORBq7dG8M9r9sEtqrwI+vpvC3ncdfsolLa5aho2vu3Xatg20Tt1dk+f78VFiz
1+ExgqU1oJrogGKJLjZLET0IqU5eLevYnbMV9+rsu/7/5/M/1837YfcfIbTjUgplbmRzdHJl
YW0KZW5kb2JqCgozIDAgb2JqCjI3MjkKZW5kb2JqCgo1IDAgb2JqCjw8L0xlbmd0aCA2IDAg
Ui9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoMSA4MTEyPj4Kc3RyZWFtCnic5VltbBvHmX5n
dyVRsiTSjuIq0TkaeS2fHEui7Dj+iuowEqnIpV1LluKSbuJwRa7ERfixRy5lqYkTob1DXKat
W6QNgqK1/aeH1ri7rJr8sK9NE9ylgO+QfqFAW+BwqH8ETRskuACHHO4KJL533h1SlCyqvqD/
jtTsPvPOM+/nzOzSdgolE1phCVQIJbOG3cEY4OdNALYlOe/wHx/SxxHfwHZ61p7Lfv7Y8TiA
OgzQ8PRcZnH2nTdf2APg+yHOmUibRuqO5+/zAzS3Yn9/GgXDH/11E/bD2N+RzjoLS2A1Yj+N
fV8mnzT6oA9hs42XxqyxYP8newUdaF7APs8ZWXPfT/91EvsvAnT02/mig7ZxaNsbYtwumPaP
j86+iv230L9/QRkDch8jAtZI/f/nn4ab2K7BXdg6tCB0ANx8G9u7on30KI79GuCjQ5jVuxH/
EkDZjffr0PLn9oNprJ21w0/gbfx6nz+iTEOJ913hgOR8F16Al+AaXIdfw+/gRzVYyP8ZfiGw
cpS9rHyRNbO/hGeVIfga+3fU8w7rx+/77BtsGvW8yrKsH64rN9hj6ue111iSbcL+19gZ9h/K
kPYb+A58h/0bXi8rn0D5K8rPlTn1B/A/iqW8DUvKEjwLV6DI9kOxGsz76Mf7AKH7p6OfOjr+
8FgkPDryUOjBI58cfuDwoYMH9t8fHBzo79vZu0Pf3t3ZsTngb9vU0uxramzQVIVBf0QfS3B3
Z8LVdurj4wOirxsoMGoECZejaGw1x+UJovHVzBAyZ9cwQx4zVGWyAB+G4YF+HtG5+5Owzq+y
05MxxF8O63Huvkf4OGFtJ3XasNPTgzN4pDMd5i5L8Ig7Np8uRxJh1Le8qWVUHzVbBvphuWUT
wk2I3D7dXmZ9RxgBpS9yeFkBX5sw66q9ESPlTkzGIuGunp44yWCUdLmNo24T6eKW8Bme48v9
r5e/dDUAM4ndrSk9ZTwac1UDJ5XVSLn8rLt5t7tLD7u7PvdWJ4Zsuv16OOLu1lFZ9GTVAHMb
egM6L38A6Lz+3rurJYaUNPYGPgABRYjVNOF4BQP6hh5ifD09wpfnroZgBjvu0mTM63OY6fo+
hIK7466SECOvV0bufESMLFVGqtMTeo8oVSQh/+bTne7SDB/ox+zTXy/+4Th31Z2JmWRa3A2z
rIfDXt6mY24ojCBkyFgjy0NB5BsJDMISaZiMuUHddjv0EY+AAi5qYE3FaIqc5naMupBIyllu
MBIWfvFIORH2HBS69MnYNbjv5o3lfbzr5ftgH8SFH+7WUSzKzkg5lpp1uxNdKVyfszzW1eOG
4pi+uB4z46JKesDddQPN9ZBFmoWxrWFXyCLypl4fjyldalxUCwV8DC/6yDAOBLBc1BUVHRnm
MdYFFRpakQyBVunBjto7Oi6GVDF1dLyrJ97jfTZwqUv61NDr+mp0BVBQ9cmzU9c1jy0c2sUj
ZrjGwVVKG6SDUtv6fioiF9IwzvCJco5XhtRe3LkoU1ANiUQVO7kLEzymm3pcxzUUmoiJ2ESu
qb7RKT06eTpG1ZZ7suzTo1NlIdUPeiLg5aMu4HIK4cY5uGWfJx3Dk6dcHtP5WDlRNq7eXJrR
eUAvL0ejZTuSEGZjmMKrN//xuS537EtxN5BIs8NCv340VdanYsNdtBiU0emY9OKgXJWkHo+N
kWWdnZ9cDrHzU6dj1wL4wD8/Hfu+wpTRxEg8PoDnsAJL7Iy6pJ3Bl4Im2Bna2nBJvaxdaoJP
wAHxntB0iWEXIPjhh++x4OOP4W3P0B2bezb39mzuWVLhwyUFPgJUAR/iSe+9LTQAhB/5XfBx
//AH0OWj4/7vlz71Su2zjCwyfMeovF3gvekL4im68rhb8/hTNEALFmHvlYeR/z5sNA4BCMIj
KH6YXUPXxWhULVf17K3qFHb3SqyABkckVqETRiTWYDOclrgB2uAJiRvRyoLEPrgTzkvcDH74
tsSbUM/fVd+idsAbErexY/B7idvhXmWf8FJT0Yd25YzEGvQpGcINKG9Rvi6xBjuUi4QbUd6o
/JPEGnDlOuEmkQvl9xJrsF15n7DIT6u6RWINdqr3EG5GL1JqWGIGnep3JUY96usSqzCkXpcY
dar/LXED3K3dLXEjcG2fxD64V5uWuBnu0Z6WuEV7V/uWxJtgqPm8xK0w3nxV4jblxRaQuB2m
W18k3CLy0/quxJif1j8S3oTyLW3bJdagv83zoVX435aQGH1uSxNuFyukrSyxBve2fZNwgPS8
IbHQ8yvCd4g8tysSY57bfYQ7hD/tfRKjP+37Cd+J8o72MxJrMNheILyV+JclFvx/IHwX8X8l
seC/Q7hL1N3fKTHW3e/FuE344x+TGP3xHyPcTfyMxII/T3iHqLv/mxJj3f1/S3iA+G9KjJvK
Tz74KM9VjH763yJM/gdaJUZ5gOreSvzAiMRCPkGY8h9YkBjzH1j6Ht87NLSfH7eShXwxP+vw
0XzBzhcMx8rnBvlDmQw/ac2lnSI/aRbNwryZGpwumDOlZNp0+PGpkXwmtTJ1ZUTIa3kkOGUW
iqiV3z84NLRQHT0+NbBaS40Dp6xc0swJUS5nFMy049iHg8GzZ88OZiv0wWQ+W08edBbt/FzB
sNOLwXi+xLPGIi8VTe6krSKfzaNio8hts5C1HMdM8ZlFHDF55JFjD+FogTp2IZ8qJR1u5fjZ
tIUvKitz8Y7uZUopnOrkecoq2hk0YORSOMtCQhJZ6P0gr9jO5zKLvM/axc3sjJi0oipXIa/r
EdFTVm6OF8yiU7CSIjc11nF6VdcD5ECfhVYcMysSWbDQaip/NpfJG7VG0WfD89QscAw3j6bw
WnLsksNT5ryVNAUnbWbsNQHdTr6FiWIQPg0mzEEBrw4YME1oBkqQhDTJOByHKbyu5jlQYm2Q
gz9sMGOFM4vy1AZMb3yMZM4GPMlQz6uvqm+or+F1uT57Fet7KN0LQ/jdT+MWsguQx99UebQu
5owiKoBNVxGfhSgHgzjyEGTwy+EkyubQhoOzRM/Eu4nsefJ+sK4nI6gpg4z1rK43p8Kvn4cK
4xTZL0pfOdyPXogYF9aZK2YObOjL+hk4hfccck28Vlg5/Bpk4VY7+LqG+k3yag55Ijf48wQW
8bqxLk6jHPbAIfzuJ00W5drAlkYbWUQ5konZReoVCYk8WBjHerZnKSKOPQNHFomfJIsm2SvQ
SArbDM7LYHOQNVinOmL1P0E2ODGL0u8iZs5alTlhWWQ4S7PSFOF6PotennyvsEQG7sM6ipGz
KLPIvsiBQRFlKGNzxF0gublqbQobKYosj77nZBZMb99STBWvHcpBSmbKQT7HODyv8zRaLz9c
xljJdVFmzItAMGxEszgrSRJR5ayssrDuVSBF2mqtG+RBCT6H3wzx02S/QBxD7oK1q7dfZsqU
K6mSyb9CTSatl0pNztIq4HR9giyLudtRn8hVhqwsEuZUeUvKjDrroY9GvDWWrVYyK2Mz8XQw
6PRIku8GxZZBtKsasahmifZFuhq/t6/rrSKxD7y9kqSsCp3Fqr4KK0nzi7RvTNoBtez+mnWS
RuZZeBCzsFLB9WKdJY2VNbayZ9dbRTOr6iDOSG8dZ6pyQ+q0qivSy3tB5q9Iu2VOjhnVihdr
9B6V1gu02x1ag9vh2KqM1tMq1oJFmupX15bc7ag5TU8nGw7jL6UgzhXfQdS5di0OUuaz/2d+
UO6aPD1nxUpJYz8IcbkaRdXFvivR2eHlwNtLlbpwuba99ZOl6Cq7yzuBK3mL4G+9Y/hkWzkd
KyPe7k9RFpzqmVx7Cq1n16qeKKLCpTVrIUXjNq30xZp1Z9MJ6GlISl3es0HUcW3cYjxDqA9n
7aITPUvrLFXXq9wtmm8/RyvaU6RpTp6F4jQpUDYqp8r6sXvWb/XrgZoMiEgseRaYtDe9p2+B
zp1Fyp3YmyLyvDz914u09uwsVPdkgbLmXR15OnLKqkOngAPe83KeojGregQzg4yNK/TnWt8r
p8rK26h1m2+jHu8Y3sV5Mo+aLHrG1Z95K/dh8qa4wZwKYwzfZTP41PgvnP0HlG30prqaWdFQ
lO+4+duwtsI9Raj+DG98nJ408/Sk34i9mjch61Gip7uoxOIGc9dj19Zio7hW8bRu7Yj2gDaq
7dcOaiHtk1pUO1R/bh32n/4NssIZ+xNZ8cajIjdsD86oz1zhRIljY503iruWdYzOVgs1fLyV
/rFy/TFt3f6+UG/577ZVn9DN6RNXWPDKg1d+dkX97Pie7tPYprCdxDaJ7Si2CWxWeE93DNtn
sJ3C9mlsJ7AdxzaGLYLNf54908kuPHbpMSXQyX4L7JnShdKl0kul10o/K/221MQL7JkCe/wk
C1wMXbQvfvXi5YuvX2zkzw89v/S8GrLZV59m9rmlc5fPuedunGvIP8P8T3U/xZ+68JTmf7L7
yQtPqqF5dkI5oZ7QTjRoiQV7wV1Q/eHucDB8IXwp/FK4EfrEP59u2ewLHfA/+NOtTG+PbG+N
9LREuC/S3Ri5R4tsUyJ/AZG7fZ2+rb4O3xZfILTZ1+5r9bX4fL5Gn+ZTfOCLXm26eTLq+iY+
G1tm7Ctxd0sUotMj14Cxm3/z5d3rfkbYtqjbNRVzX9gWj7p7EcC25a0wIjtD2+K7WcSaGmHR
idiyD+Wjj3r3rQH7yPKBAxGLe/9xk4iHl4fAfln8Ir7L7rSLqz6Od1trvejsxrj/F4mCTx4K
ZW5kc3RyZWFtCmVuZG9iagoKNiAwIG9iagozNTIwCmVuZG9iagoKNyAwIG9iago8PC9UeXBl
L0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0RBQUFBQStUcmVidWNoZXRNUy1Cb2xkCi9GbGFn
cyA0Ci9Gb250QkJveFstMTAwIC0yNjkgMTEyOSA5ODFdL0l0YWxpY0FuZ2xlIDAKL0FzY2Vu
dCA5MzgKL0Rlc2NlbnQgLTIyMgovQ2FwSGVpZ2h0IDk4MAovU3RlbVYgODAKL0ZvbnRGaWxl
MiA1IDAgUj4+CmVuZG9iagoKOCAwIG9iago8PC9MZW5ndGggMjIxL0ZpbHRlci9GbGF0ZURl
Y29kZT4+CnN0cmVhbQp4nF2QQU/EIBCF7/yKOe4eNtCemyZmzSY96BqrP4DCtJLYgUzpof/e
KVZNPEDyeO+DN+hr99hRyPqFo+sxwxjIMy5xZYcw4BRIVTX44PKhyu5mm5QWtt+WjHNHY2wa
pV/FWzJvcHrwccCz0nf2yIEmOL1fe9H9mtInzkgZjGpb8DjKPU82PdsZdaEunRc75O0iyF/g
bUsIddHVdxUXPS7JOmRLE6rGmBaa261VSP6fdxDD6D4sS7KSpDG1KdnjdKf2sX7agFuZpUmZ
vVTYHw+Ev9+TYtqpsr4AfVltdQplbmRzdHJlYW0KZW5kb2JqCgo5IDAgb2JqCjw8L1R5cGUv
Rm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0RBQUFBQStUcmVidWNoZXRNUy1Cb2xk
Ci9GaXJzdENoYXIgMAovTGFzdENoYXIgMQovV2lkdGhzWzUwMCAzMDEgXQovRm9udERlc2Ny
aXB0b3IgNyAwIFIKL1RvVW5pY29kZSA4IDAgUgo+PgplbmRvYmoKCjEwIDAgb2JqCjw8L0xl
bmd0aCAxMSAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aDEgMzAyMDg+PgpzdHJlYW0K
eJzsvXl8FEXaAFxVffdMz/QcmTuZTiaZJEwgkIQjGE0jl4rchwSJEEmAcOUggChK8ABEFNZd
7wO87yWEgOHYhVVW14OFXa932VVYRVfdRXl3WVbFzHxPVc9AcI/vfX/ff9/vpVNdT1VX1/HU
c1ZVD22tyxqQHbUjDplzFtc1Fw3tZyCE3kYIu+csbzPsH+ccBxiCOGVu87zF9z869CqE5AqE
hK/mLVo5d8h3m6G8Ix+hyyfMb6ir/7DlIwdCV7VBHYPmQ0Z78mYJ0i9COn/+4rbrSjx7OiB9
BNIHFzXNqfvolze9hND0n0C6fnHddc3rBYmH9DeQNpbULW5Y63mmGqGaAEIuublpKdTLwaMF
tI9Gc2tD8/UzPhoDaRMh288hD8NF/9kBFGmacLwgSrKi2uyaw6m73B5vls8fCIbCkeycqJGb
F8sviBcWFfdJlPTtV9of/f/tn7AHBSGEhGdQkI8jwGPqTxA+p3GyMfU5fU5j8iUU7k4HhJ5F
L+FG9BLaj17Bp+CtbWg36kK/Qn40Aj2MVqGfoHVIRDMg53Y0CS4B8n+Cg6kuVIoegyl6DB2C
slehm9Ae5MOB1BdoNbqNewfeug1pKA8NQxNQE7oTX5lahmaiY/wtaDC6Ei1Bzbg9NT11V+ru
1JPoKbSb+1WqB9lQCM2B61DqK+G/Un9AfeGNe9AD6Bi+W9mJTGilHUo+glrRg1wtj1PzUt9B
D3LRCugDj8aiQ/gASUDtDehPOIBXccOhlidSHamDUCqCatF89CDagwfi0SRXmJkamzqEfNDG
dVDrA6gT7YKrG/0MHcV24VTqydQpFEQl6HIYTxf6NT7AJXvWJKspogFLxagSnjShn6PX0REc
w78gTYJdKBNM4frUu8iLBqCp0Ntn4M3P8D/ITXCt5l7jR6UuRQ7Ay48ottEv0R9xCJfi8Xga
KSZN5FGuFcnQ4gC46lEj4Pt+qP0jnMC7iJ0c5p7gX+DPitnJ4ykHzEgcPYQeQb/AGozUwEvx
zfh9/AkZTmaRh8jH3E/45/jfSnUw6mvQYnQnegH9A7vxEDwRX43n41V4Hf4RfgAfwkfw52QY
mUIWkq+5+VwL9zP+Urgm80v5W4S1wh3i58npyYPJ3yT/kSpLrUUTgR7WQO/vQY/CyHajw+h3
cB1DH2MB27ADLgPn4qn4Brhuwnfix/Gz+DncBa0cwR/jL/Bf8d/xWYLgEkmY5JI8uGKklawg
PyEPk8NwHSF/Id9yfi6PS3ADuSquhmuCXq3jNsO1k/sjH+IP8ynAc5lwr7BFeFZ4QXhFOCXa
pZtlJL/9/RM9fXo+SqLk+uS9yc5kV+qPKAvmMARYiKIq6H0dXAtgvu8FituG3sF2wF0I98GX
4CsBM7PwAtyCrwNM3oofxE+xvv8U7wMsfYC/hj5rJML63I8MJJeS8XBdQxpIC9lM7iZd5H3y
HSdxNs7JZXF9uNFcLdfAtXEruXu5Du5t7kPuY+4M9z1cKV7lo3weH+cT/Gh+Fr+Mf5T/E/8n
YabwlvCpqIqLxbVit/jf0iDpEmmCNFGqlTZJu6R35dlAna+inejl3jyPj3NruJHcTnQXKeeD
5Nfk10DPs1A9N5YApZJn8XpyI+4i+cJ14kXkIjwOneLjgOvXyBZyhlzEjcVj8GS0gAywahO9
/PMQVfGvopP8Phjbr6Hm60Q7vol8LdpRJ0akEtr8JdefT3BvoaPcMSzxj6Hf8yr245PkGW4C
UMHP+EuE6SiXexj9lGvBN6KdZCRC6ll5I9DxOPw8yIUpuAx/w6UQR8YBFQ3mPkG3oIXkv9BJ
4OP16D5cz89Dd6FyvAr9CT0NXFEsLBH7iFn4DdLIbyAe3IUI/xyMrhLnY07woltxLfeg+DX5
HVqGDvMq+oh7EXp/mPyUG8ufEibh+cABN6K1qCW1Bq0UpvO/xfMQh6ehAv44SLdVXBmfC/Fq
kCozQabtAu7eA3JgGDcWcgJAOVcCXUwFCfEgXPeDnOCBghqBx68CKfZr1CVOId1onuDAIHUQ
4t9KTkIzUk+jB1Lz0JLU3agvyIN1qVVQ47PoU7QJPYtvS96AmlEOcM5H+EphFDksjEr1JRvI
78hkcu+F8wvYLsAB9CVcP4XEJcJetIH/AE1G1amNqfeAuotAwj6ArkVXoBMwyq+ghcu4A6g8
OY5sT43immG8x9DE1DOpKFbR/NQiNB7tQ09JAqqTEjDHHfi3MN4bUAOZlGrjGpKNgIdNgAUT
sLUM5M/t5vCpU4aZ1ZdcXHXR0MohgwdWlJcN6F/ar29Jok9xUWG8ID+Wl2tEc7Ij4VAw4Pdl
eT1ul+50aHabqsiSKPAcwahkZGzUbKMjPruDj8cuu6wvTcfqIKOuV8bsDgOyRl1YpsOYzYoZ
F5Y0oeTcH5Q0rZLmuZJYN6pQVd8SY2TM6Dg0ImZ04xkTpwN854hYjdFxksFjGbyZwRrAubnw
gjEyMH+E0YFnGyM7Ri2fv2Hk7BFQ3XabOjw2vEHtW4K2qzYAbQB1+GPN27H/EswA4h85dDtB
sgad6gjFRozsCMZG0B50cAUj6+o7JkycPnJEODe3pm9JBx4+J3ZtB4pd2uFMsCJoOGumQxze
IbFmjEY6GnSHsb3kwIaN3Tq6dnbCXh+rr5s5vYOrq6FtuBLQ7ogO//UnAueTULl7+PR1vZ+G
uQ0jA40GTW7YsM7o2Dpxeu+nufReUwN1wLukYNTsDaOg6Y2AxDGTDWiN3FYzvQPfBk0adCR0
VNb4GmIjac7sBUaHErs0Nn/DgtkwNaENHWjSytzOUMjcnTqOQiONDVOmx3I7qsOxmroRke1e
tGHSyh1B0whe+KRvyXbdZSF2u8OZBuxab6Dh3DMGseIUGjPpHGYx7VHsciCIDmOOAT2ZHoMx
DaG3hiFow5whUAz+1WB4q6MeZqSxQxk+e4M+lObT9zuEAj1mbPg7AgqInfzLhTl16RyxQP87
oiClk3OkBs8zcEci0dGnDyURaTjMKfTxEpYe2LdkeTeJxZp1AyJAH5oAuK2rGVoK6M/NpRN8
R7eJroVER/vE6VbaQNeGO5FZmqjpILPpkwOZJ1lT6ZP2zJNzr8+OASV3MRM5q0OOn/tz6j7P
yPlDO7DvPzxusJ6PmRwbM3HGdGPkhtlp3I6ZckHKej7k3LM01OEZPp0LkzREwhx7CkQ581xh
mphu7+AL4E9kRF3fLclAlSwHG6M69NmXWfcaNTf3f/hSd+oUfYtF519Ld7NjaOLC9EUXpC/o
nn0DBx0GVTlmyowNG9QLngGpWQ1eno6A4tGU6bnG8A40FTizAP66UweG0FAT7jABZcNpAaA/
KyudvKBgOA3XwD9KnX1LRoGg27BhVMwYtWH2hrruVPu1MUOPbdhNXiGvbGgeOTtDON2pPXeE
O0ZtrAFczcdDgSkIunR7DK+fuN3E6yfPmL5bB/9p/ZTpnQST4bMvraGIJMOnTO89e4wlavoC
NRDMDFyBOl/gzeW6cl0FcMOg9L43uAPfmwI6iwz+APW/wIXi94BXIYGe0ASSA8IeMaGvdJOl
Owwe890YvywamJRymAN4J8YGvNed+ty06TqZimSnE+7dqb922e0M+LhL0xjwPeSIFEhCDgWg
RnnXA4GEfibB/tVW6ach9Jyo/Uyv0qtQdXVVT9WA/tDXgblZuS7iSWbzG5JhQXvppe/+Rnu7
DoZEfSAvrtuNfKkDO7L8FVx36rjpoA0U8APBjtqj8SxrqD9Y4ZdddpeXEzByRgTJa1PtBYpZ
PqgipeADCvaZNhuZ6jPpMJQidvc6HHDvTv3FdNFBKDwdkxKi5SD3DLxgE6GUros0/Y1po+0q
qtPJ0md20QEr43xABqa/YlBFh++UjzT7tvo6fCkf7yPeAoq5A6YOfThFOddAR9BxmJfu1Hdd
DJsAmH7aCcSaRjJtGvG0WfbMR5tChCGWMKyOyxo94TxKAaktCcCiDtHpRK9/kD6JqquqT1a7
Kl2V2F05oP/wlaZDdEgFDtEexprsDGOUwInEGpSohbjcVe4aVF7m82W5Yq6KeCxPFLNc67pu
OrD8p2O6li2ccGeVsKfnr3fXPvlwzyzy2LobJt91Y89ecAvWw0TBI0Z7h8xrlEF0BOOVzcpW
pUM5oBxTTikSUqJKs9KubElnHVdSihpVMAJblHCKyN2EkSiIvCpKBQLit/Bb+Q7+AH+cFw/w
p3iCeIM/AimehzlgeOPP4Y1neONV2irvpXiDZ1920RnjM5QIwPemSnHIj5N/iL1WwB6lxOqT
2OWurKRhQH9c29qS8Awsz+IAK+u7urr4Px8+fDaLj589SumyOvU5t52/BPXn/OYNfJ43b6hy
hTIif1peQ94q5S7l1vynPS+UvMJpij8U8PcfU/K+XwiTqYToZVgNzJRnKjPVmbaZ9pnaAnmB
skBdYFtgX6B1xbsKnYXx/ML84kH5M9QaW328vqgt1pbfnv9j9WH73UX3ldzT/0n1OfsThU8W
7Yj/Mu4r6k6dZgPMywCxDJCfAVgZOvS8DBDLAPkZILs79ZHpzqmcIRcW2FU+ZMSzeFu/7FA3
ed7MC5ZQ1EaD1cHxwVnBbcHDQdEZjAabgseCfDS4KUiCPwOKzQIx9DzCQOteWlzHJiY6eJAE
YR0TDEyww+urwIwZHK4KjPvNzF6UTbIjWRJPu8Gmrzv1WWbiPjM9lPL5SD9bNIRD+UHTE6go
o6+XUvkTDFh3yrRBH6WAoEHfDBr0raBORxX00fEHu8nVnVJ+H3h1Z6TySB/ch7ZC3wDg8y5a
DQPoGwB8uYu+1CfEmsot7FMxu+xAGakuay8jZTrGOB+xNpHOeNGwsEymMoB2gAJmkHbCyHfq
dFRO1j2nQYs5KdkatE2ngzbotNNqnHnHEK4GM5+g4ICKwYHEOBCTLWPT7HwSgg5R6zjK44xw
WxJjT55n9pOtqJoWqj7Z4q4sZSSdOKH3sAioGf6AsP0W/5uFfXNigrck7tLdukfnxDzNCCOl
SApjoS/ccryQzHXEwigvptnlYjWMiwoVVUzwYRTVs6nESFDRbd0wbb5PYs0aECHnGYryTq1n
sM9XXjZoYEVhvBB874pBgwcx4eKX4lS0ZHn9PrhySJZXFGN58epO5+03rLpuYMGPX3tg/LAh
fX40+cafzXB12Jc2rlrg85WGb91/37TG1248/Dt8cWRha8OIi2OBgrLL14wbvbIomrjshnmB
STMnDY5Fsj1qfvmwVTNnbKFLmiTVA3qxhmk7B563CzucIDoIVV1p4BvGIoTOWQ0T5XZ6F9i9
VO+vz5PnK7P19dxm/Q3hNfGAfkq3yUINnkYm6PNtHfrf7H/T/uYApcFrvIMD90kAaaQ5ZFGS
7ADLol0CmU/1hpMJd0Oye+ER4Tial0XzOIO3e+EtJUcQ5ByRE7tJs6kg2f6FCbqf7ME2hLHN
dNsN1CBxkybwh/ljPLfZ0tOmbYL9gHTMzm22YztN607psERWS+0SkX7sfP8DkHRASUEI8Bc4
qZ8MBfWTJ1Gguip0svpElX4S/tYJ/RKJG/WD6/oFWGxJwcrKdfrBg46DB9cJVgwycUyHbfKY
jhwwQLp4JydLe1KnEEp9MwT+1WCYc4sAYrgcx7hczpPLxQtFiSPlvyHTP3yh56HHfof/+4FR
eZFyYc93o/C+5AgyA9+7e8Wdd8BMoUuTE7kvQaLmoD64yZxtswGR2gq8V9pGekUlO5hdYot7
S2KVtkHeK2yjvNOk6bb5tu/Uv2c5+sVKCi+JXVJ4ZeHmkq0l0qDcQcXVJaNso3JHFk/JnVLc
KM3JnVM8u6S95Gjh57lfxb4udPl9YlY32d5VFPFImIo43QCzaDa49+3oAOhnCQyXG80yIRJx
qiPzInbVl1VeUK4WBAJH/Fj3m/7Z/nY/X2LaYPpKTMrWfjfVSX5KRi7K3H6Raia/jz0DmWKZ
EbSUSNNfMWHjp0rpCkp//jYnLkB50fz9zsPOY86Uk486q53jnZzTYAIkxARIHhMgEVpTWmyE
mAgJJkracitAqSXGnc6wIIiHk3pPb2OAWl1nQM+dPFF9sqf2BI2rqJprQbUtfsqLwKyDBxUC
LwKzuoFV/QPLXRZverwWJ1O+nbvNVja87cb1AQde3vH7U0t+c+e+659u+P3Wn3/5wNM3rnr2
peuve3Z6aGJBWf2MwR134KoP78d44/3t3y/45vB1L3B9fnNg/9uvvvYq1aC3waS/BvPtQm+Y
F5V6sM7jGF/BD+cn83P5Nl5UXLIiK5rHpWiIk7EtIkpYRKpStFnGcp7hwR6S5/r31tU3Gevq
G9PVy7oSmXVFLVU6FYhOmGVgiczAki0Dyz364D8ZWCf02tOtJ8BOqD7pYuzB2ATpb6xz3Ai8
gWpbcS1YUFlUyoGMA1RJYD7d9vgljdVXX3PJpZdedI03h48/1nLZ0GcKR1fPbu15l1L9mNTn
fA5gIQtl48mmP4oiWSASaoVaZaqtgVsoNCkNNjmrO3WCySkXAOYkCmVH6L3Q/TvhO++ZED/A
PTQ4IDLMPTY0LDLRPTM4KVLnXhyqi1wnXpd1hpwJ6MiHnZrfP8E329fs43wR52Z9q050nQ9H
VAntsTQ3Q5mloSl2qLa7xxPhbX5T6079gak5jRIvbVqjNhbFmUbLK6AnOzSshaJUzxfEK2hs
DsuJVfSP4qivXM+XzPw+FVGpWhovcRKjailAZ0SK0GolB6VqKUIrlJjWloI5aUWYnoPE2J4T
4/SWROJMC02PBdsW6DiRAEoGpVdb1dNSxWbEzYw3RGURbmnFfkrByKWj8jLk8kq5TCnh3Hgh
nSHumj0lX+3+Ivk19v7hPezA33+udt42Z2PPUTLRPmTa7auew9P8T3ThKOawHRclP0p+qxvb
9szH96wdPv9pyzsR4zB7Mfz6bqSl7S05Y3iBf/Bf5libVlHAn+BPKH/0f2oI7wlnDOKXjZgS
CBsKx8VyImIWZWkg7hjIZvVIAd5csLWAFPj9IUfBZhd28XRWXMzccVE/xUbJ2eWlyHNRp8xP
kekiFIEuO503l0gp2kU9DIpPV0bLubpxrWkPFGwO4zCrLnyuujCrDtJfmS5aXZj5H2GVVge5
ScvtCdtpxeGMnxem9fkQKY8V4CMIb0ZbEYkiasZw1AU0sxnf6Za1xLjPzrjPl/ZtevGgl/Eg
M9AR8+xQML+gG1+3I3d0b7mWNteBEvReOb0soURtz7iRDSM+awGLqKqqCoz6sTooPZefcWvG
BbJ7PXGv3RXGbi0r4wKlSSbDwT4/vVmOEDNXertEj5U9vWD5fdGb3nz0+R2xmZc0/6Rrev2V
a4by8XvGzbp2+p5tu3oKySOLZg2958me+0jndddNePBHPb/LeLOfAb348I2mR+BED3lW79Y/
4f7kOcWd8Yhg9Z4yq4BgVur4fv1I4HggFeAN2evw+tzgzWLRp6maw+7IDzAPNsC8WRvzY23M
j7Wd82NtTNzZ8lgJimGmgGzMj4X0t9aE2pgfa6N+rpvi3sZcZRuGP9u4AGXhEPVpA6cCpDmw
NdAROBDgA6DPs3xM8J7pcrksD/Zfu7LqD1xZVy9XlrcWCKAJ9w+F9zi/fqa25fycgnt2mrm3
F+RSu5ctIVQxiZzxb32iS1FlVVI5UY+7REcYO1V3epL7rKHqDkiIzTIzRi+Y4nWPL/tw9mMT
dLWrz8LLlj7Dx+/bNrJ5bNmNPUvJ2iWLh939ds8+Oov5qb+SPsIDyI/+azdSQd7F4hUKk3cA
tAfBp7VrKuaQT1cSTlX0RTibU89DeVhzF9hxSpJHKiNnS81go22WeCQZ0lapQzogHZFEiUpX
ikqJyhDKohK1VSlKJYuL0wCTnBbeRQqcMm0UtxLTYhL1ZpgM3UMWoAAetH1ub20G4z99Agy/
nir9xGlqENA1GBcwh6u8XH+DCs9EosBP9X58oCsGRsBgwFbM5aWSk+ihK6uuXVRy6607du70
JIpyHtuiX9LwOJmzEUuLkndu7Pnx2JIQ1WujwD8+Bna3C/TaVPNJlfBagVahjdCEgd6BkavI
FHWSd3JkHqkXGpQ53tmRA9F3hfc8HwY/9Xzq/dr/5+Cn2cejqagvGk2EqnxVoTGh5ujmqNSP
5Gv9fEPJQG0MGamN8l4euUqdps3TPhX/5PsOn3boOItz2HQnCkdskgupWYD6QDlGBS5nga4f
cWHdZbpmu9pdfJTxTpQZby5mvLnOGW8uZry5mJsHuX+1eMflYLI1Y7xRqWpeysRqmzt/P1jd
x6SUxGc0XE4vDZfDps3ONByz2yRmt1ENN6G3hgOj7QcWG5hwVSfYDNHgop4ctTRwSy1qyR1o
TRGz1Xx+V7kL9zLTuCENB1e/t2zBu7fMvrd0R4/x4rLlTz17w3WPrX1049kntmBuw8RhxPHd
KOJ++81fvHb07YN0zkaALVII0klDQbxwV1aAdtWToSUnVTVLmT/NHrglNWgfLV4mTxNr5Hli
oyxX6EPdQ30DAyP1Me4xvpGBmcJMZZJe6671TQosFhYr9fpi92JffWAFzlJEQbuamyJMUa+2
L+IahAZ1kV31R3jJBarQmx9m0xJmUyRR65lNi8QmRNLTuae6GEIpwHBKAcYDFEizwQHTk19Q
0R98MEkHPuOkAcdA99H8y6lpArAjH9kddDnTzdSUncmtCJNbzCRJayOmV5GPSS4TqqRqjqAB
IWqigLA6L5HAQKk9U3s+gy7Bnaw+CVxF52z4zOmmMlmYrFwrXKvwuLaGec0efTBMIbIcYdTb
2B7x5O2//D323fDnO44lT+7uXLe2c8dt6zqJBxfetTz5x55Df74Z52Dt7bfe/s0v33oTOrQu
2cjnwgy6UQ6+1rzLrvfVL9bH6Hy10WGQqFFsj2WXZZVlX5rdbGw25KH+oeEr/FeEa+Sr7TP9
M8ML5IX2Rn2xf2H4gPGO98PAh6F3ck54T+QcN1KGL8Yn9ETWQH6oPoq/Qp+hf2r7c3ZSt7kc
YEwy09wXcdiQI5h/RMW6aqqz1XaVN9gUGmw6VbqkY6MTqQbS6e+YHFMpS1Fcq5bQY8DnZowi
W23DnnJS7i5A6ADGm/FW3IFPYT6Kq/F4MMqoA8WsDMysDMysDMwoBDN+w1RJ0bljRZmlj5lv
D6of5hUHo6MHB/B5HswYGHoPiMie81kwizCNVM+kORBKoRZPxljwZXkJ5cZCF9dr9tY9OfTu
+euPLFh27IYZm/q5nl5+3QvPtC3dnmwUfrZh4sSNqfufSJ6948qhPWe5Jw8dfOu9t978gGqX
CSA5T8IchvCM7YQu+ZsVjtVO7LRhE00AF5VDvBukWwDscuzIkmSmHOyWiGHixmKQUtrxQ+++
xshPP1hbRsOA/mFztGLH0chwz3D/ZM9k/2zPbP9D5CHuQe1J/cmQXdaC6gLSyC0QltmbtXbt
aftOZZe602732dfaPyGcI2+Ws8m5GhxT5jev7I9op6jnTK2/4+gUUpDTaUPn+xiBruc7mF/l
yAtT7WlLRDHoSLp4QWfIZNNzGZuUEJuUyyNZ+YclTEUpSTsGzBCVmI0iDQhXZLwzmBhLr9W2
pjdGdlM/ZkjNydbT1qoYcw5claV6LfhvJ+jUtcDc1WTcgrTwzCxJ0bnjqrZnf/3To8l/tH5x
+0t/iG4Lrp6x/vknb11wF77N//JhnI3VFzFZs+2x8MJFr77z/is3U8l5BUjOCMxZERpM+pol
iqb0CWqhPsVanz6V2qCsweGhfS7vU6vV9lmgNfaZ3X+Dtrb4Qd9Doee0rCIqX+kQCynNByn0
dPD5ol3BvUUHg4eLfpv1YZE8wodzmHKiw3e7zy9QDaS7HlMpFPVHA4mSPhWVfGXJ5fxlJdPk
msRcuTGx3L7O/ob9W+3bhGtwhQPzeml+hb8s1xuYVdxUTIojpY5qxybHFkfKIWxxbHN87eAc
dsqiDmsFnQGnzSyKfQdTXQ7mWzgcEc4PBLArcI83EpGYCc90GhpZqJaB0i2u0+uQyERqQW4+
WKWssnzmb9DcfGYg5lO/llJrvrUAzBak/0B3mQBiDeVnfI38bnK16Sg0UVyPG/H+8W1xoRLk
ODON4t2p93cxYADNMzUq2ysPVJKtlbiSrckMY+suBYG80vz94mGRRMVqkYgOOlKRsY7INLXI
/BORSQ6RCX6RrSOLA4acM5+A5E6fTKQXYnu5HlU9iU8/pQR3IgF+KV12Lc2Ub7HWYDOLsMzP
AN8UItRSwBZYBlYMGjSYXXS5lC4dFF5C0vYpUKU/FudEyUEsAoVCXFX97gXb9o1eetnAhUfn
4fKR61evzO4ILDly+/rnJ+iKP29fxH/twaaZZYsb5z8ez75l6qgXbhu3ZpzXoYXyC9QlfS+u
aQm03DHGrLui33Wnzt528RD8YVFELxpbetnsq8dfvAK49PnkR/gWdAipaNxOlUPSC2I3nmDG
MVdFCFZxFVIJBwkkDpGGjkezUBNaDQJAQFttj93P1hyZiUnNc3qnhgzbXBnQv3xgOSg6qRAG
vOvQhKvKKgdxhw613BEfG6y7Gtq9BaTfcXoOEo/fjUJ0ZSHLX0EMj6/CSa3ccre3IuHB+bLH
Z8cen01EqgvIDZX7CgJ+6ryEmGfkZz6R380W4c4RnZ8Rnf+cN+T3ppfj0rt6fube+qk3pNFp
T/nxAT/2jwtRosqijlDoVIg0h7aGOkKpEB+yFyjnFp8UjBRDOaIcV3gls/iknFt8Su8qqmwv
kdbPNJHCPCGFbeop44IXbEvRzbt/dnmqepg1WF1lrT4xhyfE6w7NqRFRkkVZkMHt4e1hpMmu
MKJOT58+a0Bdwbtpe7EQjPpyl9fP1kEGUZirXvXeNU+M121dNteSiRPvuqjr4a7LFo8fuJTc
3bPjzgGjJ07etJ5Unj0Ks5ObnMh9BbMTwv9I66Zs1evkbFwk6HSLNtFjup2GzbQbTra+4AyW
JkIfhgKHQkGdRmzxjPFAeIczgp1002lxpLLIO825TeVMzXQSp1HUv0KnN8muuH1awF1oK7QX
aoPsg7SBjgdctiJ3kecyX427xlOT1ehu9DRmrRSXaytd13uvz7pN2+Da6N7oud17v/qsbZ++
17XH+6X6J+/ftR79W28qkuPeLrJe+zy2SJh3jnDeCposeK771uKeu7KWLSSFzcFOp113ud0q
4oJej6fArXoh4bQ7XfYCm+q12VQPFcc2kVaAInqElEb2R0ikm1TvdAIuTG83mWLaqt2mm8xy
73cTdze+dJcT56GRYZU+YtgyDXt/+3g7N8GeshM7lNhRCjoT6ugKG6vAcwPk9dDV+1CALd4H
9NMngvoJkCuhgH6SQShA3QO6IUOX8mW6lC/0CyQcACAYyTqHXlUlHxzT4Zg8piMASnIvsqc+
R7bU53jIkJoasE3BLt2NvKmPdg2uVPMGV4LQ/3xnVqUrL6uSUl0NpUEE8goMVk+hJYLgwuUe
n3/QYE85FiUqxVZ7Lyqpuszvigu25OJXPkzkRROfdCUXDcvvv2paRXLec3pRfnihM5sv6nlg
2ZpVy8nCs7/admnNZGrzeECJtgvvID/WzByvgoFwgv2DZrA5+JD9Ye05TQ5pRVpH8ECQD1KO
KwpFK7JljbM7IyrOIgmvh+dAEmzxYm/KY/L+Ah5x5G7M1oZ3DBhSwZYZEpFoxWaEgybbNzQ1
ukzhZcsWRew8Qx5buChJn2QAp4+5At704sWXmbWqz5iFSpczXmYK74lAcB/eg3LRGayiQCJx
phe7goSv0k/DtJzUT56spVvMVeBqV5+sdFms69VdoiKJMugiXXGHkUt0hjHl2TVrcAL8hdZy
6n8PrBh8fk05K4v64p1btnhCtyy/cmZ4SNmkEYcPcw9ubFlYMeoq9yPqqNnXbvx+LpWkgNjB
bFf+k10C25IXKDoGD6lgccVAK+4/wIrzClhsFoC8dQpRYYtwTODHw+2UwEWFZqFdSAk8RlTu
W4vutCaG2Czo4RaED4DxR/7lCvx36ZXA3otCFl7lNFIzx0VSqcwBkvRuPRrHX7hbz/Y2E9aG
Pdu9aLWy6dmFW7rovhK1x9aCPRaFsesoG7ebD2HB7swXBgojBaE62hEl0WhepDxyaYSuKYhD
PXSB4UrflaFauVab7qz1XRNaIC/S5juX+JaEDkR/Zz/qPxr82PMX/1+Cn7BViaAhlDpLvf2F
aqcpXOmcIMwVjmb/nf9Ot+tZDl4kKEwdIjULHKJA/hEb+COmbbat3cZbyw02ZmHZmBNEl96Y
E2TLOLS2jBMEwHGGDbZ8V8qW69qwqzyNRmv9rJwrIORfe0bJzGp+xkWy93KR3Be4SN/80EUK
MGvca7lIOaN7r8P3dpESiR86SdRHqj6/TsG8pNyYda4kh2TpKJZXyHn9530k3PeZrtbt125r
MZN//dm+haRi6o+Wv/jUsuUvCnt6/r5p/KY3lya/Tr7/CL53/9Q7Dr115LVDQNl7gLLXgW3C
oQIzQKgpUmUZINsQvxWeb+WZDQJuOO2RZXLsOXToEJU0++G2hnHF2zsxQTJhxD/kYosJyius
uG9/Ky4qtuKYxRw7snOsOBCymKWPplcYwmZhm8BxBjDHJrCBOhBfyryiY8AQgtuAzM2IY8WZ
FYICabb4S1f6HNVXmeNTZ0xrmdxgzPE4/35Nr5NTIKM728Ftqq2hB1bOrTBYjEDJf/8rjPwx
eCGIexe0tANvMzV3N3lDJm5c5vZXyN2pX5sKAPiSnFyaesW8AoBiUqSU6mArq5fjUWSUfLky
Xp+Jp5Ap8gxlgr4IzyFz5AXKDbhNvkG5A98m3658i0+TcFCO42I5oVTKT8kfYEmHEb6sZ1WQ
Encl2DjvmjF3JSZDFZXIqlqAiRdjgunWOKkTEqAw1DoNaZS0FTpaLeFQSTd2dsmyJIh7ydUI
IYluzjH3L0/b6sDIYTpmO9odpxwC80ry6SNHG1JvwngbwuOBBFIwrwGGvKBTb8tdddDaO6ht
YdsAPRQ4kWASWe+hRyaq9E+rq3o+ZQRLVee6Gw/qjoMJECyAWRDAFMGA953FOC7TIywW9mSK
S0i98jLFIkUlsiz6GlzLNKmc+qjTSZGQjj5/OVypyL7wxQCf6vRXMsNQ9VUSL4SQrzIzlzXl
A7EYo0fhsDSoPDeriDy5dHpyPFff84umlQvwn+/mZPHuFT3X3KA8RGk5RM/GwTyr+Mu0NeYX
ZKTKIhZVJCiygImQT2lMKE18eEj/8JCrvJyaOJQ5wy8PFDDKc1Wq1AjTXJWKzx2pkOmNgLbb
ATFOxyrdxlLoKIvgxtZmFNAWyAc3SB01byrqV4EMuDntxahIiauVaKB6GRqtTsPTSI08XZmL
55JGuVG5Dq3AK8hK+TplhboOryNrudul9fIG5RF0v/Ij9UX0uPoz9LK0XX0D/VI9it5T/4I+
Uc+i02oJDEcNIJ9ahOLqYHU8MlVFMN2+CgFYqiJt0ykwHjp0RJeRTCeVXSpiPivFBc1jSz4U
KyyXCILdRt20DxOAGwiHEocSqLS6mgkvMP5USZYLFNWrKGD/EQJaD0gYOqIiVZFlcINESVU4
hIVSO7bnyaZpKu0KUbpxeKcJ6hIkCw6bikFMnGf78reUk8F+66ntqQVD7kSttVVZiSy7jS7u
pgmQnsKACMwylPYSz/9DtTW5580u/NPkop+fKADP/y+7k0v4eM+t85qmLCfrrRNqDyMkUB2o
4Bu3u21U/KierAo5YPeRqRydxFwKyQQklyR7JUkmEsfJCk+IIsk8Z4iikJFRArOHqJAS3FRA
QfofZojymVBr2LBhmwD6rRk0nGCTFcPaktegMXps1EhLuzMZaXcmI+2+S5tYmf2hf2R0P/AG
m7Za9aKa3i5R+pQjU0TAwGzrp4r51ZWV63iGPIsWdiMudfxlu6tCNuAGaARkAi4pK3fJ5qhK
GP6BXaMqZbPMAssqpbxgJdD9R7uCAJZZIM2NMdC0xSolhxeCh6ZP7/IAmG2B2QBmUfCb7VkZ
Rsbp2bJ42lUOWtsVw66HX+fInte/Twp7zq7hV383im8/205n6nGEeHrG1YbuMbNEIQdEoIQ4
Podgoio5NiSzlexs3V0hTeGuMFRDI2pI4wHT/y8IzpzP/S6D2VMZzNovurr3zkPV2J6qcaAw
x54+kUB0O4gGYA2KZapc6NlcKzzO53//KJf4/j3uVmHPS8nqF5PaS3QMc1N/EpaDBZ+N3tk5
hyzIptLSWthiB4dnUchAZdoc1IzastvRrdmb0YPCC9xT2m6uS3tdO4JOZP8t2+VwZ7uys7k+
YpGrT8SIjtamea/KmhacLyzMvsF9h/tB7gHHg5Fn8ZPkWdd7Dg/yopDu1UM8naTOokp2dKFv
UaXuRJgPe3LsXDiHV/S48woUNzDGoag/bshYZnaPHMyZM9NCQu3Yk2z0J09bq/Uu6qLCJNbS
wzEwnfQUAR/Ly6cHY/LLy/j0eiHJ8rqpJcN3vXJx8tVPTyY/eGgbHv7KH3DJRfvLX/nxc5/M
XPzZ2ic+JmTA12d/gZf89lM8dfvxt/puvfvx5Nc/2pv8YsM+aqvOAcx9KLyLHCiM3jQnhJzY
q3u9YX84zPM677X5bWH+Of8ux2sOzu8PhImRbbrGe8b7zdB0YbpylT7VNcszwz8rMC10VfgO
/wNED+ZwnDvHpmTFDQmzvcD0juJXmf3DU5n9wy8zeyinM3so34FYoIusofZsnO2MUwIT2Sxa
52OCkQzOLKTVZqyTsef2OSjOAHEeHeWW8e4sL2GYG2wdwKgggDg0B6/Hg97Co17oSu7afzi5
59lf4ewPfo/DK7/40a+TH5A38WL8yCvJp/5wLLl156/wjJ8n/5E8jCtweAe2/Tj5KXTpWeCY
26hsQ3eaCcYxm2CoGaYBhnnYIIaNkJDtf8AlaTFkTxNr8p+YRb1oZm8D+Dy3nLDOr7PjJz/g
lGe5D7//lHT0TKBcMvSlHuqRTUt9xvuEAyiBa9L62hYMMJcgEEGMdhN2aqIXx1TNaXfmqGpx
Vk6EzymOCMVaTLMHghi5DWYiGlKcHVmF4vHSxCH6Ry/krqyupgceoEsnX9Nfc1fqBxNlNFCN
ViRoPm2ktlbjR7quci0Pc5N8i/QF3nrfMm2ld622wXt7+ClNFQx2mN5Gv8fmJQzt4m7y5A4T
BrAX009oNTwQUJTFB/aQJ1GQzDcLoZcCdFNzL51lNAHm2Qah0S4tjZu5sYr+cUxXbQn0+PTL
9El8c99ANx7SGXwH78FDEKKWMZQzwGomaHNJN757+x3Wtho9xHaGrYUBk1oUZi2tgjFXe+L8
uVY8ZAg9vwEW2LlTp0Bn0uDzfgZdcLQ2akSJ3sERiU/rit6zcPW2x28sv9Lrti3tXrugcaO3
K/fLn1735sK59TdvTn7+/i9S+JbAA+s6bl71mPdRct2Nc26+9VZj5+vzOutnPdwv52d3HUj+
/TNAzDBA0QKyGKzPEjPYTJo5MhaPBQshhkhIaIYCQb75TkpDJ2r1z1DpWOAT1IJrPWDpDSPF
uHvnTioJwJ7jdaBqFVAcNwe5p9vn2x+0P2d/wy5cyV2p/YTn3JjIyC5ykqDaOAnZwZB5k+O9
HMdzGgKzhpe4vWQvkhHBW00V8TwUQW+qfDeZ+7IgqGZ2lFpsx5lAoPtxXemNOOtIl9qNB5ua
ZObFKqT23IHSZiexvBZvBSI6MQhH6Mv0HQBOsHPSZKejG29k8/UXqqKptk4r6M+Yiq4Gc/tM
Vea43Lp+Cf5G/aDT6cysOmkgud2VGnUYbOWVXF7fSo7Pzq6y1p0QtadNr920VdrbJ1TazXil
PS8CcV9L1dbQD0dwOTufwLkwubfnVvLIj197rSs5EM96itv1/RVPJR8jPLmnZyFMQhXgVwL+
y8GvZ2xGl64FPB52iO10l8vFgK9MhbrDWo5XyGHnq2iBnBz6NCfigCc5zH7M6SZ7TTtR/X4j
qrsIMaKUMN89RO+HUCk9j51gp7IPUuZLMzxt0O52s3N04Pk4XSTTDnCc20Om5nhpHq27E6q2
dGh6DdvB1rD/RWuJhNUebY01Zg66SLhI3CvsF/dKr8tvRKTL7TX2KY6F9nrH9e7rPbe797k/
DX0aPhWy77e97CFhPaJn6zm6+PPUKXC6joP/cgopIP9COaoui+KbkZA3EgnJkRAH9BeKcFqO
TkXCeBd2dePATjoCxNDhBNtaXep/BywCyvl4L1mDDKTjIabdtbOazCJNZDVMxx6Sj6J4U5rL
GY9X6VT3stUxxtl+i7XXOfqxZUxrtRvRg8aY3ujaQmtNTUFWbnww3Tq5kMvpTjp4mBIvfT+Y
+AueePDrZx+44eaH8W7PN79558xlz7zy+Mycl14aVjXnwE0HP5278McPb/Ac/t2XL01/ft+T
6+sGACdOTf2JdwGl0PWjqempU0M5vODN0TS/kvlsQGF7duyzIRdiqzrIZ+kSplvoBtAhNjuW
agynqe6CmqzFHsViRgZ8ZW0DQpXWJwZsCwrpTD1lqjxfZ5doBPUI9StB4/0cJs8HwQ3BCSR1
LS+uI+tt651vOARFsgXISM+VWVcEh4eneGZmzQxOCi+UFtrmeBZlLQzODq8kK8Tltuud68T7
pXv1NwJHyfvi+7bfO0PnurtUYfKc7nXo4OlsjrqWMlvfcV5657yeEd3sDNcFVgGbPjZ/NTUe
ne28+txZOt05L4x7dCqsXTqV2+LUhe9sXd7ZdumCdx57d+WPdj+3atVzz9206opa8g7m8cUv
ztqRTB1NJpOvvnT/y/iR5H1fn8Lz8YKvGtdSS/QYiNKzMHcq2mYaHLi2FQv51WQTeUDmX+Sx
gkSBcOAr2gl+U2W9V+mYUPobt+OZRcv0oRMUYRPqSBsLp6wvOzJzwuYnZBdMzWktCFFM9Bew
IZjg/wVte3AVvg1Zgr8lccHuDjUiQDpSOs8cWM2NuYBoBwI9l5OzXcPemXLfx6Vt/A2XrIr+
dPSbs+jYRPDpXgaP381nW1S5G6b6tHXiT7K2W8W0SH+XGQc8+2qPQi7Dbj040OWwPp86YJZS
yGWytOriMKgWCTxoJ3i4ml2kA7eDUOVV3qWmT5taR9BclKgP6e8f0t9NsE0d6jSzrc3z/k/Y
9Dm9uA9frJIrXFe77gL5bFhKhqkQ9onP8cyh5lOmEs2t0CPZhfQg3Snz5Wh+BS/aFY8YVoJu
gUe8aFNsDtmtIw/nlSJy2JbtyEcFUh854ahAA6Wh8kWOEdxo0ZTGymNsw52jXVe4r3ZOci+U
6uV57pXi9VKbvFvc49zl/rt4VimyuYpQkVboKHIWuku9Q9Bg9wp5rXw/d5/9Gfwsedb2tH0n
2iXucfyKf1/8nfI5/7nzT+7T4ndKxCbSHtvZXRetDXF2OordM9tLYdXh5N3IJUtygeQscNDj
Kw6J07C9AOT+++ZgtuJFCnAftgCrYa9HVG2uuJpwTeEnqTNdi1yrXBtcqkvlOYTpdFgTcx7V
1g5VaeI0/NG0foJe1j4z/IVNLycIRJQkQVFVGQxcVXe5nN2pMTsEMCG7U5ebc1Wnw3jVJcmG
5HK7E4LkFQTJAfNcoDm8muaQgfwTquyF15FwbvUDDAvJzctOl92hse65Nbud+qt0OcTtdDoc
SPWe0TU8W6PHRzitGz9jqsZ4FTepq1WidpOppgJ6o8m12kVcNGXTBTyb7S9wAhTeic94zsxl
5nZw7Ona2kBPbQv80YWT2sBn51ZL9PRl6Qm2kuJi93Vjey+iXBgBVa5z6Aclh15FA4VpGNMR
nTy9SzPsBtkHchNDcKSOdKH+TsMNNMr0DfvCZUxHxWS2undku0RNTsjInTymo5wdO5FTx7dL
hpXrTn8ks5tWtMtp0Lrl7tSRTqk/rbETDSF7rJbOVX7uPT97z5U6vkM1eAMN6b1D50i9u8td
iUogAINv91AjqOb8rghbcGgBzcgWidgakcdPF4piXCGHxyT37nmumi9/bveWgRfv2pbs2vtc
8Qd8vOehE643yZKe+986ROaePUpW7fz+MEiaVcmJZDb48zq62FQLnRjpbknW9W5cvgNtccgQ
my5pi+MaxOmcwXHci65HNjLB33MGJD/77pR9XYLjxFUxGCQaELAkZukYH7vn12Nn7FuzsvDi
GAiK5MR9+Bvs+Opoz9kjNRvu3fuzZDRpgCKZzP2NzID2bfSUrTlzS3BbkHwtfe0hx6RjHnJY
Ouwh+6X9HrJN2uYhW6QtHrJJ2uQhN0k3echZ+ayXLJIXeckMeYaX2GW7l3g9suS3O22Ic37r
4L4lDo1ge5WGqjRMDzaUepqk1dImiZOwZ4i3yqHZq4CYTX+owrEMS0PkKgLmI8dtAu8yGGh5
xvpAj+6B0K9qmPnCIFRdCyYM+F+6deiBnXmAP6S/QU/WotaWlhbckv4HyMmK0c29wX4Q+7m9
YOz9hdHn6pLBFRz+SQbiD/7mqbVVE4pH+a++6jwEmHoUrNoe8Bo0FECdZkmDa6GXjNHHeK/W
r/byNnsO5Ul/wPKL3XFZpQJcZtYEWxQNU00mh4wQhr9QQPvfusv/vLYUpO7yeVVXRZ3lFrZQ
QBcJMitLPVWW1gOXuYx9BUhyc10AU0uuMB7LfZQU3z120d01XyXfSK7HN+x7tPbKAbcmbxf2
ONwNuxbvTfb0vMjhjatn3pKlUd9pNPcFGSe8wejl9+Y4Ri+n5FNegmXsJcel4x5yRDriIQek
Ax7SIXV4yOPS4x5yt3S3h9ws3ewhzVKzhzTIDV4yWZ6cphen3cYh7wseSiF2DQjHASSD5Rck
mtEfAxkRVIWxw1llB6op1PyXgEdGiUZbRghXhYBwChFdeFrAaAa4o4oeK6xiBHNCZzA7IEOP
x2TiC0nmHLW0tAD1UJexPMsrWednynvBV/0imri6ZNBA7r8yAP8NkMlFE4tH+2ZNPg+hC3i7
wbQXkSKdKKqOkVuh3K1u4YAjyrvQFu4aB10qSp8C+6YrfS7sBKMEB/VInKpKv2ONOojjRXea
/+mc/0AGeGLIRb8CjReW0wNNOulZAxZC3sWF16/ZN2Ps4eREfBz/cd/uezfM+O3ZnqNfJf+a
lKGX6xHivqGroqTODIvWuWlxmjhD4Zza34QzIqfYaddE6xNmYp0eZcdsMgBb5WY22lRuhUrc
ouFhu16ndrgtO6MLYrfAMnItw+NWyBF5XuDFwcpoXigQ+6rT1RXcMvUo94koPS3imBiXCuRK
cYhSrY3XavgacbpUo9zIrxQeUF4Tfwv2wgnxC+kf4rdylltVBfDMCTC0osiQUGQwB0SvJIkc
zxcIKmhcVVUgIQNvsl/Bk202BN46dpqKwLNzfnkyTeUa7Cykbi3NbdawZitAoJPx5sxnw/R7
mwH/9L2NtdfuZqzq7vWBW9Cu/TF39NzeX9ak98hOAq+eoct5p9mPB1jatrrK5WfbE3zvoyWS
LlfJVRy7pw0fbYyCo8qtHFECGl14r21J6y5TVUqyKxUZPHuRrtVmV0L0bqfBou25aW++FoH2
akFsz203ElMHOnPZAn2nj0YfdeqVohWxlJ1F223pVfcabG3Wme4PeSx7fdCa11vFbvDWmc4A
ffkv28NWcXr2ujYNtbDTA7gc4xiWXOu78PNfJBfg/R8lH1st7Pl+H+5ILu+pJ9Hrk1dT7pkJ
vuGfgXv6kyyzcA43h1/KtcF0Fg7kKiPDuculK7NHRkfkjyqczNVIM7OvKrrd44jRjzjSByAt
oCADxDNAYQaIMWFrFbaAggwQzwCFdK94FIWKtHg+yecKCwY5K2IjCkaWzjCmxaYWLLIt0BY6
5nobAitt12vXO2/Ul+UvLVjLbbDdrm1w3qnfln9Lwd3avc57s3LSU9c3N+4Ox0NKvBjHESoO
ufmyAXHUAKSl9V0Zvj1MwgU+rW9OYQEuEHwC1RzWl9I5fZWcHB/H/LwEPTtlia/a9DEqf2Xp
SesKm30L8h2aTciNZOeEZUnkOSLigvw8yBOFnHDfkElpdhNooZM+1Jeth7LdJh0beAKejZvx
ZiyCbOowPX1pk7Rp6PEVShwV42K6mE3pv5h2TaPvFYfKYEw47qbbWPSRO6PG3Oc+yHZPodou
OGCOtR1SO/ZEgh7ip9sBbFE7vSGg99SyD+otYxuYgR3nBLCGnSg+v0EHxOQZnEPY0Tqqx/IL
4+xw5w8+fOf9bCUSHN/8+MyXtVm/urHp+ckTZl6UXDSxcd5Nf/3JE9+uFfY4X3qu47HKIfh3
09uvX3v2kdeTf3sAf6AvufOqS5eOGDkv5q9LDH6ioekX9Y1vr3Hccdeaq8eXly8sumjn8mWH
l7Z9Qb99fxwk61B21sGN3jNHgjgTLuLLhbWC4JfB2Od5wgseBLKEcF477xJsEv0VDpsoRVzO
zV7s9ftDoM8KVHWzDUdt1bbxNs5GDYDB7FMzJmdsTM7Y2LlZWw47v8I+lbDJ7OQKk9q2oMf7
0g+/42PihloG7Gs9VD32pHX0zl157jc4XOXl60C4WJ/sybozLutqGCsOyTrYSD/Zo9oQW6u8
9FCjBAhd25WcnzcoOnhQV/mw+y7nv/jNb7694QHH5XfzM89uPTi2nnKwEzTLf4MXreM/pNd2
spzYJvJEEYmogbeVPr1YmmAOF9sNCr/sdGNnXpBJIHNCsHKG817+XvkBx4POA8IB8YD0llNx
mr7KEOdRsrSQPhAPta3Bd9nkUvdVfI1UY5vuuA/fr95ve5l0239le9Pxtn6Ue0/5jfZ7/VPV
nXEcbXbkdjkDGmBQpMrLQSGniIiGQNWKTKNS1AChWScU54oiJ8mKgkURNAbH2ZxO3aFp2OnU
dBtGCtFsnF1XRSdxqvpr6DWF6AVI8SKkcER7DfRIgR3m3s6pisIBO8Kc2u1IHe/G7su1m+x5
qrNOVG4y1W4cftkUJ4jt7OcJhpsOg7uJ5I0HXF7uWnUwvYrHNrdDgZP6p/rpk5/VXuCrUeVR
m/bEatPHEiudznUy88CsO0QSO6lYlVYaXY5AdqWN7b9mV9rz/JUcBJoGtaCzlZusSpyXW6mY
kfNHKNgHfky+gzwv99Ot8sFUsnOF2IlvTT7wxyf6RUoKdnyQ/BG+48OjQ5NfkCKc/HZ0/0vL
zybtPb/GV9Qka9kvbAlk0wB54ZeznFV/l8My+1W/xz8p7JP5hT/KXWJceBdAJf2btpS2kHRJ
chwafv6HAH/wc68DRMjiP0H9+aVoHX4drecRqqa/zyhMS/VA3qXkeXQbxGPE59E6Wgae5UM8
CsIImobyEyC+AvKfh/gWSOcC7IG6boH0WoD3QNgP+UUQQsLr6GFhGnoc4rliJZoDbT8L5aZB
O8MgDkGogjAVwjEoI0L+KgiT4Z1HIR5N01DPekjPxK+nHgfYSX9/DC3Cl+BubiO3ka8TaoQ/
iHuld+RdymVqHkiJT+37HUWOeme5PsuluNa5l7t/4hE932UpWR/5TN+H/hX+3wb2Bz4O3h16
Jnxb+G85RTnzc3qi7YbPaMzdGVNj9+Y/yzA3AA2hZwrpL1yBtVqKpoGvM5/PRgLLHUroLwpz
7PkCducYxlWW4thbDtSWhjl0Dbo5DfNQ5ngaFlAO+jINi8iB5TQsoT3Yl4Zl1B8fScMK2kAy
bWnkebLh3BwPFCrSMEaC0JiGCZKEJWmYQ6XCsjTMQ5kn07CAnMJzaViE8t1pWEK1wv40LKOA
GEnDChopZtrS8FRxJdSMeQ7asku/ZjDFkC4dZbDI8r9ksMTyzzBYprAsMlihOJR9aRhwKLen
YcChvCENAw7l+9Mw4FA+k4YBhwpKw4BDJScNAw6VkjQMOFQ+S8OAQzXTFuBQ3cpglfZTu4LB
Nto3bRqD7Sx/LoMdDG5lsE77pt3EYA/Abm0jg72szKMMzmL1PM9gH8vfw+Age/c1BodZmXcZ
nM3KnGBwlMGnGJzPyn/P4D4UdqgM7svgAIVl1n9HnMGsLUcZhe1W/iUMpmNBjivQc8hAZag/
XIMAmoLmg6lloLGoCS2B0IZWomaWMxxSrQDTex3kN7IS/eDJMLQILgNNgrx58H4bWspSDRA3
QOnlcK+HksMAboR3F7Fn89AygOog74dtDe1V0vhB2aHAebTOpen2DTQQau4P/GmgIqipEc2B
p03wvAnNhRqLe9X1797sB+O/rle5sYCF3j1oZOOpg9DGxl4P9SxmvVkIebSd/z3eaK1LWI3W
e1Mh1QgpiikDTQaojqWslpdAbimrwWB1z2cjMWCsTYCZJaxfjax0v/91T/653JRz0AhWcgXr
6zxIj4exzmU4pk/7stlpQtemxzKOPZkPOXSulqISyJvAWmplTxoZDifDfRkbkTUbBsxAJUjX
MlTDRmMw3K6EeBmjHwtH1hzMZX1tY3lNcK9n+c2svZXnMGVATivrU1saR0sYLq10HaupmbW+
mOE8g/VrWR2ZGVmUHueSc72w3sj0o7VX2WZGc/XQ4zmsDQsfK1i/KUb+9RisNC07B1pbxjBS
zzjqh5igbyxiUBGUL4aYUuC16X7/67qX/H8Y+/na68/NfSujr8xcZqjnX42gN21f2K+Les0R
HYk1ljbWXoYuaf3WWOshZwUbeRPjuv9ECXUXzHpDmlN+yC8Uq21Qbhl7k/Z2+TlqtuqhJRdB
if9EQ/2eM8r69x9kTJnfYIxtWtLUtrK5wRje1Nrc1FrX1ti0pJ8xbNEiY1LjvPltS41JDUsb
Wpc31Pcb1tpYt2hSw7xli+paM28NZZlGOnfotIbWpfC+MbBf/wFG0djGOa1NS5vmthWzUr0f
9iu7juWNnWJV0LjUqDPaWuvqGxbXtS40mub+274ZjUuMNng2dUljW0O9Mbmtrq0BXl5SX9rU
ajTBk1ZjTtOyJW2tjQ1L+/27Ss7lTaG3Ea11KxqXzDPGz53bOKfB6GtMaroWWhnXOGd+06K6
pSXGhDqobk5jnTG5btmSehiGMaBySFlN0zJjcd1KY9nSBugRjGBu05I2o63JqG9c2rwIHkCn
jObWRsicA08aIK5bajQ3tC5ubKNdv3YlG8giaHMJrQIe0DpaWW5za1P9sjltdLQr5kNHerUA
ceOSOYuW1cOcGJlONC1ZtNIoaiw2GhZfC3X3Kr3kP7bOitfT0bc2LKWjpOg534CF7XRdF7ER
FTVCK20NiykuWxuh1fqmFUsWNdXVX4iEOmvoMB3n5qVpWVvzsjajvmE5RTOUmd+wqPlCDPUD
GdzEeLuOcQ1wNdaAahcA3X7BpHzmmaVhKCdSjqvnHuS2cz/j9kPYze3hXvw/q+D/rIL/swr+
zyr4P6vgf24VXCB7z8N1jGb+1bM/XlBuEdTTWyozufxv6lwEZVb2TvM5/AB+DD+avxjulRe0
sATq/Xe1jIP7coZFi9fn4w78GIfY3FJZ15qWI3X/oYbzMIf+47/daApXtCMeiB7ZxxWj4xAI
V9yZyI7u5gq57M6LomY3F9vhzipzDuvL0cXwUnY34N4EYRuE/RB4NIvLgXwd7qshtEPYBmE/
hCMQRHD/c9hTA0IThC0QjtMnXDYX6TSi+rBCLgjvUs/byfnR1xBSEDgUhXsphPEQZkHYBGEL
BJGVozlNEFZD2A/hFHticv7Ou8uh7/7OO1i0Y8GiMpass5Iza1lyx1U1Vjx2ohWPuNwqNtQq
NqDCyu53qRUXllixu6CsncaqVnZgmI/zwSCpS98Md0wOIifGKIq2clmoAwLhxHSOybl35MfL
tuzneIQ5wmGY5GjqAIc7NVfZMJWkyNfIjaLkK3LSekJO7nC4yrYMu4J8jLZB2A+BIx/D9Ufy
R7SaHKc4h3s1hC0Q9kM4DOFrCCI5DtcxuD4iHyEn+RCVQqiGMAvCFgj7IXwNQSIfwl0nf6Br
RuxO4WoIhPwB7jr5PQzr93B3kqMAHSVHoWvvdA6uLNvNgERpGogWpAF/OA24fWXd5Led3xYD
RcVhpoGi9nJ56BJUzuV1FgyIdnOBzqrGaDf5ZIeRiG4d1p+8izogEOjJu9Dyu8iAMAHCbAjN
EESA3gfofdQOYTOErRA6IACVwV2HYJA3IbwN4X3UH4IJYQIEmRzphGa6yeHO+KXRYT7ya/I6
8gPGD5Ffsfht8hqL3yK/ZPEbEOdA/CZ5rTMniobZ4DmCd3SIdYhL4blAfrEj3x1NDXMRuhoX
hXsphGoI4yHMgrAJgkj2k7zO+qgbKtmL3pQRlOxEX7D4afS4jMwFUTM+HAjQoLf40IsBgtsW
Y0ucmPF7H4AkvcXvuhsgeovfuhEgeotfvwYgeosvWg4QvcXrFwBEb/EZswCit/j4KQDBrZs8
+nJ+YXTw+IXYGOYkKwBLKwBLKwBLKxBPVtALfcvTvj3U2acPYOxBM1HcJ9q+B7fvw+2TcPvj
uL0Bt9+E29fg9ircfg1uT+D2CG7Pwe0mbt+LhwAq2rHZdUGy0gzg9jdx+0u4fSluj+P2Atye
j9sNPNjsJrmdl5ezaCSLdgyjTAfxxZeA9HGSXMBoLtB8LsiE/XA/DCHFUiYUMvKswsEcGuft
6FNtpfsNLWsadhl5FV58FabhVXQMAg8T9CqQ0atQyatQgRPu1RBmQTgA4WsIKQgilM6Djm9i
dyfcSyFUQ5gFYTWEryGIrDtfQyCoKd3FbaxjpelOj6cp8ipc9D/HyiW5ZrYe0RP6ZdymCHbm
4PE5qRwyGPnogrLbJbu6sbbrH9o3/9CQMkwhd5FNKBsmYnM63tT5bXa0G9/fGd8bHZaF70M5
PFAdrkRxXADxELSUpQeiiEzjChQhL0Bc1hmZBq85O+Ml0T3YQd/aFf02ciL6RaSbAPh5ZG/0
A6Obx53R9yDnhV3RdyO3R98o7ZYhZ1+8G0O0x2BFd0eGRF96kxVdAw8e7IzeRKNd0Rsjo6ML
I+xBg/XgmqWQMp3RSfEZ0cugvhGRa6PmUqhzV7Q6ck20yio1kL6zK9ofupCwwD7Q2eIIazSW
wyqcOrgbzzdLpHul6dJ4aZBUJpVIuVJUypbCkld2y7rskO2yKsuyKPMykZHspefmE3S93Svq
7IAsT+88g3VC78TahCFY/n8aO4PWNIIojs+4LcbYlCYFs0QjG1ZL6ZIWSsA2W4zZ7lboXEyU
sJN6MBEhvRVWcwxeAg0lvRR66CcIPc3Wi6aXnPMp8hGaHHq1782OJqEWOjjzhv/7zTxnHN09
uLwYeUvEQ43FWNWhTJw1Cds1xO+q2afTG9virulQMccIqznihcX68eGmKFhMxCvv/JDSzxxU
EfvYp6Tm9+kQpcM05uwZEEpnD4/TaB8fHnNO9NT+mr42V5x9+cad0DRUe+PBTv1Wf1F8ZVVf
fF/k4jl2houciS+Y1GdAr+gvzx3QSzTcH2hFeuVtoq4VXc5Zn25Jjhj0Ejg4MZeSm4ILM3LE
mMpG3LeIy8N44HJogEskSF5y+URCcncocmGQ89wwl5PMvEECyQTzxk3mPA9MPi+ZVJecS+Y8
1UVGFCWSyQCSzUiELpCMRDJ0QSJb18gzhRyNkSMZSaPXTCZiZi5GzMwFMNb/lpZjWbRn82Yd
EyI1TK8FtSE+7e/portrGGGTq0xJjxq7zT20Oy3BzZYrmqZrhHZ9gruObtt0Q1L3an5YL7Xc
H3bJ9swdl/fKlZXCrVhH41grlQmTVXCyFYxVLkxwF9BdxlgFjFXAWOVSWcYi8oxX/HCKOPx1
PbK9WHIazmsjvcSd1IMPRXl47SX9IH0KdysnJGlxcc90xAxUdC2vL6+jC75T6LqPWa+USz+w
l9Kn9ES5HoA8azrEaneCDtG99270CqCA1O7ghketFfyrgM8TpR0Xc4gy8aTKxNrGth/G46A2
cElidaQlk15/eBaJT0FcRVHTxiBqr1BLJBT49+ffUVb+16gb+9mjpSxtk4BrIstqMfgpqKn0
QqdwL4WXh4DDAgNq0WA0h3rb6lFfMLjmUW13VE/tRVvZaCQMCUZbMi64WdZ4x9owIfkD2R5u
WQplbmRzdHJlYW0KZW5kb2JqCgoxMSAwIG9iagoxOTMzMwplbmRvYmoKCjEyIDAgb2JqCjw8
L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQ0FBQUFBK0FyaWFsTVQKL0ZsYWdzIDQK
L0ZvbnRCQm94Wy02NjQgLTMyNCAyMDAwIDEwMDZdL0l0YWxpY0FuZ2xlIDAKL0FzY2VudCA5
MDUKL0Rlc2NlbnQgLTIxMQovQ2FwSGVpZ2h0IDEwMDUKL1N0ZW1WIDgwCi9Gb250RmlsZTIg
MTAgMCBSPj4KZW5kb2JqCgoxMyAwIG9iago8PC9MZW5ndGggNDQwL0ZpbHRlci9GbGF0ZURl
Y29kZT4+CnN0cmVhbQp4nF2Ty66bMBCG9zyFl6eLI/BgIEeKkHI5kbLoRc3pAxBwUqQGkEMW
efv6n5+2Uhegz/YM/saM091xfxz6Of0WxvbkZ3Pphy74+/gIrTdnf+2HxIrp+nZeRvpub82U
pDH39LzP/nYcLuN6naTf49p9Dk/zsunGs/+UpF9D50M/XM3Lj90pjk+Pafrlb36YTZbUten8
JX7nczN9aW4+1azXYxeX+/n5GlP+BXw8J29Ex5Yq7dj5+9S0PjTD1SfrLKvN+nCoEz90/625
FVPOl/ZnE2KojaFZVrg6siiXK3BOfgM75SoHF8qSgUtlZ8EV4yvwivECfuN8Ad6Q9+At+R28
Y7w67Dmv/E4+gA+Mwb424zx8LP1LOFj6yw5M/wr72sUftVj6lyWY/qXGL/5wtvQXuFn6O82l
f7UB07/S79DfaTz9ne5Lf6ee9HeoRejvkCv0zxEjiz/OR+if4xyE/jnchP45zkHon6N2oX+F
85fFH/9R4C+ZRY1C/0Jzt5zXvegvqFGW89+C6V+oG/1L1J7Tv1ppgy2dhFbDXfjTwqZ9hBDb
Vy+M9i06th/83zs1jROy9PkNA0fbuwplbmRzdHJlYW0KZW5kb2JqCgoxNCAwIG9iago8PC9U
eXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9CYXNlRm9udC9DQUFBQUErQXJpYWxNVAovRmly
c3RDaGFyIDAKL0xhc3RDaGFyIDQ4Ci9XaWR0aHNbNzUwIDYxMCA1NTYgMjIyIDUwMCAyNzcg
NjY2IDU1NiAzMzMgNTU2IDgzMyA1NTYgMjc3IDU1NiA1NTYgNTU2CjUwMCA1NTYgMjc3IDU1
NiA1MDAgMjc3IDIyMiA1NTYgMjc3IDI3NyA1MDAgNTAwIDcyMiA2NjYgNzIyIDc3Nwo2MTAg
NTU2IDMzMyA1NTYgNTU2IDU1NiA1NTYgNzIyIDMzMyAzMzMgNjY2IDMzMyAzMzMgNTAwIDY2
NiAyMjIKNTAwIF0KL0ZvbnREZXNjcmlwdG9yIDEyIDAgUgovVG9Vbmljb2RlIDEzIDAgUgo+
PgplbmRvYmoKCjE1IDAgb2JqCjw8L0xlbmd0aCAxNiAwIFIvRmlsdGVyL0ZsYXRlRGVjb2Rl
L0xlbmd0aDEgMjcxOTY+PgpzdHJlYW0KeJztvHt8lMXVOD4zz33v91sS9tlssrksuZBsEgKR
PIEQgQiEq4kaSYAAUSQhJFysQryCoIJVES+VaBUQrSwJYoJQ4qXe+lqpWou2Vr4tilp55W0t
UiW73zOzGwyt7ed9f9//fp93N/OcMzPnzOXMmTNn5plsZ0dXCzKgbsQhbdF1ze3fKbG/IIT+
AyFsW7S6U0WPjx0N+AmEpCuWtC+9LqXVNB8hpQIh4dqly9ctWXngPy5HyLQHoeJHlrU0L357
40MmhCZWQxmlyyDhhtjNEsRvgHjGsus61z7o0R2EeA/EDyxvW9TcmasB/aS5EL/quua17dnc
/SLEoxBXVzRf15J9TfcvIH4MIcfa9rZVnQgailD9FJrf3tHSPvb1CR9CfBlC1ncgDcOXfgyA
ijROOF4QJVnR6Q1Gk9litdkdTpfb4/WlpKaN8quB9GBGZigrOyc3PBr9//EjHEKpLOxGqXwI
pSIUPzkcYq3xkzSPQvIFCCstEZKfXvQM+i3Oxirqw98iNzqHvXgMmop49A0Mwj40hO5HDjQX
bcc2lIFcaB6ainmgCaM78cPx1fHP0SXox+jx+PP45vheyN+KXkXnoAV/4DEqQzOAfh5qQZ9z
n6CG+ENIRhuRHo1Hs7ELNaP34fs3aMO96D70c3xD/BzU6kA3Q3kVqApVxV+Mn0e56E5+m3Bc
eQ7dg17AYnxRvBWNQuloMwnH349/jEKoAf0UPQNtCuNBfgoKoGvRbWgH9nKvAnY/egLFsIE0
cpOEo1DTVDQfrUBr0Ga0F72JbbhOOC6cif8ofgqJyI6yoU2t6HNcgqeTJ3lDfEL8Q3QlGkCv
Q3/pd5C/kt8tXBmrjP8k/hJyouexDh/GLwpFwt1DN8Ufiz8LGhlCY0AiM6CehegW9CJ6A/0X
+gvZEN+ApqA5UPMvcBpWcQgk/j7xkvVkPfcuyofeNkJru9BOFIUROYReQEdANr9DJ9An2IFT
8DS8EN+D/0IMZDF5m3uYO8C9x2P+KZB3EGWCjDrRk+ggzOe30NtYgPILcR2+BrfhB/BP8AkS
JV+Sb3iZv4X/jh8SQrETse/iM+J/Qx7kQ5eh69EGkO1PUR86gH6FfoP+gv6KzmILHouX4cdw
FJ/AXxKFpJOZpJ1sJ0+Sn3EzuHu4F/kSfiJ/Lf8W/6Fwu7BFapZi53fF7o39LPbr+PPxX4Pu
mKD8EKoBid4EWvEkOorehdI/QB+hP1L9gfLH4yvw1VDLKrwJ34d/hn+Bf42/gF4i9k0n40k1
1NpGOkBON5N7yX1Q+9vwPUY+JB+RP5O/cQKXzpVyK7nHuCjXzx3jPuUtfIjP58fwM/kr+DiM
TJFwqTBH2CM8LbwknBErxMViu/iZdLN0q/wfQ7lDf4ih2LJYNNYHuiuDJl0PkngUPQ56fwDG
4E2Q6K+gxSfQ1zAKPhzAWdDuclyDa/F0fDm+Crfgm/FG/GO8Az+MH8fPQg+gD0SCtodJFZlD
mkkLuZVsJHeRA/A9RN4g75Pj5DS03M0FuTA3hpvKXcFdya2APnRy67lbQbL3cHu5t7l3uVPc
Z9xpGDU3P4rv4q/nH+R38wf4XwuXCdfB93HhqDAo/Fo4L5wXiegTU8UC8Rpxj/hHSZRKpTrp
Duk96a9yO07FudBydaS1IF6Yg6PIXuLgN+DTkJCGeWSGnodhHObArPgrquRiMC4mmg9tcxIv
b6ecosaDzSad+AVUgn+BNoiEA0vMn0C9+PfkBP8yuQT9BjdhL7+bWyG8SQLoabBG28hh8gKe
iA6QCjKfPMIh/Anegz4BfV+L7sPX4lXoaXwaj8M34jK8Ab1HXNwcfCuqiD9OeKzgqfgMghag
m/jF6Op/bwVxOfo9+jz2KG/kbwD71I+2w4g+gz7GT6FvsRD/EqwbB9aoGazMnaDvtyFq9Rph
nm2A+egFC7JcfBsdoCuKVCZO4K9HZ9Df0efCIdCoiWBJT8Va+Uf5P8XL4nkww2CWoT0w75ah
S2HGfAJacgTiNHYVzHQd2JIimNV16Aq0GN0IVu+eeDT+SPyW+Lp4G/ol8H6LR+NvcQ/MiH7g
qECvw3cr+gBvgXl46f+3VSC2GA2iL7AHZ+IimA+nhdXCNmGvcED4ufCWOAakfSt6GDT6j6DN
OujBIvRr9AX6BsswNl40GkWgvWOh7fVoOWngjqBJ2IfaYc5mgx2fmOzJKijlZpDeIzCfj8Dc
OAN24ir0c3QcE+yGHi2C+mUopxbkvACod8EI3oL7IGUxWO1c9GfotwmPJZ1QnwYlbQerNQht
+j36FKQdZ+0aDXahGs+Hsr5Bl6PFUEMpqsP7YQQOonKwrNXcf4C8M7AFTcTp+Anga4IZakJp
qFz4EyZodGxGfCxp5Y7AGhOH9B5YvVLQJXgltMIM/RhCTjwTlcRmQxvexRwfxe+wVjxIWuIb
uTWx5eiX6CkYE41fLYGHo1XN1SonXFIxflz52LKSSHHRmMKC/LzR4dyc7KxQZkYwPaD6R6Wl
pvi8HrfL6bDbrBazyWjQ6xRZEgWeIxiNnhysaVKjoaYoHwpOmZJH48FmSGgekdAUVSGp5mKa
qNrEyNSLKTWgXPIPlFqCUrtAiS1qBarIG61ODqrRt6qDaj++YlY94HdVBxvU6GmGT2f4NoYb
AQ8EgEGd7FlWrUZxkzo5WrN62ebJTdVQ3H69blJwUosubzTar9MDqgcs6g6278fuCZghxD15
3H6CZCM0KuoLVk+OeoPVtAVRLnNy8+Jo3az6ydUpgUBD3ugonrQouDCKghOj5jAjQZNYNVFx
UlRi1aittDdoi7p/9ODmO/staGFT2LA4uLj5qvoo19xA67CGod7qqPv6k57vo1C4bVL9xpG5
KdzmyZ5WlUY3b96oRgdn1Y/MDdBnQwOUAbwks6Zpcw1UfScIsXaOCrWR2xrqo/g2qFKlPaG9
SvSvJTiZpjRdo0aV4MTgss3XNMHQ+DZH0ex1gV6fTxuIn0C+yermufXBQLQyJdjQXJ2634E2
z17X59VU78U5eaP3W6wJwe43mZOIwTgSabmQxzBGTrHa2Rcki2mLglNBIaLqIhVaUh+EPo2l
j5axaPOisUAGnwYMXNHFMCKtUWVS02bLOJpO+aNCpiWobv4bAg0Inv7y4pTmZIqYafkboijV
kwuqBvnDeDQcjubmUhWRJsGYQhsnsHhJ3ujV/aQ02G5RAYD4UB3ItrlhXAGIPxCgA7ylX0ML
IRLtnlWfiKtoYUov0grCDVHSRHMGh3Oc82hO93DOBfamIGjyAbZRcEbl0IU/s8Vln7xsXBS7
/k12SyK/dk6wdtYV9erkzU1J2dbOvSiWyB97IS+JRe2T6rkUksRICsdyQSmvukBMI/WGKJ8J
fyJT6sVRDpSSJWC1JmppmpJ4NugCgX/J0y/JI5j642coFwPfsyVbGR0Xvjg+/qL4Ra0zbOag
vXyI1M69YvNm3UV5NWCANm+uCao1m5s2N/fHuxcGVUtw8wDZTXZvbp/cNDyg/fFDW1KiNXc2
QCeW4XGgrARN3B/Em2bt1/CmOVfUD1hgd7dpbn0vwWRS08SGhjxwLeiACPCFlVpCEw8QHBOl
flKp2ZHAxzikk/gYRl5ZFGKEO4xDSAEH1YM8YcvZiqGKGZavK6YPVaBKwC3n4TGmMGANWDPh
gWHRP69yg+c1AX2HVH4Q6mI7p6OwN5KQDlcNICl+XFPKyiNiNjyk/vigpmSXREQNHhA7rtUF
siAPHjkol88VsnUFhrGoTKg0XIOuIS3cEmGZvFT3GWeeJmIiK5jTKQovKRgWe8kBPoWo8Lwq
iA5BEGWd5kuboKNV6H1pEV0m4TiRV/rxYc0kSkTgYfMkG9xuH+onzZrej5lL34053E8yNMWv
4EKlWyHKIZKBeKBQVAELXv3VizxhkEHj9CHv2caVXzeu9AzNmNxS/SkIpMJSUVkx/bTVVl5Q
MRQOV2wU8sMbb3xlY76HAslSUbHxlVf2i2TS3PoDSkQxRlC4YUwhro3q59RGR4G6DCAuHuuV
ed2heAwkdX6/yI+lnwa8sjHMPoEAB18csHOccDT28+6hg+tir5LxuDz3zVfx9FifcOj8ZqIO
naD7d3/8M3KP8BPwO97SclSk4qAuxzzONM3UYJa8TuThXE7khl08dtuIA3s4RdJJBk8/xpoZ
uXvcUTfXBGDQzbn7Md/rxI5+0tmHnFRXOjWTQa8U6AoQKsALwC8BCi3bw4XctnnOSsdOxz4H
1+TodmxzHHOccQjIYXGojkIH7/D61vYk5LeyozZaBv0ez/rtiA+ObaiYTvXp68YKy9fek8hT
eZrpGJCeBJFai83wAXE1YmfQ6nC5iovK3GIwPRTKCpVYgyXFJZlWcv2gPis1a5pn4Q2XXV+u
V266Cfv40InY3JvDqSkf5hbPmjzmfvz2iXefiN0B8rkXhPQMaCaH5gwgAdQkx6qr1IQ6gXQL
UfD7jwlfCYJfaBI2CD2QIMC8gclBuBBGTG8DGRHk5SsrWH/CyUlRCfMBRqsjXAyT4l7sFQ59
WwOzYGr8M9gxTYCdZBFeqS2TfHKqkObyTUuZkjo183eWj61KqbfGe3loiXdp6PbQj733+nb5
BlJe872eYhBFo9Mlel1ZYo6zwbuG3E52ic+Jr4qGo5EPLCQto2iMdbQxQwvnRzK09Gx4eNMi
bRnnM0hGTRptZ6HJHLkkDaM0S1o07e9pfFraaFyMNEg1Iz80bV5AS7VWBrQUCzw8vkgAhvc5
XjIYdaOBvQ/yGIRsBoFiNFUAzaEfNSYk5yjZxga/YaeB+A04bsAGzeSKGHwzIzjSBDK+uxBj
XJwTWODGH7vxTPcCdxvok7e4tWpYC6af/nrl6cYZlsaz4UTsJJXjadB1ECbMovDXjeGTMKMa
V4YTU6e3IA2vbDidiAygjPjg8ylpkbkZizNIY7iBzhPQFs4Esy0xFKhxJc4qLS0ucrmcnMPl
DoDCZIlUc0oipaVlpeBvhoLpIhZFSXQ6qFpBYgluiYffeftwfy2Xkhn7Qm+RuClPND5xZP7D
P/7FZXVttXPx1aVfZJTVV182udiiJ3/Mf+i+hjuej/XfedtlqWVeuaamd9MVd9WmZqqpsyaP
j71jK/JkVYyfXxQqy2gBqdwD+7kG0AYX2ql5JLvbfoW8TOb7eRyRI5Zqudr8uUUQqZDTrJLJ
KBr0egyKh0MupKkZkX0Ix6EQn4eOris9I7LN0+Mh7Z4zHvKVB3t0+pDB1I9zeo1GA6UwA0uP
AZ+BsfG6k9q6sgP01XLaQs05SD18liUwBWZGrPL0mELUCMILBKyREBWP6AR9DjhBjKOIk2+I
ncqYVT61Mxw7hYUt7zY+NNNPRj3TMrbu1t6Ynw89cmDSslt/RG3QDrD+QZhjCv6VZlI4UfZy
bpm3yWCL++Ooz6av5KhSXdkYoVDLnTM3whVJskOSZE4mROIUnhAFIrwGNLwG+XyR+DZY4n6y
RfNq+jp9k55r13frSY9+UE9UfaGe6GUlWSiFmmnOnIhSBCtEIWxAOLD2W/p0Y7oS+gedDlNR
NIIUziZjbBZjUKJyBGFjPrW7YL+HFY6Ln9AUU1ZEVuFBW/08WHJZY+YcPmDRJzGq7oP6Erlb
X8I6dokvPyLPgYfAubgiTuP4Gu42eZvcI/fKJznxFe5t+UOZU7kCOcKNl2fKP+Z2yj3cPjnK
HZX1iWWyuCRCtGK2TJ7QjAVFEaLSh+QogZQHwBzlR8hceDDqmlEqxOAhE0nyEM4tjSZZ0nhS
LM0gmnQVmS8pDpIiTSeTpYekp6Vfkg/IZ+SU9HeizyLZ0jRprbRJeoaIGMTSER7+ICol1kfU
COYNU43A1h1YJfXYHvvt0H5YffK4d7+t4Q6fr6ajfz/o+RkYfT3apl0iC7wkZ4o2v4ALhX0C
EQSF4zPBL9EpmXoE+7hajkzRIT3W+1RjoVEzckZeUdmwETZohjFzLgwa1Vs6Xl9XfJ1wRWiw
UisB7huz5r1p5QI4Tr0+Bvbby2m7gYgTLNQwQPudgWS4n688/zk5MaRyxcKhc7EXvomt/AZa
PxpaP8A8lw4tWKAU8oVCndIOPsE2RRKxQDJh3ykhWQEXgt9ANRLnaTpRAi8CbaBNhqiVM9WR
dtJNthGeeOWhZxIdqJ1Vv59odMGDzrAVDzyIk0zvhhJmqxHaVUJbhz+OTefvis3gXzp37rsJ
0Krm+CnhauFd5EPvazNuV+5w3OHaiXaIrynvce/p/8YpmUq2IduY48hxdQldyu2CLNklt9vu
dueQXC5TkLKFB4UHlDe4X+iFSjwTlu7ZFvpS4gxtMUwaqyfCoA7UGfaymtuTx8smzWSLmGoX
mPFMMzZrTk/E3I+ztXRbno4zf2Waj75CrChfYSpOdWb1SNgs+aVCiQNX4c6+lPXJcVs5/TQb
NjDyp1Hl0Ndg8E+GKaRII7M4jY2NWBD5oIqsFhRQ3S63wMyP1QKGuZSvxP6Jsbe+jP0+tglf
jyPYuGdxUex3vidX//SXr/es3ktSrjzzOd6Kr8Ar8P07r47WdNz6Rezb2BdfbqeeaANI7hRI
zoxS0OPavAeEB+Qdhh0mXsaSSTZLnizPWmWNTVpjXeu8nb9DvsNwu+k22x2OTc5N7k2e230G
yQZ2yee0+Rw+j9Mn2fOMijdP4lxZ+3Rgni06VcfpoL+aWpimpTWltad1p/WkiWramTSSZsnq
QZiut4XMAt3Zl7r+5QtCAfOz8ixFYN2jlheksBI12iNldHkqTooCYYcNRJBYrBomFf1s6R19
uBrfFlsfOxIbiK3HYz7dv/9PHz3//Any3okd7b3hcbEVsYdiP4m1gUCW/T0Wj8fPn/uOzsoH
QK9vpTYZ9LoSZqUoZEqqXCgflT+W+QIwSkSWUWJqKjAvK8WZIhFnc7BvIL6Efb14Xup+aF42
ViTVmS3dPzTvHuBOD40ni4ceoXPuyXND99C23QmPA8wna2OzuK8oEhGoPgYzGdQqHe4IEqiX
1i2cSLhn7cIZge8WQP8Ih2Bl+QD2N1F0AnGDVKtpO49BjEcr+DE7h72Okd5awqhRf+1OnJ30
16rAX8uCFdqBUvFPB5Alfk6r0Zc/qDxk3G7ZI+zWvaC8YOz3ybIDTyGXijW6maP2GA+KB32v
6V43vK87bjgnfWM0pppTnRr4Jk7NZI2YnUedbzs5J+2MeVQlgyY3QHKXZjCbbHWmJhMxeWwY
Mg56UyK42MYmYpqamJDpOQkYzktATyqDmhkcuR66x7ZAsxfYbNRJ5/U2D3UfMvQSCuACZ2Cm
CZt8BaMWjGobtXMUP8ockDWjOSJ705J+WPiimXkabKjm8GjZjkqPNsoMD3D+PNRLZMa/cojZ
WBs0AihstDFAZEs6iRT2DpOCqNnKwRgQZNjKaaN73RRE+xTdBBatClSG6eLZcJL6bo2sepMG
UjLRSk20ejBB7srEAss2VzBksEYXs+FDjWEwGmJQhZ2ABRUXIS5Atweldmo6JNFNvsWe0s/3
xf58Wyt2vHsa28Qhjbu5eeIVWdza+VdVVGA8u+Chx5675yMs43DstdiRG7dMwcuv3zBp0iqq
kxtho1wGumBBe7TsBwSsmPAcYYnQJXAFtnrTMlO7jdcpZoPfQLYa4gZSaZhpIIZ+skbLkSQw
DBwRddlIsSiFsHjwim+DbaeNLLBtsO2zHbPxNgsKYQ7cNU1PSDfuAS32WisHcCpKOGoj3LSz
jd7pdFvE/DNQ2vIi2ntwb1Ft1A07qRLYSe3XFY2F1TnAfDVw1twSc96suId6apOurW5quPzS
S8bPLuBDD1xbXfK3/Kq9sf8CxZkN+v4Q9NEIu8UHtCmf4VPyN/ZvnPxr5DOB2LyCVyENlvn2
+a4GzwNkh7hDfsDQr/yG/E74vfIbA5hV8TOjZbf8S/If4svyqwahS75DvFXmrKCEvTq9m+qi
g5cc5ZKvKaU9haSYAsjrq0/oHlW9lWcvGD+0ElaBlZPqNaXVssS2xNXq4XFjA10a7BEb9Ag5
HSiYnhHKpK560hzO3jz0yH/hSOyNL38c+2YzVrevWHH//StWbCfpd2Jxc+y1r/4r9vKt8T2P
7tnT88iePXQt2BJbzj/AxjQVPaTlj7VPsRNbhCs3ltsjKdXcVONUe3XK31OU+eJ8XYNtvmu+
pyH1rPT3FBkj0Ud7JUh0O6y59HqL2eQOyL72UXiUNcdkMocsFszGsx11Q03etMpEP8G+V8BI
Wk4Od7eCdjhhgaB70GPjEnGJrhX6vMTTmirSTtsTo0hXANivZIG7NaLXW7BY/Ow1A5jEzg/U
b50JA+y6e8nCm29ftHQTuOB1i2N/iA3FzsY+qJk39Dk30Pf0T/p2P74TWrQRxvo+sLFm6PtP
6Dw+p43Rl5elXJpCbLS/id5+I4kl/HjjeHtJymS+1lhrn5xyn/SgojOYQEXRSBnY9Xoz0g3L
wJIDO2QzFYAB/6MEKqafHqr49J/6z4Yc+q+n/U/0XqC9ZzYZum9Ldt9pd7i/7/5G7L2596VY
bGjgyv2aLTJ1XeMtty5tuV04NHTmvtip2N9jZ2IfXtnwCMl9cmb7zqcPPvYTOu7f7/kltGYA
KXRFobt+pU4h3UpUGVSOKV8pgl9pUjYoPZAgcKKEBJ4zI6yxdYRDjdB/URAlXkekEOaHzwJ4
r/xPZwGwAMLix5Y+S8XwyYAdeoUTpwMwZl7+IOZj57+bxoe++xCsjSk2i5/Nh5AdRw7YsgVs
p+6+xwDW2gUmW6IPkT4EF6QRWrnfNy4C5o836k2ihSC7yNsJz3EYWmlvsmBLP96n2fRmY4Ep
G6nOQmeTkzvjxGwBSg9FKNRsqaMiTurHlnOaxxvZwFGTlKUphMVgYaUxGy5HWmppJLHyex2v
JE9ywtOHvPCEv+RRWDgMG3nL1+DQnm4sqISeWyqwrdxajsC4w47KWi7B7hyGPYzZ4tBYG7WA
+RoH5quXt6BD8TOwwT2zn7NgdvaVdOg/00xGa6XdYvfCw+apBG/gTB9EKOyFeKKsBnvAbg+A
Q8cF07OyqLKUmcCmn8PB2B2TMiddvqFu1gzvxJKFV3v50JCJ/OU8GWhceEm69ffGVQ3U1hfC
3LCAXcglL2mDolUMylluqzu4w7bD8UDW/bmK5KhxENsLxgHTa4FPgueMZ9PFHOM8Y4vxfv0D
tt3pAwapKqhlVIeWpi8ObbRtdNyefkuGUhaaLNbopxlnmmsCE9Ol9IysUJmhJFCSXhIsyZBE
nWBVAh5jliE9PT0oZaRro1cZ1jrWOVfndOVuct6a+5Dz/twD6QeCxm681X2n58Hcp3Kjo0V3
wKUFghGXluqP+F34Yxd2FcuBusytmSRT86RFMn30uEZzg3bXjcaFo3HBaDx6VKAQFKIYB5gL
YVYqEz6/rjJxokX3sN7w2n46rudBmuxsJnlCEF5JY7DsnkaJnbBWImIsYhcOpZcGagJzcYN7
MW51n8U67Ca8L5BOsu1GA8n2LeAxX5Otr/NhX41dqhxqhD+rzV0+HBpXpgyg9Pgv+7JzI4H+
BEwHre8blUHjJ/r8GYm418fiWgog1xpxaXpN+g7jfemvpL+XLgbSDUae99F+PAfeEyqmflSf
O68SJx0NFk/PjFCopfnAe8KFWMN1mG/C3fgM5hC2QKwJ84zS7gJKjLXpiMcL+DM8oV1waVC0
q9itQbluDQp1ayVlETc9e3NrmTnwgHLNbj875uLd83xaekbE7MN1vriPJDu/kk4U9qF7n8aV
dBfUkYgmhJHIbEicXa2ET2MjmwIZ8Tc0RW+rNGfDA+Tw5UFjucFhKKdor6EcJPTFfn05c5Ew
3aKvbLRnslNSsJdZoSxQupIIPQVL7KjoWZfbxdO3qfQorBD7bCsWXVeW6XBOjT1z5foPP/nw
vezYN9YF9W2FamoIv9hQ//VXHwzhgvDsedmpBarTYa2dMP/BzYfv3jJmwkS/KzjKmbpkWu3t
P34nCrZhLtiwJnbaWYBnaAvXpG1MIzaDsX3M7cbuMbyKgyTIFeJiUsxpeBKZxF1pbnA0ZM7P
mQ/O3bXmc9Zzdtt4Y7FrfHbx6Fpjtas2u3r0GcOQW3e3ARv0BqM+12DMMrnczjyjAfrgycDJ
UcfFTJ9NVuZW9ukNCQj6hJJ7CAbHRBKus+JMYYeUCwS6mvnNWRSYdHl0UdM7JY9XzM3Rh3we
upgpXq/Pt3UMHgNa0a/pUHFGwOYtrK9IujBfMycm4aydHF7ahr5Onp0MHx0h1jhWea9iiDCH
F9NRp5axnAZJtlSM8IGMreZWR2vm0pwl4dYC5hG4BZd7+IyyBEYu6fK6SwJWh4kEVRhk+wgf
YR2uktOy568oy7Qb1w++f+NCjI/+ohtLE9pf2Br7yx/P39K09O5Ny1puqcka6xwVcI0JXv3w
M89t/Q3WY9/P7j9/6eFD11QM3G0itzz1k8cefbLnJyAsPewer4D1SY9TNKeQ7SuISPQh0odM
H1x//HgfQLYwqrA2PcRjkdPLss6gh2WH2Dif4tOlozz9a3oDiOKM5oI9jg4Jegfy6jNRrj6C
xuk3IiX5pkSHjQZWll5xR3iMFCwiHaqsrAB5hdkxXQosb0jH63WKQggWAVfKjZTDk5od0Rv9
7DSJN8L6ZtFV6maybXqhpudJuZ6v5GfyHH+IFMKa062ZDSUIq2AWOOw10PXNyxY4z/TTjTCw
jV62vLE4W97pymYrh7WtnE3XcCPdiSTe0+CA3U0Pl2Exws/H5uKs18e5RZPlTRyIgfSG/vjc
ZFdeHhkFSz7IdHr8FJ8iDKIc9IFWtNH5hpP8KHVLKtnFPSXsdhzkDgkHHR96PvLKLge+y3WX
mwR0RjBLbrsr4DdaDLp+nKEZZhqxZtxqJEYjdvVjopn99gI7sWs2V8S+K0UAtZ3/nIVXwZBR
yRRBMr8ryxg1DMJmxeCyHN/g3+rf6d/nP+oX/Cek4zMzcIYv7DruXoOPI2/uuy+NUPSzdClo
PE2P21DlUHjlSfZgp2+n6YAkVvrEXyOzYyCYhDFKqKVU5krqp5Q5gYD2ghWSXK6EZz8dW4wd
sy5f0zG7tNbfsbZ+6pQl+thQynUvr3v7xqXvrn8g9uk7r8W+xbcFlq24tf2aG5yfcK2XT6tf
3DT6tp1X3rp804urUg7f9mLszCfUDsFq3pz0dLdpebYGseGCN78DnNlzitI+qnsUGcdFDOOc
Ee80rtowzVntfVBRHMzB1fvYuy69ZAL/D3zcHJMxxJx7sxn5tlJvNwCb6AtWIGEDqI+b8P5O
XzhHZ3NZbB3p3QcCJfQtBPj2NpAAde1HOLd8c+y7qv1XPB/7LvZS783YO2QrqL6+edOtSxdv
fOTKBpwFO1UT9t5HLOfb91624sknnn+MevYhmJvVoEc62Md9rJUbVGO5YvAawoY5hmsNfzSI
p41Y5F18Jp9tnGK80rjb+LzxVaOCiYwMolESdHqjhAwGo7EfP6v5ON7BcTxHDLyRMxJehyTN
OGg8BpEXcDaSEcEHDiKeBwbUj+sPCFt1WEcVz2aRdkpHJU7ymSvJBkKI13QIX4ansA3tyZWW
s42JU0+YwpavwT9mR+30sJ0B+s6Uv9HyitlsTroZ+jzDJYbphrcMHxkE1NjAjsdgntEDUlxs
LXYGwZnGZP3QHnLDlwcPgte/D2ed5X56/upvYh+QUfhvMT0MXTFIxgCSScOV2oLnPAd9Aylv
8q95jnmOeY/55Ekpk1Inpc33Pszf79nL70qVRZ+KssUy3xR+kmeSd5JPzvBkeDN8nCvEz+c3
eR5JeST1kbS9qXvTZBt9r6amjUlbnXZr2ra099Nk9tLN5XBG0ojFYE6zIDVxCKXRkz9YAGDm
oX7yWB/BBtgmzdeCfkMBzEE6UQ277IJy3OXCM+n7Hb/5uGUN8Y4annuJqVdBF5nktKsYAueB
2kFsLQ4nvIQ0WFqs5bQNvWYGNJOlnJct5YJsBWgtT7oXw8JVUrywH7djevcwOWOZiGtn1R9B
KfETKBVCWvxE8i10YyPsXEptbPlJTuDSDHAqwIuQRB72RIbzWZaeL38eHtfSUL9Mjn3mxfKr
H5y7dHpx7OylLizEvrsPK7/bX3n5vKtbrvlR6mdvfvHsor6FVV/XhejubD7YQROMkglkdq9W
u1a3Sbcb75X2KrtNzyuvK/J8a4OrwTffv9S6zLXMt9Qvl5NysVQpNU4lU8XJSo1xt/JL8ob4
ivKK8QPyO/E95T2j1eJRPYS9KssECXt2yUa/ucBMzFTe5l1ISDs+E/xTX7rjuN4buGDmEkaO
vodcSUNij96IwVJZLVJi1paVuqH79GSabTNKrZZQiBT9Zu3WbWt+837sW3gW17nSIjOLE0AY
3HEgtiDWdHA7nop34UcPbv+8au51Mfi8qFXNXU5PL1+sgmF/HCEuBDJQ0HxNuZb8iGwhHNhs
nNO3gL31uvp5WREwMijoBVwPMsOkUTMKiPeDbY/yPO/VHcK7cQ8aPpI9W5Hci4LFLqfWKBCw
ilJJaUZZMReKnXro1yswKTzJB7dNjme8cTtdjbpiA/hJTO+vVj6nyHpRJ/XjUVqK+Ageq9fp
OnBIyqAn2VSneeQ1LF2dvBBxcggEBivDEKYLQDlUZg+AXohSVmlpWfBO7M3tuqJs3hSyCXvf
uP6udrUzdeE8Wt+98VNCBlhpL9qsjZVkSZEsbtmlXCpfqkiXK/Mt2y0PWHc4H3bttjzv+q3z
E/GsqDcaDBgRKdOuGPSq8W0TNtHXgelaSl1KUwrXntKdQtSUwpSelMEUPgXD9FO9hd5BL+el
59W+ES//6Ku/5Js/+taZvf5kZ4p28KfcbGRLS2CvbgHfKnHV4F6crbdvvWF9tw9nF950/Nl3
PljvSBMOnf/0yNgrrlu6/VkufD4WO/fh9obmh+etP0v7Ny3+Kf8X4V00Gh/TLhmw9qcdzH51
NC/ZJafb7nZ6wi1CS3anuNbYmf2B4f2goUE3zzQvvSG4zLDEtjTQmr109Jq029O2Bwy2INsU
+SMUai2wCZqVPiv4YvqLQX5l+srgTek3Bf9P+v8JimFdrjEjPSNYbowEa3XgQKdPCl5jbAmu
M16ffodxc/ou3W7jnnS7olOMYroY9Oq8RhfsSoM6I/gU8z2aV420eXCbZyfMm0OkBazAoGbw
lftTcEqeg0NT2A5qqk+NJPZPTXgb7sFRPAhr0n/ymq/cAvMpL1fxfBV3Y7dmd0fctVJWyJfv
z+qxRC3EUou/sibPEPLeSb46qJ1Tvx9pYxuYYwGTD2C4g5o5tl06mYAd4ZN0h8T2S8zYpYM8
UtImgDyOJeGfeu10J3QCAMTe6LXR2DHNbCs3qrZyHQtmmvaZZjJAmrFc56HBXh4e+Rk2j85x
unFGuk+v1U01TkqvCe7SPZWuY6sQvVYwwqnJYl96o6BY5S/aYlG/hr3RmoZV386NW++55LLI
wH82bdzw1VPYgd1S7Lj9xhtvmloweiyOvt11ZxwdjX0Rex9/lHrPpnWzIlNTbPnj5697tv3l
JX9507hyUUl6eSSzYMl1R7as//21GFP98oDp/BT0y4X6taJSHufyqkW1NvDdHkHmj3qI02Ul
DpvLarKbkcVkx8hCHIps1uMF+rie6KmHoxOx1ezCcRf4jhAdZYFyzyB6gOTQKcWV8ky5Tubk
bEuBdYGVWOllH6PJHiKOBajHNegiLvrOAjY0Lq977QBpTdie8MrEfZ7zjWB6vImDa/omCALd
95YXJe/z0Bsa9mImueRxtdNJV/WANeh5pPzBrrWrQpMmXFLyzjuxU4/wobrbb52T8YqlfFbt
R+ef56bS/q9HSNwBu80sPH4A5YBuNlp1lYIoGpyiyxDhInLEEwlWk8nyZE910KByBTlzlKac
7pydOU+Iu6VdhufE5wzRnGM5J3JMKKcgpw4yjuZ8nCPm0N18JcS7WaYgBXjJl+ZiZ9pSgMmJ
lyxWa1ZKamooSwfSMltCNqt2RUmTFbeBV9JPajSzLyWUlgppbam4KRWnQtqBTDAk1IvsRSgr
eQ5DoVYK7c4C0iytCkIFhIysSJY27pJIQdbbWR9nceYsf1Z3Foey1KzCrHgWn+XN/lPF8Cut
pOomXxicbVwZBuGfXdkYHl4A2HbFwrxS6nLR5R7E3xGmA4DDdna5w+VmN2XAIQf5R7Iu3Pz4
/hLIesxtGVyyvbDm8au6Hs9Oi51Ky5o1fll+7NSoytKqZXmxU3zonqfmzps3d8FV1TuGGsiC
R/MrpmzZHiOk5uErRtfc+uDQeZj52xESDoPNd6IAOqfdXG6ear5cukZ/jYGu9T3Bg6bjik6U
RR0sBLpSU42pxgw7YwW2uA6zw1JqKjVfau4yrbO8q9OvVdZ6V6dtUjZ5b08TFZdDMZhNc0xd
pltN95l+ahJMqtHgMBoNZoPT6HZl2i0O3OTocRCHA6kB+orTaDI5kWyi1wKzkNECG6j3UrJ6
xKg4KB4Dj2ZjexCrwcIgCQacI196po9Z9P0iwl7OUMs1fH/m+9eebIO6MT/caAKnFluTUmd7
AnqHoohZB9j7uO0BLp8Eg1YrW3KoQQkGt5O2P/+m+6UXm268pi/26Psdc69eUvG731xTMXNK
xoFTwqGZb9785G9Tx97+dOyPuPLphsDQI9yMjPqJ064ERzlxy0j0gowNxKPp9VxIDunBn8ew
P+/WlNRxEZ06bjy9IXOiLwm1J1LzIRUeoiLr/qR8qeN5Raezk1Teovh1QTKaV5UC3VKyjG9R
rtGtIWv5J5S9uueUQ7qzyrc6105+m7JT96ryhu635Dj/vvKB7hT5jP9E+UJnXKOs1d1C7uRv
Ue7UbSNSvb6FXMMvVZbpVpN1vFRNavlqpVZ3uXy5Uq+TPLoCU4SM4yPKeF2lSaJbEFFRdE7i
492KlDTNfsJzOkUwSFKRaDIUgddk4QiYKWNETx+slyY9vZljyorotcRdnUc0C0X0ModhA00k
HexjYMjoWYI7uQI04oLTlvdO04SU/vh4LQ9qUXlZUYoSGyICPlARRwAlUAxn4Akx6HSKIsl+
6oZgYx/9j4RDZCx7fX1lY+K1tXvO3IhQJGnSBhnLR+j5+hG9qjeQfjJWs4EVp7ebEL3dhIr8
BmygxRipm2L5euXpcNhS8Z+WCp/XMrRyaGWFz2MZCochATZTKHEGUVkBrb34tmnyZql9DiyT
cvzEfr1KHfhG9knYCgQTn97iwfT6Lg5g6z34BazDEj4cOx37KPan2B/Aq/Fwn31bw9/83Xoa
QPXvg3lLd9QWcAA3aMXZQrbuUncL32IQct3l7imuBtcyl1DuLk3ZmPKgsF0v+K2Z4KjZbZlm
i+zN2idhejupT9FH6M0Qzd4dwGqgMEACVhv4aJZC8A7o5FJH3ihgtyPCzBtP3vMZXnwD4I67
bE6HJNJvELpQXFQ2gcDkobPnPpL2fNNN/U15ZUum37LwiaF3cfZHN5RNWVBRsXzOhOeEQ6mh
l2KnfvXcLT2LanP9/EvnS0y2+b/Yu/fgEpuJ7kXo3aVz7OwgBa3RMkVhwDHg4S4V8FLhfYHY
rJlgOFCKhZoQM5Jd/9Q3lz+tMHkLREizmEfajtSLu3ehd0m78X0PYXhUN7MQtH9BL/neNtyP
f4dNs9fvXfjAjGveePHxfasnXT2lpEc45Ap8tG9jf6vVOfRb/qVYU/7CqrplRh1sPanFXQj9
sYPjPhod1yrX5OJlprW5n/JnYZYHnIqYPTqQ6bL5nTOdpNC5z0mcTkcwPdNml1UHHcSUrHax
WyRibXbWPqqiib4aaF8Dhflafl1+U357fnf+tvyefFnNL8wn+Y50GFV7oZ3YabfzfnBUE1bz
Hy9wOePdvWnl9N1Ur4+CERe4RqxdiZvTZvbeW6XqTd+Y0guKzKQmxCYk1GJYbhzY3EQkBOZ1
2rNPb7yibcHt2xofWz0t9knMiLNf+lnuZZfXThv9673Y1hOeOEdb96ZwKO2qBxcsfSacdXjD
4iMrjTLhX439TFAuv7R6niIMDcTWKobGGROvyqV68waY3j/yIfaGMV9L4cZiURzL65R9HCFi
CKtCoUCEffJbT9P79PQcxFJxNvnqe/jF4BuJF4OckcLzf6VPas/Twca9DyVb8PQDtjd4DH54
XBtjsUZ0GB4SlnXkG3xOR8r0l+ouNdTjetKKW8kGm/wxf8zwFX/CwOsK+MekF0gnWD0dnqsp
iiKLuMDwmJk6M2aLBem28jt5wquh/AhsOcMHFF2xxZx0UcxsD03fFZlBnc2FZs28wSyafWC/
Bm3HbMQmycWo27CNXn6gVyShDMngpjEc7sX4X7xxMkSQ17r2R8NvnKj30hjusHxdMcNC92U0
5euK0+EOaumG/nYSnqcpxCuHz9QxuPcmxRPBZqQrBKiTZKod9CIJs4H0gkQ4jBNqReJnNJ2+
XG8xQDCylyUNqLgEl5aJklAScGKptDjgTMd3LywYUxe7g1sRu2ZrVyru+x1+o72Aw+Tz12Kj
H5a+oaMxL/4ZXwlepxf9H21WvbnBBqbP3Gprdd3oWed9gDxgeNXyque3lvc9n4ufy5/bP3ee
E+1j7WOd02zTXDWeBkOrQRpnK3OVebg1whrzRuF28x3ePbbdrgHbQZdiYjd8UiIUPmdzREzF
9Dy7zzsqwqDZGjEewjzSwbDZrHqkASnSgA4Vb8MYHwJp85CluiVMU3EAFRgpYkxcBEqRAo6L
rl/Qiz/hr0+H6aW8xpPhxJ08gAkztLIRJy7hsdvRpWVC8tgSgaPIj4n92bRoZuuNG66tW+LE
jvDXb30e+zN2nX7pE/Jl0Zy59+w98siVbQU/fwmHMA9rS+ZuKru7QHZzQJNd6BHNfbl1qXW7
wCmiV6wgFdZaUms9RSSmklZe70I6pwM2IbATCTmdiJ69mlzsFnRiu/JvbkEr8oXrzzI+A+vu
xdefR959TlzN+Ifbz42JA9pQiB4AOL4/C+BmjDvSeu3ey7DXP7tySkcu9u6ct/DqvdtJT8xz
omX8zK6TeJCd68dPx67lb4wHwBb4NAN+ARGfgLz8JRF2Emr5FBVMh5o40Ds7vy127cGDiP2v
lEC2lvz6ticWmCv+Jntl9l+nj/+p4sKvCUCps8QdsN/DSEn+RgPjkybEZqBJ3/+j7j/842qe
CEnCa2Ci9iI/KUf38qvQVP5P6B7AafoOYT66H+KjAW8Wy1ED4A9A3p1AV8WloY0Qnw1hC4SN
SX4ThEKIzwWohzA9iYcgFEOYD+FxoO2CMu+F8qdB3R4pDa2H+HZxL7oH4H20XhqHvDd4hNKB
Zx6Ucxe/Kk7/b7oU/RXfggfIIFfClfAR/l7+D8KPhLg4XbxHekBW5JvkuHKj8ivdXYZC4yjj
66ZO05fmdZbLLL+ymq2XWp+3nbIvdVQ5/upKc/3Y9a37WffvPI97Ne8B76+YhPJQMfsZDGq5
LagAzQOf+VvyEhLYfy7N4b5AKJl/DXtyTLI6FuMYl4w6kziH6tENSZz+xsJ7SVxAo9BnSVxE
HvZrGhSX0CE8KonLqBAfT+IK2kzkJG4ke8mPL4xliVCRxGEohZVJnCBeWJ3EORi/65M42Adh
VxIXkFmIJnERGYSjSVxCjcIvk7iMPGJ2ElfQZFFL4kY8T7wNSsY8B3WZpA+TOI980mcMp9LS
ySSJ88glGxguQroopydxHtnkbIZLVG7yuCQOspInMlyGdIM8P4nzyCMvZLhC5S9fn8RB/vLJ
JE7L+c8kDvKXzyZxKFOZkcRB/spwOSB/pTuJg/yVHUkc5K+bncRB/rqbkzjIX5/oi4723Xgw
iUPfja8wXA/pNuMfkjiPRhnPMNxA2wYuYgKH9phcDDdRTTPlJnEepZoScqDXN22m+UkcyjEt
Y7idytB0exIHGZruZLiDtsf0aBKH9pieYbgT0h2mV5M4j1RTYrxcjP7bJA70ZpnhXkpvTk/i
QG8uZXgKHVPz/CQOY2puYngabY95dRKH9phvYLif0d+dxCl9QrYZdEzNzyZxGFPzIYbnUvmY
30niIB9zop15rJz/TOK0nHMUl5n8LaYkDu23pDKc9ctSmsRpejXFDQn6q5M4TV/OcDYultuT
OBgcy93oKfCJi8A9LwRro6K5aBlqATgdtaEVEDrROtTOUiZBrANw+myG9FZGkQ85VWg5fFU0
G9KWAn8nWsViLQBbgHo1PBez3yDpAIpmoJ0IvMsh7R9rGTeCRr1ANQ7NZ+WsStapohIorRCN
ASwbymhFiyC3DfLb0BIoK+cHS/lXZeRD79eO4Mgb0bq5F5XUyvrVDKGTyWAxlHgdwA50LaTR
uv/n8qOlrmAlJvjmQawVYlRiKpoDWDOLJWpeAakFrASVlb2M9UmF/rehLsjtZK2l1Pn/45b8
M93cC1g1o1zD2roU4jOhr0uY3GluHhvtNrQw2ZcZLGcZk2IztGU0pNWxmjpYTiuT4Rx4drEe
JcZFhbEoR2NhNBpYb1Qm23UAu5geJWSUGIMlrK2dLK0NnotZejurb90FSamQ0sHa1JmU0Qom
y0S8mZXUzmq/jsl8WOoLWRnDI7I82c8VF1qR4BhuR8cI2namh4uhxYtYHQl5rGHtphL54T4k
4pR2EdTWxSSymM2sf5QE5VjOsGygzwFINXBhst0/XPaK/4e+f1/64gtj38H0a3gsh7Xnh3ow
Urcvbtf4EWNEe5LoSyerb1gvafmJvi6GlDWs521s1v07TWi+aNRbkjPlH+cLlWon0HUxTtra
1Re0OVEOpVwOFP9Oh/KfUosKC0vVucta1OltK9o617W3qJPaOtrbOpo7W9tW5KtVy5ers1uX
Lutcpc5uWdXSsbplcX5VR2vz8oltyxcPs4xjKSpNGje/pWMVcKol+YVj1OzprYs62la1LenM
+Z5kJEV+0VqWkceKm5sgal2lNqudHc2LW65r7rhWbVvyL9untq5QOyFv3orWzpbF6pzO5s4W
YF6xuKCtQ22DnA51UVvXis6O1pZV+f+qkAtpc+mjuqN5TeuKperMJUtaF7WoeerstoVQy4zW
RcvaljevGq3WNUNxi1qb1TnNXSsWQ1/UMeVjixrautTrmtepXataoEXQgyVtKzrVzjZ1ceuq
9uWQAY1S2ztaIXER5LQAbF6ltrd0XNfaSZu+cB3ryHKocwUtAjJoGR0stb2jbXHXok7a2zXL
oCEjagDYumLR8q7FMC7qcCPaVixfp2a35qgt1y2EskdQr/i3tTPyxbT3HS2raC+peL6vICHt
ZFnjWY+yW6GWzpbrqCw7WqHWxW1rVixva158sRCaE12H4bgwLm1dne1dneriltVUzECzrGV5
+8USygc73AIzls5XuoqMXMkuzulEXdgIGv35RTTfpy5hs3lkXiKlhvF3XpSTTOM2cUe4V7ij
8Nw/Mv+i9P/1PP7X8/hfz+N/PY//9Tz+x57HBQve+i9teyLnMoDLAK4GfprSdRHtP+deyiSw
6iKq4bQaWAuWg8U5C/SfQ9rFdv/ivGGeVck1ou0HS/w+dz7DRtIkUqaw2Gq24lycf3FOHZRB
e93FbAGV1bqLqH8of6Sk2v6lDNt4Pz+BH89P4kv5sbzGX8LX8uUjqX8wf+4Prqnfp9b8U38S
KbU0hscAzci871Nr2SxoB0m3/QPFhXRsRX/kgqDPI/IvpF3GrETrP+jM96n/Xb36b8ruv13e
sEZw6N9+9s/trjJyz6B9EAiywFOF0MPR4x+Ne6ZPMhZp/QBtDgZ7XeGigfggIOOKWXrefUXd
h7mn0QJUDMlP986jyU/3adVFDBaPT8CCMQz2yolsyVHkr/IBWwEEgsxJbCaErRB2QjgKQYQG
PY0+hhCHwHF7uMd7a/xQwpNQkLnKwT2JMLTySfQ2hDgEDlr/JPTlSfRVMoWHVv20TzHQ6n/K
uFK4nwKXGZ4WCN0Q9kF4G4KA2uC5E0IcAgfY45D3OCLc49xjvRa/pUrHPYo2QCDcQ8iM6Y8i
DXI7+ixMNg/2me1FWpWFux/VQSAoyk1HgxAIFHsPsN2DCJDX9uaNYSKs7dOZiixAvwUavQUa
sgWq7IEnZnENAqXf0md30eJv6TVbGd+PegsjCaTP4imqAymsRZhr4VagIPJz6wGOArgIYBrA
hdxiZGTt1PrMlqJuqK8SyCs5J9hpP1fFuWCV9nPVnA+lMLKuXlOinq7e7Nwi6PEkzsNIzJwR
RQDKnNRb5Fdf4DQm/E19ip62b1OvxVl0hLuNk5ADqLqByu03H+F0MLI61pO5fYqxaFuVgZsL
3ZwLYvFDGzFIeQUraEUvFFRl5SZzqcgFeddyacgJsIYbxeBu7jGY0n7uJ32hVP/gC9y9jOvH
tFCofkJCtSb0GU1Fg1UKR3/cIsrdDQNwN6t8W19obBGqCnHZqBACARlvAGwDU/rNgG2GUdsM
I7UZRmozNGozaB/i7oCcO4CmgLsetXNr0DYIOwGnauXsBYEOMCQju2iA83IeEIzlBRAlhlRf
n2KiLfP02uyMzNNnMBVVHuFWgZ6vgjI1rrPP7Slqe4HLZV0Z3edJoQztvaCuRzh3YmiA0UWH
5AiXCoKggknjRvU6/dEqP8SpIvsRJm+SY1RI5F3yGzrc9Bd3GfxlEr6VhL9KwPggOZaYFOQd
Ck9UpZJP6P8ukY/QTsAIeYG8DC61n3xI+mkryAdkAFUCPA7xxQAHABYDPNQbeN3fT/r7AEDb
H+41umhnycu94YIk4s9MIu6UJGJzFVVlkpfIiygVivgtwAyAL5JBlA7wKEAPwEHSiV4H+Bwp
AS/DTw4k4SvkMFVx8jw5CD6mn/T1mmgTor0SBft6RQqe7UWJWF2B/zB5ljyNfED6s96QD1L3
9IUy/OYXoDxMniSdvWl+W5WOPIbr8ddA1IOOU4hs5PHeMlrItt7Dqn+AbCPbNE+Zlqnlabu4
wszCvMJdnJoJW/IydZdaZSF3gwHZSWD+ki3wLEMqAe2BoEHYRu7o5cuiVUPQJ9ovgrrh2cOw
Jni2MwzB03Ih9wzDKsltaCYEAmWsh7ABQjeEmxAPz+sh/AjCDRBuZCmdELogrAFr0g4c7cDR
DhztjKMdONqBox042hlHO6u9CwLlaAKOJuBoAo4mxtEEHE3A0QQcTYyDtrcJOJoYRx1w1AFH
HXDUMY464KgDjjrgqGMcdcBRBxx1jEMDDg04NODQGIcGHBpwaMChMQ4NODTg0BhHIXAUAkch
cBQyjkLgKASOQuAoZByFwFEIHIWMQwUOFThU4FAZhwocKnCowKEyDhU4VOBQGYcFOCzAYQEO
C+OwAIcFOCzAYWEcFjY+XRAoxwngOAEcJ4DjBOM4ARwngOMEcJxgHCeA4wRwnCBr9nPHqn4B
LMeA5RiwHGMsx4DlGLAcA5ZjjOUYsBwDlmPJrncyYRBQm/UQNkDohkB5B4F3EHgHgXeQ8Q4y
9eqCQHmjwBEFjihwRBlHFDiiwBEFjijjiAJHFDiijKMHOHqAowc4ehhHD3D0AEcPcPQwjh6m
uF0QKMf/XCn/x0NDbsL1Mqy1pBvnMLgBfcngenScwRvRfgZvQLsY/BG6mcHrURmDa1CIQSiP
wU7kl3Gvv8xc5QITMBPCAghtEHZC2AfhKASJYW9D+BhCnJRo6bxZmintlPZJRyVhn3RCImZx
prhT3CceFYV94gmRqFUpxMjsKJgWtJU9N8DzKwiwiMCzkmGVJAL1RsDOlsA3QiKa9bT6VS5+
OxcfzcX7cvHWXFylkEsxzyydisoINBzXa4bQBP9xCGWhrAlgme4++KXb3xsq9ffjwwmQo4UB
fglhP4RdEG6GUAahCEIehEwIfpaWC/T1WnqyyMMQsiAEIKi0CuRygYNos8raADHiXX2/MCL6
e5e9WdnA90JvViGA/t6smQCe781a6K9S8EGURb0i/ByM3NMA9/X6T0L2zxLgmV7/CwD29Poj
ABp7s/IBXNmb9Za/yojnIT9PWecm4RzoN4Wze/3zgWxWrz/HT+/+ZIUodS5UlAm5ObgenQSY
meTKSNQU7PWPB5De6y+n1DLKogOPRZTHmidAoJDrgwZ9NYDreazp/af99/q/BPY/g2BBPT5Q
+3kAb2fSf6vS+Q/nPQrEVf7eKh2lh/VhfxJGKXzOvyvzDv/DUBbOPOh/0J/vvzuvX4bku6Dd
d7Aqev03q/3kac3u7/YX+jvzTvpX+af5m/2z/Y2ZkN7rv8p/mDYTNeB68vRBfx0UOBV6kdnr
vzSznzWxxr/Or/mz/OXqYSpfNDZRblneYSoBVJSofTTINzezn+r4vLJ+bNVypTPSNulKaaI0
XgpK6dIoKU1yyDbZIptkg6yTZVmUeZnISHbQy1ZheiPAIdJr+0jk6ZNnuIXQJ0lcByFYJmga
itq5WlI7ZyKujQ4uQrUL1ejZOcF+rJt1RVQITsRRWy2qnTsxOjZc2y/FZ0fLwrVRqe7K+v0Y
390AqVGyqR+jufX9OE6TbkuhvwO9H6Pb7koZQBh7b7uroQF5XKsrPZW2CdbymuofeDQlnyP+
48IzEk2Lbq+dUx/dm9YQLaJIPK2hNnoT/ZXoAWImxsnVA8REQUP9AN9OzJNn03S+vboByE4y
MtBmE5ChLAqATJ6IVEoG9mQiJYMxStCFgB3oAhQAnc6IQowupDMyOh5Tuv3H1cnV+1WV0WQi
dJzRHM9EI2hAY4C3en8oxKiCKq6nVLg+qLKG5bCC/H4gyfMzEtgH+1lBfswqixZ8T5KZJCm5
QFLC6uLw9zT+BI0je5jGkQ004f/HT8vEMO4b07X+ZfrD203ByS0QmqJbVi/zRLsXqur+9V3J
X+QONS1ctIzC5pZoV7ClOro+WK3uH/PyD2S/TLPHBKv3o5cnz63f/7LWUt07RhszOdhc3dBX
WVFfdVFdd1yoq77iBwqroIXV07oqq34gu4pmV9K6qmhdVbSuSq2S1TW5lep9Xf1+GU2kPyzC
YB/R60CHm1ICDRNdlvYJVKEHxgc861MO8QjvQfpwQ9QQnBg1QqBZeVV5VTQL5hnNMtFfV09m
edaPD6QcwnuSWRZItgYnomHRIkpEf6ipNhqYc0U9VZWo1vzDY7aKfli2B01urYY/iHeyAN+R
lGjVD346f+jT1dW1ij66wqsQqo3mzqmNltLrs5IEVTVVN0Ba/nAax7G0/YoyuT8+CJlhaATu
pNVRLIzpP2FpOth1SaRH7JEI3Sp09vnSitqOwAq+AQLs48ia3gK2fSZr+tIz6f6ls6+gJAFh
u0phry9QRK81lgErhZkJqFnzANmWuS1vW1lPZk9eT5lI/89oFyT6d9GltLdgF4c6w6uGBQFo
ZwNK/G8Y1PdYb2oaq7iHIuFwQ3gVTlx8/6cPHhb6BcGuSpa6ihXfOTwgifRVyUJgJBK1dw2z
dSWZWGYXY0oUkohdeHz/gRhC/xfs/On5CmVuZHN0cmVhbQplbmRvYmoKCjE2IDAgb2JqCjE3
NDQyCmVuZG9iagoKMTcgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9C
QUFBQUErQXJpYWwtQm9sZE1UCi9GbGFncyA0Ci9Gb250QkJveFstNjI3IC0zNzYgMjAwMCAx
MDExXS9JdGFsaWNBbmdsZSAwCi9Bc2NlbnQgOTA1Ci9EZXNjZW50IC0yMTEKL0NhcEhlaWdo
dCAxMDEwCi9TdGVtViA4MAovRm9udEZpbGUyIDE1IDAgUj4+CmVuZG9iagoKMTggMCBvYmoK
PDwvTGVuZ3RoIDQxNC9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxdk8tugzAQRfd8
hZftIgKbhxspQkpJImXRh5r2AwhMUqTGIEMW+ft65tJW6gJ0bM/jYA1xtd/sXTfFr75vDjSp
U+daT2N/9Q2pI507F2mj2q6Z5pW8m0s9RHHIPdzGiS57d+pXqyh+C2fj5G/qbt32R7qP4hff
ku/cWd19VIewPlyH4Ysu5CaVRGWpWjqFOk/18FxfKJasxb4Nx910W4SUv4D320DKyFpDpelb
Goe6IV+7M0WrJCnVarcrI3Ltv7MsQ8rx1HzWPoTqEJokmS4DG2GbMafCRcWcgSUmB2+ZC2GT
MFvUkf0HcM68FM6l5hr7KfMjeMdcgQvmDXjJvEUvqbODmwmsE+xzroa/ZQcN/0JiZn+uo+Fv
heFv2UHDv7DM8LfsoOGfSgz8C/bX8E+F4Z9KL/in4gD/lO9Kw9/wHWr45/wtBv451zfwL7iv
mf03zPDPub6Bfyb78M/YwcA/575mvn+Jn/3XzPC3wvAvpC/8rfjAP8fAzJPBo8Oz/TOSqrl6
H8ZRfgCZQ57AztHvPzL0A2fJ8w2bHNIUCmVuZHN0cmVhbQplbmRvYmoKCjE5IDAgb2JqCjw8
L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0JBQUFBQStBcmlhbC1Cb2xk
TVQKL0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciA0NAovV2lkdGhzWzc1MCA3MjIgMzMzIDI3NyA1
NTYgNjEwIDI3NyA3MjIgNjY2IDYxMCA3MjIgNzc3IDYxMCAyNzcgNTU2IDM4OQo2MTAgNjEw
IDYxMCAyNzcgNTU2IDU1NiA2MTAgNTU2IDU1NiA2MTAgNTU2IDU1NiA1NTYgNTU2IDI3NyA3
MjIKNjY2IDMzMyA4ODkgNzIyIDgzMyA3MjIgNjY2IDcyMiAzMzMgNTAwIDU1NiA2MTAgNTU2
IF0KL0ZvbnREZXNjcmlwdG9yIDE3IDAgUgovVG9Vbmljb2RlIDE4IDAgUgo+PgplbmRvYmoK
CjIwIDAgb2JqCjw8L0YxIDE5IDAgUi9GMiAxNCAwIFIvRjMgOSAwIFIKPj4KZW5kb2JqCgoy
MSAwIG9iago8PC9Gb250IDIwIDAgUgovUHJvY1NldFsvUERGL1RleHRdCj4+CmVuZG9iagoK
MSAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDQgMCBSL1Jlc291cmNlcyAyMSAwIFIvTWVk
aWFCb3hbMCAwIDU5NSA4NDJdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdC
L0kgdHJ1ZT4+L0NvbnRlbnRzIDIgMCBSPj4KZW5kb2JqCgo0IDAgb2JqCjw8L1R5cGUvUGFn
ZXMKL1Jlc291cmNlcyAyMSAwIFIKL01lZGlhQm94WyAwIDAgNTk1IDg0MiBdCi9LaWRzWyAx
IDAgUiBdCi9Db3VudCAxPj4KZW5kb2JqCgoyMiAwIG9iago8PC9UeXBlL0NhdGFsb2cvUGFn
ZXMgNCAwIFIKL09wZW5BY3Rpb25bMSAwIFIgL1hZWiBudWxsIG51bGwgMF0KL0xhbmcoZW4p
Cj4+CmVuZG9iagoKMjMgMCBvYmoKPDwvQXV0aG9yPEZFRkYwMDQyMDA2NTAwNzIwMDc0MDAy
MDAwNTcwMDY5MDA2QTAwNkUwMDY1MDA2RT4KL0NyZWF0b3I8RkVGRjAwNTcwMDcyMDA2OTAw
NzQwMDY1MDA3Mj4KL1Byb2R1Y2VyPEZFRkYwMDRGMDA3MDAwNjUwMDZFMDA0RjAwNjYwMDY2
MDA2OTAwNjMwMDY1MDAyRTAwNkYwMDcyMDA2NzAwMjAwMDMzMDAyRTAwMzE+Ci9DcmVhdGlv
bkRhdGUoRDoyMDEyMDkxNzIyMjQzMCswMicwMCcpPj4KZW5kb2JqCgp4cmVmCjAgMjQKMDAw
MDAwMDAwMCA2NTUzNSBmIAowMDAwMDQ2Mjc4IDAwMDAwIG4gCjAwMDAwMDAwMTkgMDAwMDAg
biAKMDAwMDAwMjgxOSAwMDAwMCBuIAowMDAwMDQ2NDIxIDAwMDAwIG4gCjAwMDAwMDI4NDAg
MDAwMDAgbiAKMDAwMDAwNjQ0NCAwMDAwMCBuIAowMDAwMDA2NDY1IDAwMDAwIG4gCjAwMDAw
MDY2NjAgMDAwMDAgbiAKMDAwMDAwNjk1MCAwMDAwMCBuIAowMDAwMDA3MTE0IDAwMDAwIG4g
CjAwMDAwMjY1MzQgMDAwMDAgbiAKMDAwMDAyNjU1NyAwMDAwMCBuIAowMDAwMDI2NzQ3IDAw
MDAwIG4gCjAwMDAwMjcyNTcgMDAwMDAgbiAKMDAwMDAyNzYwNCAwMDAwMCBuIAowMDAwMDQ1
MTMzIDAwMDAwIG4gCjAwMDAwNDUxNTYgMDAwMDAgbiAKMDAwMDA0NTM1MSAwMDAwMCBuIAow
MDAwMDQ1ODM1IDAwMDAwIG4gCjAwMDAwNDYxNzEgMDAwMDAgbiAKMDAwMDA0NjIyMyAwMDAw
MCBuIAowMDAwMDQ2NTIwIDAwMDAwIG4gCjAwMDAwNDY2MTQgMDAwMDAgbiAKdHJhaWxlcgo8
PC9TaXplIDI0L1Jvb3QgMjIgMCBSCi9JbmZvIDIzIDAgUgovSUQgWyA8MjkxQ0E3QTI2NkMx
QTlDMjdBQjJEMTk2QUUzNDEzQ0M+CjwyOTFDQTdBMjY2QzFBOUMyN0FCMkQxOTZBRTM0MTND
Qz4gXQovRG9jQ2hlY2tzdW0gLzQ1MzJGMUY1Qjc2OTA3ODg2RTJGRUQzQTc1NkFBQzA2Cj4+
CnN0YXJ0eHJlZgo0Njg1OQolJUVPRgo=
--------------060202000002090807090308--

From j.schoenwaelder@jacobs-university.de  Wed Sep 26 08:37:11 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FE421F844E for ; Wed, 26 Sep 2012 08:37:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.219
X-Spam-Level: 
X-Spam-Status: No, score=-103.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBwqTEsuUo4r for ; Wed, 26 Sep 2012 08:37:11 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CFB7121F844A for ; Wed, 26 Sep 2012 08:37:10 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 30F0720C13; Wed, 26 Sep 2012 17:37:10 +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 8LD83w9WKaDK; Wed, 26 Sep 2012 17:37:10 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 84D8C20C09; Wed, 26 Sep 2012 17:37:09 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 9BA172204A4E; Wed, 26 Sep 2012 17:37:04 +0200 (CEST)
Date: Wed, 26 Sep 2012 17:37:03 +0200
From: Juergen Schoenwaelder 
To: netconf@ietf.org
Message-ID: <20120926153702.GA59570@elstar.local>
Mail-Followup-To: netconf@ietf.org, Vaibhav Bajpai 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Vaibhav Bajpai 
Subject: [Netconf] rfc 6242 (rfc 4742) ssh port requirement confusing in practice?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2012 15:37:11 -0000

Hi,

while doing interop testing before the interop, we did discover this
wording in RFC 6242 (unchanged from RFC 4742):

   In order to allow NETCONF traffic to be easily identified and
   filtered by firewalls and other network devices, NETCONF servers MUST
   default to providing access to the "netconf" SSH subsystem only when
   the SSH session is established using the IANA-assigned TCP port 830.
   Servers SHOULD be configurable to allow access to the netconf SSH
   subsystem over other ports.

Looking at implementations running as subsystems of openssh, it seems
some are liberal by default (it does not matter which port you used to
connect to the ssh daemon) whilef others try to verify that the port
number used to connect is 830. Checking the port number is likely more
closely following the text above.  However, it seems the MUST really
comes down to how the netconf system is deployed and configured, that
is a careful implementation being fully compliant to the text may be
shipped in a way such that is not fully compliant to the "default only
port 830" text. In other words, the MUST is not an implementation
requirement per se but more of a requirement how the netconf system
has to be configured when the software is shipped.


  It seems the control of which SSH subsystem can be invoked over
  which port number should really reside in openssh, but I think this
  is not really configurable there. Some NETCONF subsystems seem to
  try to figure out which port number was used and then they may drop
  the session while other subsystems do not seem to care.


Why do I write all this? Well, we installed one NETCONF package and
after installation it did allow NETCONF only over port 830 (port 22
sessions were closed before the hello message). A second NETCONF
package did after installation do NETCONF only over port 22 (since the
installation apparently did not reconfigure/restart the SSH daemon to
listen on port 830). For a normal user, this is a rather confusing
experience since at the end one had to provide different port numbers
to talk to both installations. (Things got more complicated because
the log message produced by the NETCONF subsystem of the first package
was just telling us "access denied" and not something like "access
denied on port 22", which would have given us a better clue where the
problem really is.)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From phil@juniper.net  Wed Sep 26 11:53:44 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB7521F84FA for ; Wed, 26 Sep 2012 11:53:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pk1sFAppAVvv for ; Wed, 26 Sep 2012 11:53:39 -0700 (PDT)
Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA9021F8543 for ; Wed, 26 Sep 2012 11:53:39 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUGNPMAPBySHbtnCN7JIs5YMW2aVJLJdv@postini.com; Wed, 26 Sep 2012 11:53:39 PDT
Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 26 Sep 2012 11:53:03 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q8QIr2h53842; Wed, 26 Sep 2012 11:53:02 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q8QIr0lW057453; Wed, 26 Sep 2012 14:53:01 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201209261853.q8QIr0lW057453@idle.juniper.net>
To: Juergen Schoenwaelder 
In-Reply-To: <20120926153702.GA59570@elstar.local>
Date: Wed, 26 Sep 2012 14:53:00 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
Cc: Vaibhav Bajpai , netconf@ietf.org
Subject: Re: [Netconf] rfc 6242 (rfc 4742) ssh port requirement confusing in practice?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2012 18:53:45 -0000

Juergen Schoenwaelder writes:
>  It seems the control of which SSH subsystem can be invoked over
>  which port number should really reside in openssh, but I think this
>  is not really configurable there. Some NETCONF subsystems seem to
>  try to figure out which port number was used and then they may drop
>  the session while other subsystems do not seem to care.

Yup, the server should be counting on the lower layers to get the
port access right.

What we meant in the referenced section of the RFC is that turning
on "netconf" as a service should default to port 830, but the user
should be able to config it to use an alternate port (e.g. 18300).
This is independent of using openssh.

For example, in JUNOS, the configuration:

    [system services]
    netconf {
        ssh;
    }

(where "ssh" is a presence container) makes an inetd.conf file like:

netconf stream tcp nowait/75/150 root /usr/sbin/sshd sshd -i -f /var/etc/sshd_conf -o SubsystemOnly=netconf -o Protocol=2
netconf stream tcp6 nowait/75/150 root /usr/sbin/sshd sshd -i -f /var/etc/sshd_conf -o SubsystemOnly=netconf -o Protocol=2

but you can change the port using:

    [system services]
    netconf {
        ssh {
            port 18300;
        }
    }

To make:

18300 stream tcp nowait/75/150 root /usr/sbin/sshd sshd -i -f /var/etc/sshd_conf -o SubsystemOnly=netconf -o Protocol=2
18300 stream tcp6 nowait/75/150 root /usr/sbin/sshd sshd -i -f /var/etc/sshd_conf -o SubsystemOnly=netconf -o Protocol=2

Thanks,
 Phil

From andy@yumaworks.com  Wed Sep 26 12:48:56 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0D121F8445 for ; Wed, 26 Sep 2012 12:48:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.735
X-Spam-Level: 
X-Spam-Status: No, score=-2.735 tagged_above=-999 required=5 tests=[AWL=0.242,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFzyHV1VGVrg for ; Wed, 26 Sep 2012 12:48:56 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4F26321F8440 for ; Wed, 26 Sep 2012 12:48:56 -0700 (PDT)
Received: by qabj40 with SMTP id j40so1494913qab.10 for ; Wed, 26 Sep 2012 12:48:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=lXyYW5kpz/qwXUz0mxb/GMS2sz9w8HqW2X9eLlvFbp4=; b=PrZyOMKuiIq4nKhZ7p9W15b1K31hMRj6UTy0t3V8QsCdxELITyIyiTxBc/hM4KYylL QtNwaCeWm4bbuGORuYx+P5NSKBbM4i27So9wlwOyt8rs3AiIWQTXD6XolwMeXpVk8Zom dJjx40SWnTLCwmrWgCoXw7z61FgYWE7baln9oCNUO/KaTXrtosQEiNYQSxpz7ErEbEbt Z3VFr/vDKHf1alO6rXHlVmCj6n7RG39luSjBfaCIXY7HitTb6pNcGDCDu+mTOJpZdCMb rppjZLUgPq5YddKAdXiQ/bH61CP1mt1BOUAxaVP5MzUwT9Szf91jr6vEWQY5c3IClwxH U8pA==
MIME-Version: 1.0
Received: by 10.229.77.227 with SMTP id h35mr1067195qck.47.1348688935646; Wed, 26 Sep 2012 12:48:55 -0700 (PDT)
Received: by 10.49.108.231 with HTTP; Wed, 26 Sep 2012 12:48:55 -0700 (PDT)
In-Reply-To: <20120926153702.GA59570@elstar.local>
References: <20120926153702.GA59570@elstar.local>
Date: Wed, 26 Sep 2012 12:48:55 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , netconf@ietf.org, Vaibhav Bajpai 
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQlpsVgGTFL7gv2JnUhsNzA3ccsNY5PyHIBRrEFTrJp7xkv7yhMMrparmkSJfcC+Hr42yMqu
Subject: Re: [Netconf] rfc 6242 (rfc 4742) ssh port requirement confusing in practice?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2012 19:48:57 -0000

On Wed, Sep 26, 2012 at 8:37 AM, Juergen Schoenwaelder
 wrote:
> Hi,
>
> while doing interop testing before the interop, we did discover this
> wording in RFC 6242 (unchanged from RFC 4742):
>
>    In order to allow NETCONF traffic to be easily identified and
>    filtered by firewalls and other network devices, NETCONF servers MUST
>    default to providing access to the "netconf" SSH subsystem only when
>    the SSH session is established using the IANA-assigned TCP port 830.
>    Servers SHOULD be configurable to allow access to the netconf SSH
>    subsystem over other ports.
>
> Looking at implementations running as subsystems of openssh, it seems
> some are liberal by default (it does not matter which port you used to
> connect to the ssh daemon) whilef others try to verify that the port
> number used to connect is 830. Checking the port number is likely more
> closely following the text above.  However, it seems the MUST really
> comes down to how the netconf system is deployed and configured, that
> is a careful implementation being fully compliant to the text may be
> shipped in a way such that is not fully compliant to the "default only
> port 830" text. In other words, the MUST is not an implementation
> requirement per se but more of a requirement how the netconf system
> has to be configured when the software is shipped.
>
> 
>   It seems the control of which SSH subsystem can be invoked over
>   which port number should really reside in openssh, but I think this
>   is not really configurable there. Some NETCONF subsystems seem to
>   try to figure out which port number was used and then they may drop
>   the session while other subsystems do not seem to care.
> 
>
> Why do I write all this? Well, we installed one NETCONF package and
> after installation it did allow NETCONF only over port 830 (port 22
> sessions were closed before the hello message). A second NETCONF
> package did after installation do NETCONF only over port 22 (since the
> installation apparently did not reconfigure/restart the SSH daemon to
> listen on port 830). For a normal user, this is a rather confusing
> experience since at the end one had to provide different port numbers
> to talk to both installations. (Things got more complicated because
> the log message produced by the NETCONF subsystem of the first package
> was just telling us "access denied" and not something like "access
> denied on port 22", which would have given us a better clue where the
> problem really is.)
>

Not that I might have something to do with one of these A or B packages...

There is some old code in Yuma to work-around an OpenSSH bug on MACOSX.
I just checked OpenSSH 5.6p1 and it is fixed now.  I will take the code out
of yuma that allows port 22 on a MAC by default.



> /js

Andy

From j.schoenwaelder@jacobs-university.de  Wed Sep 26 12:56:32 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1FD21F85C0 for ; Wed, 26 Sep 2012 12:56:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.22
X-Spam-Level: 
X-Spam-Status: No, score=-103.22 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QICiXdGjRgYe for ; Wed, 26 Sep 2012 12:56:31 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A101F21F85A7 for ; Wed, 26 Sep 2012 12:56:31 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01F1720C1A; Wed, 26 Sep 2012 21:56:31 +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 t7t-DAiF2LGG; Wed, 26 Sep 2012 21:56:30 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 448DA20C10; Wed, 26 Sep 2012 21:56:30 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 79F5722053AD; Wed, 26 Sep 2012 21:56:25 +0200 (CEST)
Date: Wed, 26 Sep 2012 21:56:25 +0200
From: Juergen Schoenwaelder 
To: Phil Shafer 
Message-ID: <20120926195624.GA60048@elstar.local>
Mail-Followup-To: Phil Shafer , netconf@ietf.org, Vaibhav Bajpai 
References: <20120926153702.GA59570@elstar.local> <201209261853.q8QIr0lW057453@idle.juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201209261853.q8QIr0lW057453@idle.juniper.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Vaibhav Bajpai , netconf@ietf.org
Subject: Re: [Netconf] rfc 6242 (rfc 4742) ssh port requirement confusing in practice?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2012 19:56:32 -0000

On Wed, Sep 26, 2012 at 02:53:00PM -0400, Phil Shafer wrote:
> Juergen Schoenwaelder writes:
> >  It seems the control of which SSH subsystem can be invoked over
> >  which port number should really reside in openssh, but I think this
> >  is not really configurable there. Some NETCONF subsystems seem to
> >  try to figure out which port number was used and then they may drop
> >  the session while other subsystems do not seem to care.
> 
> Yup, the server should be counting on the lower layers to get the
> port access right.
> 
> What we meant in the referenced section of the RFC is that turning
> on "netconf" as a service should default to port 830, but the user
> should be able to config it to use an alternate port (e.g. 18300).
> This is independent of using openssh.
> 
> For example, in JUNOS, the configuration:
> 
>     [system services]
>     netconf {
>         ssh;
>     }
> 
> (where "ssh" is a presence container) makes an inetd.conf file like:
> 
> netconf stream tcp nowait/75/150 root /usr/sbin/sshd sshd -i -f /var/etc/sshd_conf -o SubsystemOnly=netconf -o Protocol=2
> netconf stream tcp6 nowait/75/150 root /usr/sbin/sshd sshd -i -f /var/etc/sshd_conf -o SubsystemOnly=netconf -o Protocol=2
> 
> but you can change the port using:
> 
>     [system services]
>     netconf {
>         ssh {
>             port 18300;
>         }
>     }
> 
> To make:
> 
> 18300 stream tcp nowait/75/150 root /usr/sbin/sshd sshd -i -f /var/etc/sshd_conf -o SubsystemOnly=netconf -o Protocol=2
> 18300 stream tcp6 nowait/75/150 root /usr/sbin/sshd sshd -i -f /var/etc/sshd_conf -o SubsystemOnly=netconf -o Protocol=2

I think I understand the intention of the text in the RFC but with the
two packages we installed today, our experience was lets say somewhat
surprising. We now try the port 830 first, if the connection attempt
fails we try port 22 as a backup.

The way you seem to hook things into inetd seems more sensible than
just hooking the subsystem into the standard sshd itself. Is the
SubsystemOnly option a standard sshd option or a Junos specific
extension? I did not see it in the openssh sources...

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From phil@juniper.net  Wed Sep 26 13:27:32 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34AE21F84D2 for ; Wed, 26 Sep 2012 13:27:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcLEdDzSXdJQ for ; Wed, 26 Sep 2012 13:27:32 -0700 (PDT)
Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 06E3521F84D1 for ; Wed, 26 Sep 2012 13:27:32 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUGNlMYo62eLwQIOadFliPv/W/pyQQ/fN@postini.com; Wed, 26 Sep 2012 13:27:32 PDT
Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 26 Sep 2012 13:25:33 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q8QKPWh64977; Wed, 26 Sep 2012 13:25:32 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q8QKPU9U058651; Wed, 26 Sep 2012 16:25:31 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201209262025.q8QKPU9U058651@idle.juniper.net>
To: Juergen Schoenwaelder 
In-Reply-To: <20120926195624.GA60048@elstar.local>
Date: Wed, 26 Sep 2012 16:25:30 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
Cc: Vaibhav Bajpai , netconf@ietf.org
Subject: Re: [Netconf] rfc 6242 (rfc 4742) ssh port requirement confusing in practice?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2012 20:27:32 -0000

Juergen Schoenwaelder writes:
>The way you seem to hook things into inetd seems more sensible than
>just hooking the subsystem into the standard sshd itself. Is the
>SubsystemOnly option a standard sshd option or a Junos specific
>extension? I did not see it in the openssh sources...

Doh!!  Sorry, yes it's an JUNOS extension.  Should have checked.
I can likely provide a patch if anyone wants it.

Thanks,
 Phil

From cabo@tzi.org  Wed Sep 26 13:35:10 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BFC21F857E for ; Wed, 26 Sep 2012 13:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.829
X-Spam-Level: 
X-Spam-Status: No, score=-104.829 tagged_above=-999 required=5 tests=[AWL=-2.230, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7QGaXD687mr for ; Wed, 26 Sep 2012 13:35:09 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 3F35921F8578 for ; Wed, 26 Sep 2012 13:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q8QKYvsI003867; Wed, 26 Sep 2012 22:34:59 +0200 (CEST)
Message-Id: 
From: Carsten Bormann 
To: Juergen Schoenwaelder 
In-Reply-To: <20120926153702.GA59570@elstar.local>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 26 Sep 2012 22:34:57 +0200
References: <20120926153702.GA59570@elstar.local>
X-Mailer: Apple Mail (2.936)
Cc: Vaibhav Bajpai , netconf@ietf.org
Subject: Re: [Netconf] rfc 6242 (rfc 4742) ssh port requirement confusing in practice?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2012 20:35:10 -0000

On Sep 26 2012, at 17:37, Juergen Schoenwaelder wrote:

>   In order to allow NETCONF traffic to be easily identified and
>   filtered by firewalls and other network devices, NETCONF servers  
> MUST
>   default to providing access to the "netconf" SSH subsystem only when
>   the SSH session is established using the IANA-assigned TCP port 830.
>   Servers SHOULD be configurable to allow access to the netconf SSH
>   subsystem over other ports.

I hope you guys are talking about the DESTINATION port here, not the  
SOURCE port.
(This is not entirely clear from the text; you might want to fix this  
in the process of clarifying it.)

Gruesse, Carsten


From j.schoenwaelder@jacobs-university.de  Wed Sep 26 23:15:32 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE63A21F853E for ; Wed, 26 Sep 2012 23:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.221
X-Spam-Level: 
X-Spam-Status: No, score=-103.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7N+Z2R2WEMZf for ; Wed, 26 Sep 2012 23:15:32 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 02AF421F8523 for ; Wed, 26 Sep 2012 23:15:32 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0450520C13; Thu, 27 Sep 2012 08:15:31 +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 LjEtezQ9zAPM; Thu, 27 Sep 2012 08:15:30 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5CF3520BDB; Thu, 27 Sep 2012 08:15:30 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 633FC220659C; Thu, 27 Sep 2012 08:15:26 +0200 (CEST)
Date: Thu, 27 Sep 2012 08:15:26 +0200
From: Juergen Schoenwaelder 
To: Carsten Bormann 
Message-ID: <20120927061526.GA61001@elstar.local>
Mail-Followup-To: Carsten Bormann , netconf@ietf.org, Vaibhav Bajpai 
References: <20120926153702.GA59570@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: Vaibhav Bajpai , netconf@ietf.org
Subject: Re: [Netconf] rfc 6242 (rfc 4742) ssh port requirement confusing in practice?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Sep 2012 06:15:33 -0000

On Wed, Sep 26, 2012 at 10:34:57PM +0200, Carsten Bormann wrote:
> On Sep 26 2012, at 17:37, Juergen Schoenwaelder wrote:
> 
> >  In order to allow NETCONF traffic to be easily identified and
> >  filtered by firewalls and other network devices, NETCONF servers
> >MUST
> >  default to providing access to the "netconf" SSH subsystem only when
> >  the SSH session is established using the IANA-assigned TCP port 830.
> >  Servers SHOULD be configurable to allow access to the netconf SSH
> >  subsystem over other ports.
> 
> I hope you guys are talking about the DESTINATION port here, not the
> SOURCE port.
> (This is not entirely clear from the text; you might want to fix
> this in the process of clarifying it.)

If you feel strongly, please post an erratum.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From andy@yumaworks.com  Thu Sep 27 13:31:18 2012
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640C621F860D for ; Thu, 27 Sep 2012 13:31:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.766
X-Spam-Level: 
X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=0.210,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRxW3CSnCPc6 for ; Thu, 27 Sep 2012 13:31:17 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5743021F86E0 for ; Thu, 27 Sep 2012 13:31:17 -0700 (PDT)
Received: by qadb10 with SMTP id b10so937953qad.10 for ; Thu, 27 Sep 2012 13:31:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=GDYSHRO7tE0fzRr0XtuEpzety4K78eU/wiUH0LEyFyg=; b=LR8nJXpCHXl96Aahrl0mqy3yNGQ4MRvvdddf1+ChUwbhD9E2h/RXWDHonmudF6fEET pMFsxVoLLH0GSBlotzvru50HudK10qPZWnVmK+FrnGL9QopfZ2Bs3IaIsFILLjneBema WW0+uUndFmyztgbK4N8iGdJOdl+LiZJ2nctl7g1GwO4zS89IVLeLVVCeO/+MU4ohakPy u+VGR4Hxwma2bKQfZs69pViV7V9mu13VWtVlKIfJYE/eOtWylI0v+gd4ThYDUS/oMoti YtwyIAbrmBCwLnjYUuecxwLrpXRd26QLjZpTjGzxP0UFBKmo8pCYai0Xg+9vShuDURVI Fs4w==
MIME-Version: 1.0
Received: by 10.224.180.83 with SMTP id bt19mr12164357qab.82.1348777876650; Thu, 27 Sep 2012 13:31:16 -0700 (PDT)
Received: by 10.49.108.231 with HTTP; Thu, 27 Sep 2012 13:31:16 -0700 (PDT)
In-Reply-To: <20120927202547.12130.75294.idtracker@ietfa.amsl.com>
References: <20120927202547.12130.75294.idtracker@ietfa.amsl.com>
Date: Thu, 27 Sep 2012 13:31:16 -0700
Message-ID: 
From: Andy Bierman 
To: Netconf 
Content-Type: multipart/alternative; boundary=20cf30363f7b37f9c304cab4d216
X-Gm-Message-State: ALoCoQliaRPWXbzPe+PDKmSPKcohXS+XlWd6UHi8DpRl3tgZljxr37hJ9vVmC8vh82zxoQSizb1G
Subject: [Netconf] Fwd: I-D Action: draft-bierman-netconf-get2-01.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Sep 2012 20:31:18 -0000

--20cf30363f7b37f9c304cab4d216
Content-Type: text/plain; charset=UTF-8

FYI,

I updated the  draft based on mailing list comments.


Andy

---------- Forwarded message ----------
From: 
Date: Thu, Sep 27, 2012 at 1:25 PM
Subject: I-D Action: draft-bierman-netconf-get2-01.txt
To: i-d-announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts
directories.


        Title           : The NETCONF  Operation
        Author(s)       : Andy Bierman
        Filename        : draft-bierman-netconf-get2-01.txt
        Pages           : 28
        Date            : 2012-09-27

Abstract:
   This document describes NETCONF protocol enhancements to improve data
   retrieval capabilities.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bierman-netconf-get2

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bierman-netconf-get2-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-bierman-netconf-get2-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--20cf30363f7b37f9c304cab4d216
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

FYI,

I updated the <get2> draft based on mailing list comments=
.


Andy

---------- Forwarded me=
ssage ----------
From:  <internet-drafts@ietf.or=
g>

Date: Thu, Sep 27, 2012 at 1:25 PM
Subject: I-D Action: draft-bierman-ne=
tconf-get2-01.txt
To: i-d-annou=
nce@ietf.org




A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.





=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : The =
NETCONF <get2> Operation

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author(s) =C2=A0 =C2=A0 =C2=A0 : Andy Bierman
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-bie=
rman-netconf-get2-01.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 28
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 2012-09-27



Abstract:

=C2=A0 =C2=A0This document describes NETCONF protocol enhancements to impro=
ve data

=C2=A0 =C2=A0retrieval capabilities.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-bierman-netconf-get2<=
/a>



There's also a htmlized version available at:

http://tools.ietf.org/html/draft-bierman-netconf-get2-01


A diff from the previous version is available at:

http://www.ietf.org/rfcdiff?url2=3Ddraft-bierman-netcon=
f-get2-01





Internet-Drafts are also available by anonymous FTP at:

ftp://ftp=
.ietf.org/internet-drafts/



_______________________________________________

I-D-Announce mailing list

I-D-Announce@ietf.org

https://www.ietf.org/mailman/listinfo/i-d=
-announce

Internet-Draft directories: http://www.ietf.org/shadow.html

or =
ftp://ftp.ietf.org/ietf/1shadow-sites.txt





--20cf30363f7b37f9c304cab4d216--