From kwatsen@juniper.net Fri Jun 3 08:35:50 2011 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 B2CEAE078A for ; Fri, 3 Jun 2011 08:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW6IR4C79zlP for ; Fri, 3 Jun 2011 08:35:50 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id E52B5E0776 for ; Fri, 3 Jun 2011 08:35:49 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTej/VQCAnkqR6h6cpaoGo5cEEeYJsVjQ@postini.com; Fri, 03 Jun 2011 08:35:50 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 3 Jun 2011 08:33:16 -0700 From: Kent Watsen To: "netconf@ietf.org" Date: Fri, 3 Jun 2011 08:33:09 -0700 Thread-Topic: [Netconf] Updating NETCONF over TLS document (RFC5539) Thread-Index: Acwb0VBxCO+j+7orQlGmebF5IPiqLAA3pE0AAVSJv8A= Message-ID: <84600D05C20FF943918238042D7670FD3E80E2766A@EMBX01-HQ.jnpr.net> References: <20110526091458.GB21380@elstar.local> <20110526.112119.600552241751925428.mbj@tail-f.com> <20110526093035.GA21464@elstar.local> <20110526.120112.1416344284371929693.mbj@tail-f.com> <599FC8D7-FA6C-4E2D-A6BF-AF5E8AAD910B@juniper.net> <20110526181824.GA21638@elstar.local> <84600D05C20FF943918238042D7670FD3E7F64D7ED@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3E7F64D7ED@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) 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, 03 Jun 2011 15:35:50 -0000 If we choose to proceed with this RFC, it would be good to reference RFC 61= 25 (Service Identity) as guidance for how the NetConf server's certificate = should be constructed. =20 Regarding client certificates, note the first bullet in section 1.7.2 (Out = of Scope): o Client or end-user identities. Certificates representing client or end-user identities (e.g., the rfc822Name identifier) can be used for mutual authentication between a client and server or between two clients, thus enabling stronger client-server security or end-to-end security. However, certification authorities, application developers, and service operators have less experience with client certificates than with server certificates, thus giving us fewer models from which to generalize and a less solid basis for defining best practices. Kent From j.schoenwaelder@jacobs-university.de Sun Jun 5 23:50:01 2011 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 C386C11E8095 for ; Sun, 5 Jun 2011 23:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7wKd1Od+-Lr for ; Sun, 5 Jun 2011 23:50:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4E15E11E8087 for ; Sun, 5 Jun 2011 23:50:00 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7BA7320BD7 for ; Mon, 6 Jun 2011 08:49:59 +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 iwxfzIoeWa0I; Mon, 6 Jun 2011 08:49:59 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB7C72092C; Mon, 6 Jun 2011 08:49:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 10F1D18DF293; Mon, 6 Jun 2011 08:49:56 +0200 (CEST) Date: Mon, 6 Jun 2011 08:49:56 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20110606064955.GC23643@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Netconf] NETCONF on Constrained Devices (NETCONF Light) 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, 06 Jun 2011 06:50:01 -0000 Hi, at the last IETF, we demoed some work to fit NETCONF on small embedded resource constrained devices running Contiki. We have meanwhile made some more progress and we started to write up an I-D that defines what we currently call 'NETCONF Light'. /js ---8<---8<--- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Configuration Protocol for Constrained Devices (NETCONF Light) Author(s) : Vladislav Perelman Juergen Schoenwaelder Mehmet Ersue Filename : draft-schoenw-netconf-light-00.txt Pages : 12 Date : 2011-06-05 This document describes a profile of the NETCONF protocol for resource constrained devices, called NETCONF Light. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schoenw-netconf-light-00.txt ---8<---8<--- -- 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 Tue Jun 7 14:37:56 2011 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 CADD011E81AD for ; Tue, 7 Jun 2011 14:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAkwqHfHWizp for ; Tue, 7 Jun 2011 14:37:53 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by ietfa.amsl.com (Postfix) with ESMTP id 5474111E819F for ; Tue, 7 Jun 2011 14:37:53 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id A6F8B76C3B7 for ; Tue, 7 Jun 2011 23:37:51 +0200 (CEST) Date: Tue, 07 Jun 2011 23:37:50 +0200 (CEST) Message-Id: <20110607.233750.183255982.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Netconf] AUTH48 issues for 4741bis 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, 07 Jun 2011 21:37:56 -0000 Hi, 4741bis is now in AUTH48, and we (the editors and the RFC editor) found some issues. Below are proposed changes for two non-editorial clarifications. In section 7.5, we forgot to add explicit text about what happens if someone tries to take a lock on running while there's an ongoing confirmed commit. This was discussed in http://www.ietf.org/mail-archive/web/netconf/current/msg05468.html. A lock must be honored by the server, and a confirming commit might timeout and change running. OLD: A lock MUST NOT be granted if either of the following conditions is true: * A lock is already held by any NETCONF session or another entity. * The target configuration is , it has already been modified, and these changes have not been committed or rolled back. NEW: A lock MUST NOT be granted if either of the following conditions is true: * A lock is already held by any NETCONF session or another entity. * The target configuration is , it has already been modified, and these changes have not been committed or rolled back. * The target configuration is , and another NETCONF session has an ongoing confirmed commit (Section 8.4). In Security Considerations, the last sentence of this paragraph is bad: OLD: In addition, operations on configurations could have unintended consequences if those operations are also not guarded by the global lock on the files or objects being operated upon. For instance, a partially complete access list could be committed from a candidate configuration unbeknownst to the owner of the lock of the candidate configuration, leading to either an insecure or inaccessible device if the lock on the candidate configuration does not also apply to the operation when applied to it. NEW: In addition, operations on configurations could have unintended consequences if those operations are also not guarded by the global lock on the files or objects being operated upon. For instance, if the running configuration is not locked, a partially complete access list could be committed from a candidate configuration unbeknownst to the owner of the lock of the candidate configuration, leading to either an insecure or inaccessible device. /martin From bertietf@bwijnen.net Tue Jun 7 15:20:23 2011 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 B855511E80CC for ; Tue, 7 Jun 2011 15:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.503 X-Spam-Level: X-Spam-Status: No, score=-100.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, 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 cZJerzWlMlXR for ; Tue, 7 Jun 2011 15:20:23 -0700 (PDT) Received: from relay61.tele2.vuurwerk.nl (relay61.tele2.vuurwerk.nl [62.250.3.61]) by ietfa.amsl.com (Postfix) with ESMTP id C50C311E8072 for ; Tue, 7 Jun 2011 15:20:21 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1QU4dH-0003N6-Sh for netconf@ietf.org; Wed, 08 Jun 2011 00:20:20 +0200 Message-ID: <22245ABFAFB3415EAF07FBFE7C678F78@BertLaptop> From: "Bert Wijnen \(IETF\)" To: References: <20110607.233750.183255982.mbj@tail-f.com> In-Reply-To: <20110607.233750.183255982.mbj@tail-f.com> Date: Wed, 8 Jun 2011 00:19:42 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6002.18417 Subject: Re: [Netconf] AUTH48 issues for 4741bis 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, 07 Jun 2011 22:20:23 -0000 As document shepherd, I believe that these are indeed good clarifications adn so I propose to approve them. Pls shout ASAP (in the next few days) if you see any issues. Thanks, Bert Wijnen document shepherd ----- Original Message ----- From: "Martin Bjorklund" To: Sent: Tuesday, June 07, 2011 11:37 PM Subject: [Netconf] AUTH48 issues for 4741bis > Hi, > > 4741bis is now in AUTH48, and we (the editors and the RFC editor) > found some issues. Below are proposed changes for two non-editorial > clarifications. > > > In section 7.5, we forgot to add explicit text about what happens if > someone tries to take a lock on running while there's an ongoing > confirmed commit. This was discussed in > http://www.ietf.org/mail-archive/web/netconf/current/msg05468.html. > A lock must be honored by the server, and a confirming commit might > timeout and change running. > > > OLD: > > A lock MUST NOT be granted if either of the following conditions > is true: > > * A lock is already held by any NETCONF session or another > entity. > > * The target configuration is , it has already been > modified, and these changes have not been committed or rolled > back. > > NEW: > > A lock MUST NOT be granted if either of the following conditions > is true: > > * A lock is already held by any NETCONF session or another > entity. > > * The target configuration is , it has already been > modified, and these changes have not been committed or rolled > back. > > * The target configuration is , and another NETCONF > session has an ongoing confirmed commit (Section 8.4). > > > In Security Considerations, the last sentence of this paragraph is > bad: > > > OLD: > > In addition, operations on configurations could have unintended > consequences if those operations are also not guarded by the global > lock on the files or objects being operated upon. For instance, a > partially complete access list could be committed from a candidate > configuration unbeknownst to the owner of the lock of the candidate > configuration, leading to either an insecure or inaccessible device > if the lock on the candidate configuration does not also apply to the > operation when applied to it. > > NEW: > > In addition, operations on configurations could have unintended > consequences if those operations are also not guarded by the global > lock on the files or objects being operated upon. For instance, if > the running configuration is not locked, a partially complete > access list could be committed from a candidate configuration > unbeknownst to the owner of the lock of the candidate > configuration, leading to either an insecure or inaccessible > device. > > > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From randy_presuhn@mindspring.com Tue Jun 7 17:48:33 2011 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 DEDE011E8153 for ; Tue, 7 Jun 2011 17:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.309 X-Spam-Level: X-Spam-Status: No, score=-100.309 tagged_above=-999 required=5 tests=[AWL=2.290, 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 DqITHJc5CjaX for ; Tue, 7 Jun 2011 17:48:33 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id ECCA311E8149 for ; Tue, 7 Jun 2011 17:48:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=jJH9z9hINHheb2wE4NkkMQT+knYxxJvcZfu2E9bud60Atsxe9IZM0VwMRNKn56iq; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.55.175.181] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QU6wi-0002OV-Ac for netconf@ietf.org; Tue, 07 Jun 2011 20:48:32 -0400 Message-ID: <001a01cc2576$53c21a20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20110607.233750.183255982.mbj@tail-f.com> Date: Tue, 7 Jun 2011 17:52:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888cc964a8bf633b3821fd6a82d4b1ab0f0a1a7b90366379918350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.55.175.181 Subject: Re: [Netconf] AUTH48 issues for 4741bis 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, 08 Jun 2011 00:48:34 -0000 Hi - Two comments, purely on the English. > From: "Martin Bjorklund" > To: > Sent: Tuesday, June 07, 2011 2:37 PM > Subject: [Netconf] AUTH48 issues for 4741bis > > Hi, > > 4741bis is now in AUTH48, and we (the editors and the RFC editor) > found some issues. Below are proposed changes for two non-editorial > clarifications. > > > In section 7.5, we forgot to add explicit text about what happens if > someone tries to take a lock on running while there's an ongoing > confirmed commit. This was discussed in > http://www.ietf.org/mail-archive/web/netconf/current/msg05468.html. > A lock must be honored by the server, and a confirming commit might > timeout and change running. > > > OLD: > > A lock MUST NOT be granted if either of the following conditions > is true: > > * A lock is already held by any NETCONF session or another > entity. > > * The target configuration is , it has already been > modified, and these changes have not been committed or rolled > back. > > NEW: > > A lock MUST NOT be granted if either of the following conditions > is true: > > * A lock is already held by any NETCONF session or another > entity. > > * The target configuration is , it has already been > modified, and these changes have not been committed or rolled > back. > > * The target configuration is , and another NETCONF > session has an ongoing confirmed commit (Section 8.4). The use of "either" sounds odd to me. Using "any" instead of "either" for the three-item list would make my ears happier. > In Security Considerations, the last sentence of this paragraph is > bad: > > > OLD: > > In addition, operations on configurations could have unintended > consequences if those operations are also not guarded by the global > lock on the files or objects being operated upon. For instance, a > partially complete access list could be committed from a candidate > configuration unbeknownst to the owner of the lock of the candidate > configuration, leading to either an insecure or inaccessible device > if the lock on the candidate configuration does not also apply to the > operation when applied to it. > > NEW: > > In addition, operations on configurations could have unintended > consequences if those operations are also not guarded by the global > lock on the files or objects being operated upon. For instance, if > the running configuration is not locked, a partially complete > access list could be committed from a candidate configuration > unbeknownst to the owner of the lock of the candidate > configuration, leading to either an insecure or inaccessible > device. I find the new text confusing. (Not that I understoof the old text. :-) It talks about both "a candidate" and "the candidate" (as did the old). Do you intend "the candidate" to mean "that candidate", or possibly something else? Randy From mbj@tail-f.com Tue Jun 7 22:59:36 2011 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 88A3B11E8082 for ; Tue, 7 Jun 2011 22:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYdmV-t1Af7x for ; Tue, 7 Jun 2011 22:59:36 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by ietfa.amsl.com (Postfix) with ESMTP id C9B2A11E8071 for ; Tue, 7 Jun 2011 22:59:34 -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 164F5616005; Wed, 8 Jun 2011 07:59:33 +0200 (CEST) Date: Wed, 08 Jun 2011 07:59:32 +0200 (CEST) Message-Id: <20110608.075932.2037182093515132184.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <001a01cc2576$53c21a20$6801a8c0@oemcomputer> References: <20110607.233750.183255982.mbj@tail-f.com> <001a01cc2576$53c21a20$6801a8c0@oemcomputer> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / 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] AUTH48 issues for 4741bis 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, 08 Jun 2011 05:59:36 -0000 "Randy Presuhn" wrote: > > In Security Considerations, the last sentence of this paragraph is > > bad: > > > > > > OLD: > > > > In addition, operations on configurations could have unintended > > consequences if those operations are also not guarded by the global > > lock on the files or objects being operated upon. For instance, a > > partially complete access list could be committed from a candidate > > configuration unbeknownst to the owner of the lock of the candidate > > configuration, leading to either an insecure or inaccessible device > > if the lock on the candidate configuration does not also apply to the > > operation when applied to it. > > > > NEW: > > > > In addition, operations on configurations could have unintended > > consequences if those operations are also not guarded by the global > > lock on the files or objects being operated upon. For instance, if > > the running configuration is not locked, a partially complete > > access list could be committed from a candidate configuration > > unbeknownst to the owner of the lock of the candidate > > configuration, leading to either an insecure or inaccessible > > device. > > I find the new text confusing. (Not that I understoof the old text. :-) > It talks about both "a candidate" and "the candidate" (as did the old). > Do you intend "the candidate" to mean "that candidate", or possibly > something else? I think it should be "the candidate". Searching for "a candidate" reveals: 8.3.4.1. Description: When a candidate configuration's content is complete, the configuration data can be committed, publishing the data set to the rest of the device and requesting the device to conform to the behavior described in the new configuration. I believe this should also be "the candidate". /martin From kwatsen@juniper.net Wed Jun 8 14:08:00 2011 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 B707321F8583 for ; Wed, 8 Jun 2011 14:08:00 -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 cvNmQqyn6UE9 for ; Wed, 8 Jun 2011 14:07:59 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id F0A7021F8586 for ; Wed, 8 Jun 2011 14:07:58 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTe/kqx/r1YSN1OgwsUvWurX3LrkLABlb@postini.com; Wed, 08 Jun 2011 14:07:59 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 8 Jun 2011 14:05:42 -0700 From: Kent Watsen To: Juergen Schoenwaelder , "netconf@ietf.org" Date: Wed, 8 Jun 2011 14:05:40 -0700 Thread-Topic: [Netconf] NETCONF on Constrained Devices (NETCONF Light) Thread-Index: AcwkFgiB9mlM31LGQpyD6n7db54tDQCApmhQ Message-ID: <84600D05C20FF943918238042D7670FD3E81BD017A@EMBX01-HQ.jnpr.net> References: <20110606064955.GC23643@elstar.local> In-Reply-To: <20110606064955.GC23643@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] NETCONF on Constrained Devices (NETCONF Light) 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, 08 Jun 2011 21:08:00 -0000 This I-D interests me, but not for resource-constrained devices... One of my roles at Juniper is to help recently acquired and OEM-ed devices = implement NetConf plus our vendor-specific capabilities, in order to be man= aged by our NMS products. My experience is that we can implement the basic= layer, plus our vendor-specific RPCs, and maybe even support for "co= nfig-text" within the first release cycle and that full XML-based configura= tion (including schema to describe the data-model) may take another year. So, as part of a 1-2 year phased implementation, we commonly release device= s that don't implement the full NetConf stack (accordingly, we don't Market= them as supporting NetConf or let them listen on port 830). Even though t= hese releases have "incomplete" NetConf implementations, customers apprecia= te being able to manage them from our centralized NMS solution so quickly, = and we appreciate that it's a logical stepping-stone to a complete implemen= tation. In order to "advertize" that the device doesn't support XML-based configura= tion, we simply don't publish a schema to describe its configuration since,= without the schema, our NMS is unable to manage the configuration anyway. = We view this as like publishing an empty schema, which then allows all the= standard NetConf operations to be implemented as no-ops. =20 That said, I've always wished for a more explicit mechanism for a device to= advertize which (if any) of the standard NetConf operations it supports, w= hich is very close to what your "NetConf Light" idea is about. Perhaps the= re is an opportunity to combine these ideas together? Thanks, Kent -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Juergen Schoenwaelder Sent: Monday, June 06, 2011 2:50 AM To: netconf@ietf.org Subject: [Netconf] NETCONF on Constrained Devices (NETCONF Light) Hi, at the last IETF, we demoed some work to fit NETCONF on small embedded resource constrained devices running Contiki. We have meanwhile made some more progress and we started to write up an I-D that defines what we currently call 'NETCONF Light'. /js ---8<---8<--- A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Network Configuration Protocol for Constrained Devices (= NETCONF Light) Author(s) : Vladislav Perelman Juergen Schoenwaelder Mehmet Ersue Filename : draft-schoenw-netconf-light-00.txt Pages : 12 Date : 2011-06-05 This document describes a profile of the NETCONF protocol for resource constrained devices, called NETCONF Light. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schoenw-netconf-light-00.txt ---8<---8<--- --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From kwatsen@juniper.net Wed Jun 8 16:46:13 2011 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 8915021F853F for ; Wed, 8 Jun 2011 16:46:13 -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 dOGZTQJ8u4Og for ; Wed, 8 Jun 2011 16:46:13 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id C5E8021F853E for ; Wed, 8 Jun 2011 16:46:12 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTfAJxFkkP+xca+NYvG2fTrhqr2Q+PLNi@postini.com; Wed, 08 Jun 2011 16:46:12 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; Wed, 8 Jun 2011 16:45:02 -0700 From: Kent Watsen To: "netconf@ietf.org" Date: Wed, 8 Jun 2011 16:45:01 -0700 Thread-Topic: draft-kwatsen-reverse-ssh-01 submission for review Thread-Index: AcwmNexl1MkTfarBS+uDUm42L3SQIQAAA0UQ Message-ID: <84600D05C20FF943918238042D7670FD3E81EA116C@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Netconf] FW: draft-kwatsen-reverse-ssh-01 submission for review 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, 08 Jun 2011 23:46:13 -0000 FYI -----Original Message----- From: Kent Watsen=20 Sent: Wednesday, June 08, 2011 7:44 PM To: saag@ietf.org; ietf-ssh@NetBSD.org Subject: draft-kwatsen-reverse-ssh-01 submission for review I've updated the Reverse SSH draft per suggestions: - now uses IANA-assigned SSH port 22 - now defines proper client and server roles (Reverse SSH client, Rever= se SSH server) - now uses in-band negotiation to automatically authenticate the SSH Se= rver's host key=20 Key aspects used to achieve this update include: - contextual awareness to set SSH client/server roles - definition of a new family of public host key algorithms (hmac-*) My own thoughts: - I like how now the host key and MAC algorithm are negotiated for hmac= -* use - I'm glad to find a solution minimizing the impact to existing SSH imp= lementations Link: - http://tools.ietf.org/html/draft-kwatsen-reverse-ssh-01 Thanks, Kent From ietf@andybierman.com Thu Jun 9 10:01:10 2011 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 1FF3911E818A for ; Thu, 9 Jun 2011 10:01:10 -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 h4SBzJZPDEpt for ; Thu, 9 Jun 2011 10:01:09 -0700 (PDT) Received: from omr1.networksolutionsemail.com (omr1.networksolutionsemail.com [205.178.146.51]) by ietfa.amsl.com (Postfix) with ESMTP id 871D311E8180 for ; Thu, 9 Jun 2011 10:00:58 -0700 (PDT) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p59H0vqd006646 for ; Thu, 9 Jun 2011 13:00:57 -0400 Authentication-Results: cm-omr14 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:39721] helo=[192.168.0.22]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 1D/F5-19565-84CF0FD4; Thu, 09 Jun 2011 13:00:57 -0400 Message-ID: <4DF0FC6A.6050409@andybierman.com> Date: Thu, 09 Jun 2011 10:01:30 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kent Watsen References: <20110606064955.GC23643@elstar.local> <84600D05C20FF943918238042D7670FD3E81BD017A@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3E81BD017A@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] NETCONF on Constrained Devices (NETCONF Light) 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, 09 Jun 2011 17:01:10 -0000 On 06/08/2011 02:05 PM, Kent Watsen wrote: > > This I-D interests me, but not for resource-constrained devices... > > One of my roles at Juniper is to help recently acquired and OEM-ed devices implement NetConf plus our vendor-specific capabilities, in order to be managed by our NMS products. My experience is > that we can implement the basic layer, plus our vendor-specific RPCs, and maybe even support for "config-text" within the first release cycle and that full XML-based configuration (including > schema to describe the data-model) may take another year. > > So, as part of a 1-2 year phased implementation, we commonly release devices that don't implement the full NetConf stack (accordingly, we don't Market them as supporting NetConf or let them listen > on port 830). Even though these releases have "incomplete" NetConf implementations, customers appreciate being able to manage them from our centralized NMS solution so quickly, and we appreciate > that it's a logical stepping-stone to a complete implementation. > > In order to "advertize" that the device doesn't support XML-based configuration, we simply don't publish a schema to describe its configuration since, without the schema, our NMS is unable to > manage the configuration anyway. We view this as like publishing an empty schema, which then allows all the standard NetConf operations to be implemented as no-ops. > > That said, I've always wished for a more explicit mechanism for a device to advertize which (if any) of the standard NetConf operations it supports, which is very close to what your "NetConf > Light" idea is about. Perhaps there is an opportunity to combine these ideas together? > I like NETCONF Light for constrained devices where the config is so small that it doesn't need to be managed in sections, as if it were a CLI. Some devices will be so simple that they just know how to restart and re-read the entire config file. Alternate data formats for NETCONF is another matter entirely. Maybe v2 down the road, client and server should advertise a set of 'format capabilities', perhaps MIME types, like application/xml, text/plain, application/json, application/junos-text, and the session will use the first client choice the server supports. I think several implementations support their own text .conf file format. Everybody has their own text config file format! (That's why linux is so great and why it also sucks ;-) > Thanks, Kent Andy > > > > -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Monday, June 06, 2011 2:50 AM To: netconf@ietf.org Subject: > [Netconf] NETCONF on Constrained Devices (NETCONF Light) > > Hi, > > at the last IETF, we demoed some work to fit NETCONF on small embedded resource constrained devices running Contiki. We have meanwhile made some more progress and we started to write up an I-D > that defines what we currently call 'NETCONF Light'. > > /js > > ---8<---8<--- > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Network Configuration Protocol for Constrained Devices (NETCONF Light) Author(s) : Vladislav Perelman Juergen Schoenwaelder Mehmet Ersue Filename : > draft-schoenw-netconf-light-00.txt Pages : 12 Date : 2011-06-05 > > This document describes a profile of the NETCONF protocol for resource constrained devices, called NETCONF Light. > > > A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schoenw-netconf-light-00.txt > > ---8<---8<--- > From kwatsen@juniper.net Thu Jun 9 11:29:49 2011 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 3CAEB11E81EA for ; Thu, 9 Jun 2011 11:29:49 -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 NH+6ghUzhI6F for ; Thu, 9 Jun 2011 11:29:48 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 3C81911E80F3 for ; Thu, 9 Jun 2011 11:29:48 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTfERGv8qZ5xH3QOGLeICeuIhxa1JKPRv@postini.com; Thu, 09 Jun 2011 11:29:48 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 9 Jun 2011 11:28:58 -0700 From: Kent Watsen To: Andy Bierman Date: Thu, 9 Jun 2011 11:28:48 -0700 Thread-Topic: config-text (was: NETCONF Light) Thread-Index: Acwmxs/934mza7u/RQiirMQ9WarLiAACrVmg Message-ID: <84600D05C20FF943918238042D7670FD3E81EA1701@EMBX01-HQ.jnpr.net> References: <20110606064955.GC23643@elstar.local> <84600D05C20FF943918238042D7670FD3E81BD017A@EMBX01-HQ.jnpr.net> <4DF0FC6A.6050409@andybierman.com> In-Reply-To: <4DF0FC6A.6050409@andybierman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {3373F538-6A93-4D13-A555-94411F61B024} x-cr-hashedpuzzle: AVxl BAiF DGx2 IIqw J1pK LWGc ND3x Ngz1 Nwb7 PnLf PvAK QWe9 R8Z+ R9FE T/In UTmi; 2; aQBlAHQAZgBAAGEAbgBkAHkAYgBpAGUAcgBtAGEAbgAuAGMAbwBtADsAbgBlAHQAYwBvAG4AZgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {3373F538-6A93-4D13-A555-94411F61B024}; awB3AGEAdABzAGUAbgBAAGoAdQBuAGkAcABlAHIALgBuAGUAdAA=; Thu, 09 Jun 2011 18:28:48 GMT; YwBvAG4AZgBpAGcALQB0AGUAeAB0ACAAKAB3AGEAcwA6ACAATgBFAFQAQwBPAE4ARgAgAEwAaQBnAGgAdAApAA== acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: [Netconf] config-text (was: NETCONF Light) 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, 09 Jun 2011 18:29:49 -0000 > Alternate data formats for NETCONF is another matter entirely. > Maybe v2 down the road, client and server should advertise > a set of 'format capabilities', perhaps MIME types, > like application/xml, text/plain, application/json, application/junos-tex= t, > and the session will use the first client choice the server supports. > > I think several implementations support their own text .conf file format. > Everybody has their own text config file format! We defined an vendor-specific capability (http://xml.juniper.net/dmi/config= -text/1.0) to enable get-config/edit-config/copy-config to act on the devic= e's native config file format. If the WG is interested, I could submit an = I-D for it... Do you really think the format needs to be negotiated? - isn't just letting= it be the device's native ASCII format sufficient? - do you think we coul= d get 3rd-party devices to return application/junos-text? ;) =20 From ietf@andybierman.com Thu Jun 9 12:46:49 2011 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 DBF6611E8105 for ; Thu, 9 Jun 2011 12:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 JzGDWQYvTOlM for ; Thu, 9 Jun 2011 12:46:49 -0700 (PDT) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id 050E111E80E2 for ; Thu, 9 Jun 2011 12:46:48 -0700 (PDT) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p59JklRg010751 for ; Thu, 9 Jun 2011 15:46:47 -0400 Authentication-Results: cm-omr7 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:33455] helo=[192.168.0.22]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 34/CD-22544-72321FD4; Thu, 09 Jun 2011 15:46:47 -0400 Message-ID: <4DF1234D.30107@andybierman.com> Date: Thu, 09 Jun 2011 12:47:25 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kent Watsen References: <20110606064955.GC23643@elstar.local> <84600D05C20FF943918238042D7670FD3E81BD017A@EMBX01-HQ.jnpr.net> <4DF0FC6A.6050409@andybierman.com> <84600D05C20FF943918238042D7670FD3E81EA1701@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3E81EA1701@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] config-text 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, 09 Jun 2011 19:46:50 -0000 On 06/09/2011 11:28 AM, Kent Watsen wrote: > >> Alternate data formats for NETCONF is another matter entirely. Maybe v2 down the road, client and server should advertise a set of 'format capabilities', perhaps MIME types, like >> application/xml, text/plain, application/json, application/junos-text, and the session will use the first client choice the server supports. >> >> I think several implementations support their own text .conf file format. Everybody has their own text config file format! > > > We defined an vendor-specific capability (http://xml.juniper.net/dmi/config-text/1.0) to enable get-config/edit-config/copy-config to act on the device's native config file format. If the WG is > interested, I could submit an I-D for it... > > Do you really think the format needs to be negotiated? - isn't just letting it be the device's native ASCII format sufficient? - do you think we could get 3rd-party devices to return > application/junos-text? ;) > > > > > I am not that interested in undocumented ad-hoc formats. The desired format is an application developer decision. Publishing a specification for junos-text would be for the benefit of 3rd party application developers, not other server vendors. I think that letting the client pick the encoding is better than assuming the application wants native CLI text. Andy From bertietf@bwijnen.net Fri Jun 10 03:46:44 2011 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 214C221F84A7 for ; Fri, 10 Jun 2011 03:46:44 -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 LInLHdjaSRH2 for ; Fri, 10 Jun 2011 03:46:43 -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 52C6821F849F for ; Fri, 10 Jun 2011 03:46:35 -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 1QUzES-0005cr-E1; Fri, 10 Jun 2011 12:46:29 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest178.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1QUzES-0001fA-AI; Fri, 10 Jun 2011 12:46:28 +0200 Message-ID: <4DF1F604.2060106@bwijnen.net> Date: Fri, 10 Jun 2011 12:46:28 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Martin Bjorklund References: <20110607.233750.183255982.mbj@tail-f.com> <001a01cc2576$53c21a20$6801a8c0@oemcomputer> <20110608.075932.2037182093515132184.mbj@tail-f.com> In-Reply-To: <20110608.075932.2037182093515132184.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 86ab03e524994f79ca2c75a176445dd4a60c2fd327a9e504de66488d67fb8859 Cc: netconf@ietf.org Subject: Re: [Netconf] AUTH48 issues for 4741bis 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, 10 Jun 2011 10:46:44 -0000 We only had the below comment from Randy, and we'll process it as suggested by MArtin. Martin, pls go ahead and send the edits to the RFC-Editor. Bert document shepherd. On 6/8/11 7:59 AM, Martin Bjorklund wrote: > "Randy Presuhn" wrote: >>> In Security Considerations, the last sentence of this paragraph is >>> bad: >>> >>> >>> OLD: >>> >>> In addition, operations on configurations could have unintended >>> consequences if those operations are also not guarded by the global >>> lock on the files or objects being operated upon. For instance, a >>> partially complete access list could be committed from a candidate >>> configuration unbeknownst to the owner of the lock of the candidate >>> configuration, leading to either an insecure or inaccessible device >>> if the lock on the candidate configuration does not also apply to the >>> operation when applied to it. >>> >>> NEW: >>> >>> In addition, operations on configurations could have unintended >>> consequences if those operations are also not guarded by the global >>> lock on the files or objects being operated upon. For instance, if >>> the running configuration is not locked, a partially complete >>> access list could be committed from a candidate configuration >>> unbeknownst to the owner of the lock of the candidate >>> configuration, leading to either an insecure or inaccessible >>> device. >> I find the new text confusing. (Not that I understoof the old text. :-) >> It talks about both "a candidate" and "the candidate" (as did the old). >> Do you intend "the candidate" to mean "that candidate", or possibly >> something else? > I think it should be "the candidate". > > Searching for "a candidate" reveals: > > 8.3.4.1. > > Description: > > When a candidate configuration's content is complete, the > configuration data can be committed, publishing the data set to > the rest of the device and requesting the device to conform to > the behavior described in the new configuration. > > I believe this should also be "the candidate". > > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From bertietf@bwijnen.net Fri Jun 10 03:47:57 2011 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 57AE921F84A3 for ; Fri, 10 Jun 2011 03:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 NsJg1HolfRJw for ; Fri, 10 Jun 2011 03:47:56 -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 8BE2D21F84A4 for ; Fri, 10 Jun 2011 03:47:54 -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 1QUzFn-0005dq-HS; Fri, 10 Jun 2011 12:47:53 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest178.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1QUzFm-0001kd-Tt; Fri, 10 Jun 2011 12:47:51 +0200 Message-ID: <4DF1F656.1050909@bwijnen.net> Date: Fri, 10 Jun 2011 12:47:50 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Martin Bjorklund References: <20110607.233750.183255982.mbj@tail-f.com> <001a01cc2576$53c21a20$6801a8c0@oemcomputer> In-Reply-To: <001a01cc2576$53c21a20$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 86ab03e524994f79ca2c75a176445dd4e8eceaeedd782c49eb57b212c47772d6 Cc: netconf@ietf.org Subject: Re: [Netconf] AUTH48 issues for 4741bis 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, 10 Jun 2011 10:47:57 -0000 Martin, pls also include the below English language fix. Bert document shepherd On 6/8/11 2:52 AM, Randy Presuhn wrote: > Hi - > > Two comments, purely on the English. > >> > From: "Martin Bjorklund" >> > To: >> > Sent: Tuesday, June 07, 2011 2:37 PM >> > Subject: [Netconf] AUTH48 issues for 4741bis >> > >> > Hi, >> > >> > 4741bis is now in AUTH48, and we (the editors and the RFC editor) >> > found some issues. Below are proposed changes for two non-editorial >> > clarifications. >> > >> > >> > In section 7.5, we forgot to add explicit text about what happens if >> > someone tries to take a lock on running while there's an ongoing >> > confirmed commit. This was discussed in >> > http://www.ietf.org/mail-archive/web/netconf/current/msg05468.html. >> > A lock must be honored by the server, and a confirming commit might >> > timeout and change running. >> > >> > >> > OLD: >> > >> > A lock MUST NOT be granted if either of the following conditions >> > is true: >> > >> > * A lock is already held by any NETCONF session or another >> > entity. >> > >> > * The target configuration is, it has already been >> > modified, and these changes have not been committed or rolled >> > back. >> > >> > NEW: >> > >> > A lock MUST NOT be granted if either of the following conditions >> > is true: >> > >> > * A lock is already held by any NETCONF session or another >> > entity. >> > >> > * The target configuration is, it has already been >> > modified, and these changes have not been committed or rolled >> > back. >> > >> > * The target configuration is, and another NETCONF >> > session has an ongoing confirmed commit (Section 8.4). > The use of "either" sounds odd to me. Using "any" instead of "either" > for the three-item list would make my ears happier. > From dromasca@avaya.com Sun Jun 12 08:15:21 2011 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 6213B11E80A1; Sun, 12 Jun 2011 08:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.761 X-Spam-Level: X-Spam-Status: No, score=-101.761 tagged_above=-999 required=5 tests=[AWL=-0.577, BAYES_40=-0.185, 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 drVbOER2x9iw; Sun, 12 Jun 2011 08:15:20 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id BB6F211E8093; Sun, 12 Jun 2011 08:15:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKDW9E2HCzI1/2dsb2JhbABSpk53rXECmi2GJASWIIpz X-IronPort-AV: E=Sophos;i="4.65,355,1304308800"; d="scan'208";a="284589742" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Jun 2011 11:15:19 -0400 X-IronPort-AV: E=Sophos;i="4.65,355,1304308800"; d="scan'208";a="664313298" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Jun 2011 11:15:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 12 Jun 2011 17:15:17 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing down the NGO mail list Thread-Index: AcwpE4mUlWFMmxeeQV6Z8d3EZ4Kwag== From: "Romascanu, Dan (Dan)" To: "NETMOD Working Group" , "netconf" Subject: [Netconf] Closing down the NGO mail list 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, 12 Jun 2011 15:15:21 -0000 Hi,=20 I asked the IESG secretary to close down the ngo@ietf.org mail list. NGO (NETCONF Goes on) was formed in 2006 and discussed the continuation of the NETCONF work. Discussions on that list contributed to the creation of the NETMOD WG, YANG and other NETCONF related lists. No useful traffic happened on that list for the last three years, and I actually thought that we had closed it until a spam mail last week reminded me about it.=20 Thanks and Regards, Dan=20 From internet-drafts@ietf.org Mon Jun 13 13:19:25 2011 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 241B01F0C72; Mon, 13 Jun 2011 13:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 xvhXWvu7jr4N; Mon, 13 Jun 2011 13:19:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862D41F0C5B; Mon, 13 Jun 2011 13:19:24 -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: 3.55 Message-ID: <20110613201924.27170.92709.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2011 13:19:24 -0700 Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-system-notifications-04.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, 13 Jun 2011 20:19:25 -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 o= f the IETF. Title : Network Configuration Protocol Base Notifications Author(s) : Andy Bierman Filename : draft-ietf-netconf-system-notifications-04.txt Pages : 16 Date : 2011-06-13 The NETCONF protocol provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common events such as a change in NETCONF server capabilities, that may impact management applications. Standard mechanisms are needed to support the monitoring of the base system events within the NETCONF server. This document defines a YANG module that allows a NETCONF client to receive notifications for some common system events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications= -04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications-= 04.txt From bertietf@bwijnen.net Tue Jun 14 13:50:31 2011 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 8C3EC21F8529 for ; Tue, 14 Jun 2011 13:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.503 X-Spam-Level: X-Spam-Status: No, score=-100.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, 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 nmzbv7eL6Y0O for ; Tue, 14 Jun 2011 13:50:30 -0700 (PDT) Received: from relay61.tele2.vuurwerk.nl (relay61.tele2.vuurwerk.nl [62.250.3.61]) by ietfa.amsl.com (Postfix) with ESMTP id 20B9621F8528 for ; Tue, 14 Jun 2011 13:50:30 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1QWaZA-0001dl-L6 for netconf@ietf.org; Tue, 14 Jun 2011 22:50:28 +0200 Message-ID: <3529779803444F278CAA486AD89281A0@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Tue, 14 Jun 2011 22:50:25 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18417 Subject: [Netconf] Fw: Nomcom 2011-12: Call for Volunteers 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, 14 Jun 2011 20:50:32 -0000 Forwarded at the request of our AD. It IS IMPORTANT that we all consider volunteering. We all together need to help choose the proper leadership for the IETF. Bert and Mehmet -------- Original Message -------- Subject: Nomcom 2011-12: Call for Volunteers Date: Fri, 10 Jun 2011 19:56:06 -0700 (PDT) From: NomCom Chair To: IETF Announcement list The IETF nominating committee process for 2011-12 has begun. The IETF nominating committee appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. The 10 nominating committee members are selected randomly from a pool of volunteers. The more volunteers, the better the chance we have of choosing a random yet representative cross section of the IETF population. The details of the nomcom process can be found in RFC 3777. To be eligible, volunteers for the nomcom need to have attended 3 of the past 5 IETF meetings as of the time this announcement goes out (i.e. IETF76-IETF80). If you qualify, and are not seeking appointment to any of the open positions this nomcom will be filling, please consider volunteering. The list of people and posts whose terms end with the March 2012 IETF meeting, and thus the positions for which the nominating committee is responsible, are as follows: IAB === Bernard Aboba Hannes Tschofenig Andrei Robachevsky Olaf Kolkman Spencer Dawkins Ross Callon IAOC ==== Marshall Eubanks IESG ==== Peter Saint-Andre (Applications) Jari Arkko (Internet) Dan Romascanu (Operations & Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) David Harrington (Transport) The primary activity for this nomcom will begin during IETF-81 in Quebec City and should be completed by January 2012. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email to me before 11:59 pm EDT July 10, 2011 as follows: To: suresh.krishnan@ericsson.com Subject: Nomcom 2011-12 Volunteer Please include the following information in the body of the mail: Full Name: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name Current Primary Affiliation: // typically what goes in the Company // field in the IETF Registration Form Email Address(es): // all email addresses used to Register for the // past 5 IETF meetings // Please designate a Preferred email address for // contact if there is more than one email address Telephone number: // With country code (for confirmation if selected) Please expect an email response from me within 3 business days stating whether or not you are qualified. If you do not receive a response in this timeframe, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process within the next few days. Thank you in advance for your participation. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From internet-drafts@ietf.org Wed Jun 15 02:37:32 2011 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 949D211E810F; Wed, 15 Jun 2011 02:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 speN-5Fx+coN; Wed, 15 Jun 2011 02:37:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B6111E809C; Wed, 15 Jun 2011 02:37: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: 3.55 Message-ID: <20110615093732.9980.38403.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2011 02:37:32 -0700 Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-access-control-04.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, 15 Jun 2011 09:37:32 -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 o= f the IETF. Title : Network Configuration Protocol Access Control Model Author(s) : Andy Bierman Martin Bjorklund Filename : draft-ietf-netconf-access-control-04.txt Pages : 52 Date : 2011-06-15 The standardization of network configuration interfaces for use with the NETCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre- configured subset of all available NETCONF operations and content. This document discusses requirements for a suitable access control model, and provides one solution that meets these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-access-control-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netconf-access-control-04.txt From mehmet.ersue@nsn.com Sun Jun 26 06:14:43 2011 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 5F4DB21F8453 for ; Sun, 26 Jun 2011 06:14:43 -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 sXIf30nNdQ-7 for ; Sun, 26 Jun 2011 06:14:42 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 2E15B21F844E for ; Sun, 26 Jun 2011 06:14:41 -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 p5QDEf16009261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 26 Jun 2011 15:14:41 +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 p5QDEdB2009696 for ; Sun, 26 Jun 2011 15:14:41 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 Jun 2011 15:14:16 +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: Sun, 26 Jun 2011 15:14:15 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640247A3A2@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nomcom 2011-2012: Second Call for Volunteers Thread-Index: Acwymx0khkdDxZoDSYiDqrjqR+s8/gBZlkpA From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf" X-OriginalArrivalTime: 26 Jun 2011 13:14:16.0515 (UTC) FILETIME=[F367D930:01CC3402] Subject: [Netconf] FW: Nomcom 2011-2012: Second Call for Volunteers 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, 26 Jun 2011 13:14:43 -0000 Dear NETCONF Members, please consider to volunteer for the 2011-12 Nomcom. With your engagement in the Nomcom you will contribute to the=20 selection of the best leadership of the IETF and the continuous=20 improvement of the IETF processes. Cheers,=20 Mehmet=20 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of ext NomCom Chair Sent: Friday, June 24, 2011 8:14 PM To: IETF Announcement list Subject: Nomcom 2011-2012: Second Call for Volunteers=20 This is the Second call for Volunteers for the 2011-12 Nomcom. We are just about halfway through the volunteer period so if you are considering volunteering, please do so very soon.=20 We have had a very good response to the initial call for volunteers and I am pleased to report that we have 50 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. =20 However, we would like to have many more volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross=20 section of the IETF population. You have until 11:59 pm EDT July 10, 2011=20 to volunteer for Nomcom but it would be much better if you can volunteer as early as possible.=20 If you volunteered before 21:00 EDT on June 21 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! =20 Details about the process for volunteering for the Nomcom and the list=20 of open positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2938/ The 50 volunteers who have thus far been qualified by the secretariat are:=20 Alia Atlas , Juniper Networks Lixia Zhang , UCLA Wassim Haddad , Ericsson Glen Zorn , Network Zen Richard Barnes , BBN Technologies Stephen Kent , BBN Technologies Scott Mansfield , Ericsson Tina TSOU , FutureWei Technologies Fernando Gont , UTN/FRH Karen Seo , BBN Technologies Jie Dong , Huawei Technologies Mach Chen , Huawei Technologies Co. Sheng Jiang , Huawei Technologies Co. Ltd. Dimitri Papadimitriou , Alcatel-Lucent Thomas D. Nadeau , CA Technologies David Meyer , Cisco Systems/University of Oregon Wesley George , Time Warner Cable Cullen Jennings , Cisco Stephen Hanna , Juniper Networks Stephan Wenger , Bidyo Keyur Patel , Cisco Systems Michael Hamilton , BreakingPoint Systems Behcet Sarikaya , Huawei USA Mark Townsley , Cisco Systems Fred Baker , Cisco Systems Brian Trammell , ETH Zurich Sam Hartman , Painless Security Chris Griffiths , Comcast George Michaelson , APNIC Jiankang Yao , CNNIC Sohel Khan , Comcast Dacheng Zhang , Huawei Lianshu Zheng , Huawei Technologies Hui Deng , China Mobile Gang Chen , China Mobile Mirja Kuhlewind , University of Stuttgart John E Drake , Juniper Networks Matt Lepinski , BBN Technologies Subir Das , Telcordia Technologies Inc Yi Zhao , Huawei John Scudder , Juniper Networks Christer Holmberg , LM Ericsson Teemu Savolainen , Nokia Samita Chakrabarti , Ericsson Jaap Akkerhuis , NLnet labs Jason Weil , Time Warner Cable Randy Bush , Internet Initiative Japan Christian Schmidt , Nokia Siemens Networks Sean Shen , CNNIC Lou Berger , LabN Consulting The primary activity for this nomcom will begin during IETF-81 in Quebec City and should be completed by January 2012. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. =20 Please volunteer by sending an email to me before=20 11:59 pm EDT July 10, 2011 as follows: To: suresh.krishnan@ericsson.com Subject: Nomcom 2011-12 Volunteer Please include the following information in the body of the mail: Full Name: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name Current Primary Affiliation: // typically what goes in the Company=20 // field in the IETF Registration Form Email Address(es): // all email addresses used to Register for the=20 // past 5 IETF meetings // Please designate a Preferred email address for // contact if there is more than one email address Telephone number: // With country code (for confirmation if selected) Please expect an email response from me within 3 business days stating whether or not you are qualified. If you do not receive a response in this timeframe, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that Nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the Nomcom is a good way of contributing in that direction. I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process within the next few days. Thank you in advance for your participation. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From wwwrun@rfc-editor.org Thu Jun 30 12:45:31 2011 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 EF31411E8271; Thu, 30 Jun 2011 12:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.154 X-Spam-Level: X-Spam-Status: No, score=-102.154 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, 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 zZV87WjitAL0; Thu, 30 Jun 2011 12:45:31 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9586911E826C; Thu, 30 Jun 2011 12:45:31 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 86C5A98C4F3; Thu, 30 Jun 2011 12:45:31 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110630194531.86C5A98C4F3@rfc-editor.org> Date: Thu, 30 Jun 2011 12:45:31 -0700 (PDT) Cc: netconf@ietf.org, rfc-editor@rfc-editor.org Subject: [Netconf] RFC 6241 on Network Configuration Protocol (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, 30 Jun 2011 19:45:32 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6241 Title: Network Configuration Protocol (NETCONF) Author: R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed. Status: Standards Track Stream: IETF Date: June 2011 Mailbox: rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy.bierman@brocade.com Pages: 113 Characters: 209465 Obsoletes: RFC4741 I-D Tag: draft-ietf-netconf-4741bis-10.txt URL: http://www.rfc-editor.org/rfc/rfc6241.txt The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Thu Jun 30 12:45:56 2011 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 44D9311E8215; Thu, 30 Jun 2011 12:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.143 X-Spam-Level: X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, 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 kFzLPlvOl26p; Thu, 30 Jun 2011 12:45:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9EACD11E80AC; Thu, 30 Jun 2011 12:45:47 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 959BF98C519; Thu, 30 Jun 2011 12:45:47 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110630194547.959BF98C519@rfc-editor.org> Date: Thu, 30 Jun 2011 12:45:47 -0700 (PDT) Cc: netconf@ietf.org, rfc-editor@rfc-editor.org Subject: [Netconf] RFC 6242 on Using the NETCONF Protocol over Secure Shell (SSH) 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, 30 Jun 2011 19:45:56 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6242 Title: Using the NETCONF Protocol over Secure Shell (SSH) Author: M. Wasserman Status: Standards Track Stream: IETF Date: June 2011 Mailbox: mrw@painless-security.com Pages: 11 Characters: 22704 Obsoletes: RFC4742 I-D Tag: draft-ietf-netconf-rfc4742bis-08.txt URL: http://www.rfc-editor.org/rfc/rfc6242.txt This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK] This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Thu Jun 30 12:46:04 2011 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 8ABFC11E8079; Thu, 30 Jun 2011 12:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.546 X-Spam-Level: X-Spam-Status: No, score=-105.546 tagged_above=-999 required=5 tests=[AWL=-0.469, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, 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 Juf9fDQ77s3t; Thu, 30 Jun 2011 12:46:04 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [64.170.98.47]) by ietfa.amsl.com (Postfix) with ESMTP id F355311E80D6; Thu, 30 Jun 2011 12:46:02 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E4E9698C524; Thu, 30 Jun 2011 12:46:02 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110630194602.E4E9698C524@rfc-editor.org> Date: Thu, 30 Jun 2011 12:46:02 -0700 (PDT) Cc: netconf@ietf.org, rfc-editor@rfc-editor.org Subject: [Netconf] RFC 6243 on With-defaults Capability for 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, 30 Jun 2011 19:46:04 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6243 Title: With-defaults Capability for NETCONF Author: A. Bierman, B. Lengyel Status: Standards Track Stream: IETF Date: June 2011 Mailbox: andy.bierman@brocade.com, balazs.lengyel@ericsson.com Pages: 26 Characters: 51568 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netconf-with-defaults-14.txt URL: http://www.rfc-editor.org/rfc/rfc6243.txt The Network Configuration Protocol (NETCONF) defines ways to read and edit configuration data from a NETCONF server. In some cases, part of this data may not be set by the NETCONF client, but rather a default value known to the server is used instead. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to save it in a NETCONF configuration datastore or send it to the client in a retrieval operation reply. In other situations the NETCONF client will need this data from the server. Not all server implementations treat this default data the same way. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how defaults are processed by the server, and also defines new mechanisms for client control of server processing of default data. [STANDARDS-TRACK] This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From mehmet.ersue@nsn.com Thu Jun 30 14:12:28 2011 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 E821111E81F8 for ; Thu, 30 Jun 2011 14:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 Ue5Fd0f6xR5Z for ; Thu, 30 Jun 2011 14:12:27 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C843A11E81EE for ; Thu, 30 Jun 2011 14:12:26 -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 p5ULCP8k020914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 30 Jun 2011 23:12:25 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p5ULCNsR018282 for ; Thu, 30 Jun 2011 23:12:25 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.19]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Jun 2011 23:12:08 +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: Thu, 30 Jun 2011 23:12:06 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64024F9B50@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New RFCs are now available WAS:FW: RFC 6241 on Network Configuration Protocol (NETCONF) Thread-Index: Acw3XrwACV6ZkHIqS9KW+qVkOHP5EQACxIhQ From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf" X-OriginalArrivalTime: 30 Jun 2011 21:12:08.0552 (UTC) FILETIME=[5EEC7E80:01CC376A] Subject: [Netconf] New RFCs are now available WAS:FW: RFC 6241 on Network Configuration Protocol (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, 30 Jun 2011 21:12:28 -0000 Congratulations to all editors, coauthors and the contributors of=20 the new RFCs 6341, 6242, and 6243 and the substantial work they did. Thank you to the whole WG for reviewing and supporting the development. Mehmet=20 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of ext rfc-editor@rfc-editor.org Sent: Thursday, June 30, 2011 9:46 PM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: netconf@ietf.org; rfc-editor@rfc-editor.org Subject: RFC 6241 on Network Configuration Protocol (NETCONF) A new Request for Comments is now available in online RFC libraries. =20 RFC 6241 Title: Network Configuration Protocol (NETCONF)=20 Author: R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed. Status: Standards Track Stream: IETF Date: June 2011 Mailbox: rob.enns@gmail.com,=20 mbj@tail-f.com,=20 j.schoenwaelder@jacobs-university.de, =20 andy.bierman@brocade.com Pages: 113 Characters: 209465 Obsoletes: RFC4741 I-D Tag: draft-ietf-netconf-4741bis-10.txt URL: http://www.rfc-editor.org/rfc/rfc6241.txt The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce