From netconf-bounces@ietf.org Tue Jun 3 01:42:10 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBD8D3A6BF6; Tue, 3 Jun 2008 01:42:10 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2FAA3A6838 for ; Tue, 3 Jun 2008 01:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnqTerN2QvJM for ; Tue, 3 Jun 2008 01:42:08 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4F09C3A6AC0 for ; Tue, 3 Jun 2008 01:41:52 -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 m538fqH8009248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jun 2008 10:41:52 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m538fqiL008434; Tue, 3 Jun 2008 10:41:52 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 10:41:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Jun 2008 10:41:51 +0200 Message-ID: In-Reply-To: <20080527124149.GA17077@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords thread-index: Aci/9xH+8Em0+zcES1Wa8gEcNzwK8gFWNESA References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 03 Jun 2008 08:41:52.0613 (UTC) FILETIME=[ABD9D150:01C8C555] Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen, I agree, none of the options is satisfying and we should be carefull with the wording in the document. OTOH I can live with option #5 if pwd authentication and the usage of SSH is OPTIONAL. Would this be acceptable for you? Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Juergen > Schoenwaelder > Sent: Tuesday, May 27, 2008 2:42 PM > To: Mohamad Badra > Cc: netconf@ietf.org > Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4,5 > for Enabling Third Party Authentication using Passwords > > On Tue, May 27, 2008 at 02:16:21PM +0200, Mohamad Badra wrote: > > > We would encourage any conFrom netconf-bounces@ietf.org Tue Jun 3 01:42:10 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBD8D3A6BF6; Tue, 3 Jun 2008 01:42:10 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2FAA3A6838 for ; Tue, 3 Jun 2008 01:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnqTerN2QvJM for ; Tue, 3 Jun 2008 01:42:08 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4F09C3A6AC0 for ; Tue, 3 Jun 2008 01:41:52 -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 m538fqH8009248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jun 2008 10:41:52 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m538fqiL008434; Tue, 3 Jun 2008 10:41:52 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 10:41:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Jun 2008 10:41:51 +0200 Message-ID: In-Reply-To: <20080527124149.GA17077@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords thread-index: Aci/9xH+8Em0+zcES1Wa8gEcNzwK8gFWNESA References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 03 Jun 2008 08:41:52.0613 (UTC) FILETIME=[ABD9D150:01C8C555] Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen, I agree, none of the options is satisfying and we should be carefull with the wording in the document. OTOH I can live with option #5 if pwd authentication and the usage of SSH is OPTIONAL. Would this be acceptable for you? Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Juergen > Schoenwaelder > Sent: Tuesday, May 27, 2008 2:42 PM > To: Mohamad Badra > Cc: netconf@ietf.org > Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4,5 > for Enabling Third Party Authentication using Passwords > > On Tue, May 27, 2008 at 02:16:21PM +0200, Mohamad Badra wrote: > > > We would encourage any contribution that could be used in > combination > > with existing user authentication databases. Please don't > hesitate to > > submit your comments on the options described through > "NETCONF over TLS" > > [1] document in Appendix B, or to post your proposal on > the mailing > > list to try to reach WG consensus. > > My $.02 worth of comments: > > : 1. Defining RPC: > > I share that the doubt that this will fly. Plain password > authentication is just one out of many authentication methods out > there. > > : 2. Enhancing TLS: > > Does not belong into the WG. > > : 3. Running BEEP over TLS > > This is already defined as part of the BEEP transport mapping. > > : 4. Extending NETCONF with a message to start TLS > > Extending NETCONF with a SASL hook is an architecture violation. But > this does not preclude the option that the TLS transport for NETCONF > does provide hooks for SASL. > > : 5. Enable SSH (RFC4742 and TLS (as defined through this document: > > This does not make any sense to me. > > My suggestion is to actually do nothing to enable 3rd party > authentication using passwords in this document other then wording > things carefully such that something like this can be added in the > future should this need ever arise. > > /js > > -- > 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 > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf tribution that could be used in > combination > > with existing user authentication databases. Please don't > hesitate to > > submit your comments on the options described through > "NETCONF over TLS" > > [1] document in Appendix B, or to post your proposal on > the mailing > > list to try to reach WG consensus. > > My $.02 worth of comments: > > : 1. Defining RPC: > > I share that the doubt that this will fly. Plain password > authentication is just one out of many authentication methods out > there. > > : 2. Enhancing TLS: > > Does not belong into the WG. > > : 3. Running BEEP over TLS > > This is already defined as part of the BEEP transport mapping. > > : 4. Extending NETCONF with a message to start TLS > > Extending NETCONF with a SASL hook is an architecture violation. But > this does not preclude the option that the TLS transport for NETCONF > does provide hooks for SASL. > > : 5. Enable SSH (RFC4742 and TLS (as defined through this document: > > This does not make any sense to me. > > My suggestion is to actually do nothing to enable 3rd party > authentication using passwords in this document other then wording > things carefully such that something like this can be added in the > future should this need ever arise. > > /js > > -- > 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 > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jun 3 04:22:37 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C15D3A68A9; Tue, 3 Jun 2008 04:22:37 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF8E3A6882 for ; Tue, 3 Jun 2008 04:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bS2yUmCriEkw for ; Tue, 3 Jun 2008 04:22:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 666963A6767 for ; Tue, 3 Jun 2008 04:22:35 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF4B0C0031; Tue, 3 Jun 2008 13:22:37 +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 CFcyoAiv5ERE; Tue, 3 Jun 2008 13:22:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5DC9AC002A; Tue, 3 Jun 2008 13:22:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3809C5ACABA; Tue, 3 Jun 2008 13:22:16 +0200 (CEST) Date: Tue, 3 Jun 2008 13:22:16 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Muenich)" Message-ID: <20080603112216.GA8735@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Muenich)" , netconf@ietf.org, Mohamad Badra References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Tue, Jun 03, 2008 at 10:41:51AM +0200, Ersue, Mehmet (NSN - DE/Muenich) wrote: > OTOH I can live with option #5 if pwd authentication and the usage > of SSH is OPTIONAL. Would this be acceptable for you? I do not understand option #5 nor do I understand your statement since the SSH transport is the mandatory to implement transport for NETCONF (as per section 2.4 of RFC 4741). /js -- 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 netconf-bounces@ietf.org Tue Jun 3 04:22:37 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C15D3A68A9; Tue, 3 Jun 2008 04:22:37 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF8E3A6882 for ; Tue, 3 Jun 2008 04:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bS2yUmCriEkw for ; Tue, 3 Jun 2008 04:22:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 666963A6767 for ; Tue, 3 Jun 2008 04:22:35 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF4B0C0031; Tue, 3 Jun 2008 13:22:37 +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 CFcyoAiv5ERE; Tue, 3 Jun 2008 13:22:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5DC9AC002A; Tue, 3 Jun 2008 13:22:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3809C5ACABA; Tue, 3 Jun 2008 13:22:16 +0200 (CEST) Date: Tue, 3 Jun 2008 13:22:16 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Muenich)" Message-ID: <20080603112216.GA8735@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Muenich)" , netconf@ietf.org, Mohamad Badra References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Tue, Jun 03, 2008 at 10:41:51AM +0200, Ersue, Mehmet (NSN - DE/Muenich) wrote: > OTOH I can live with option #5 if pwd authentication and the usage > of SSH is OPTIONAL. Would this be acceptable for you? I do not understand option #5 nor do I understand your statement since the SSH transport is the mandatory to implement transport for NETCONF (as per section 2.4 of RFC 4741). /js -- 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 netconf-bounces@ietf.org Tue Jun 3 04:57:52 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C1FE3A6ACE; Tue, 3 Jun 2008 04:57:52 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9193A68D9 for ; Tue, 3 Jun 2008 04:57:52 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): Subject: ...0Enablin?=\n =?utf-8?Q?Re:\302\240[Netconf]\302\240WG\302[...] X-Spam-Flag: NO X-Spam-Score: -3.004 X-Spam-Level: X-Spam-Status: No, score=-3.004 tagged_above=-999 required=5 tests=[AWL=-2.793, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, SUBJ_ILLEGAL_CHARS=1.586] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YN9hDBdblGjj for ; Tue, 3 Jun 2008 04:57:46 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 368113A6A0F for ; Tue, 3 Jun 2008 04:57:46 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m53CsEkN577540; Tue, 3 Jun 2008 13:54:14 +0100 Received: from 137.194.160.242 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Tue, 3 Jun 2008 13:57:21 +0200 (CEST) Message-ID: <51306.137.194.160.242.1212494241.squirrel@www.isima.fr> In-Reply-To: <20080603112216.GA8735@elstar.local> References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> <20080603112216.GA8735@elstar.local> Date: Tue, 3 Jun 2008 13:57:21 +0200 (CEST) From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 03 Jun 2008 13:54:16 +0100 (WEST) Cc: Ersue=?utf-8?Q?=2C=C2_Mehmet=C2_?=@core3.amsl.com, =?utf-8?Q?=C2?= Subject: [Netconf] =?utf-8?b?IFJlOsKgwqBXR8KgQ29uc2Vuc3VzwqBvbsKgb3B0aW9u?= =?utf-8?b?c8KgMSzCoDIswqAzLMKgNCw1wqBmb3LCoEVuYWJsaW5SZTrCoMKgV0fCoENv?= =?utf-8?b?bnNlbnN1c8Kgb27CoG9wdGlvbnPCoDEswqAyLMKgMyzCoDQsNcKgZm9ywqBF?= =?utf-8?q?nablingThird=C2=A0Party=C2=A0Authentication=C2=A0using=C2=A0Pas?= =?utf-8?q?swords?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > On Tue, Jun 03, 2008 at 10:41:51AM +0200, Ersue, Mehmet (NSN - DE/Muenich) > wrote: > >> OTOH I can live with option #5 if pwd authentication and the usage >> of SSH is OPTIONAL. Would this be acceptable for you? > > I do not understand option #5 nor do I understand your statement since > the SSH transport is the mandatory to implement transport for NETCONF > (as per section 2.4 of RFC 4741). Option #5 means that if the manager doesn't implement TLS with certificate or psk-based authentication (the manager or the user wishes to use ala unix password), the manager and the agent can rely on SSH to authenticate the manager according to local policy before password-based authentication. This resort is possible since SSH is mandtory within Netconf. Best regards, > /js > > -- > 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 netconf-bounces@ietf.org Tue Jun 3 04:57:52 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C1FE3A6ACE; Tue, 3 Jun 2008 04:57:52 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9193A68D9 for ; Tue, 3 Jun 2008 04:57:52 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): Subject: ...0Enablin?=\n =?utf-8?Q?Re:\302\240[Netconf]\302\240WG\302[...] X-Spam-Flag: NO X-Spam-Score: -3.004 X-Spam-Level: X-Spam-Status: No, score=-3.004 tagged_above=-999 required=5 tests=[AWL=-2.793, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, SUBJ_ILLEGAL_CHARS=1.586] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YN9hDBdblGjj for ; Tue, 3 Jun 2008 04:57:46 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 368113A6A0F for ; Tue, 3 Jun 2008 04:57:46 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m53CsEkN577540; Tue, 3 Jun 2008 13:54:14 +0100 Received: from 137.194.160.242 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Tue, 3 Jun 2008 13:57:21 +0200 (CEST) Message-ID: <51306.137.194.160.242.1212494241.squirrel@www.isima.fr> In-Reply-To: <20080603112216.GA8735@elstar.local> References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> <20080603112216.GA8735@elstar.local> Date: Tue, 3 Jun 2008 13:57:21 +0200 (CEST) From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 03 Jun 2008 13:54:16 +0100 (WEST) Cc: Ersue=?utf-8?Q?=2C=C2_Mehmet=C2_?=@core3.amsl.com, =?utf-8?Q?=C2?= Subject: [Netconf] =?utf-8?b?IFJlOsKgwqBXR8KgQ29uc2Vuc3VzwqBvbsKgb3B0aW9u?= =?utf-8?b?c8KgMSzCoDIswqAzLMKgNCw1wqBmb3LCoEVuYWJsaW5SZTrCoMKgV0fCoENv?= =?utf-8?b?bnNlbnN1c8Kgb27CoG9wdGlvbnPCoDEswqAyLMKgMyzCoDQsNcKgZm9ywqBF?= =?utf-8?q?nablingThird=C2=A0Party=C2=A0Authentication=C2=A0using=C2=A0Pas?= =?utf-8?q?swords?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > On Tue, Jun 03, 2008 at 10:41:51AM +0200, Ersue, Mehmet (NSN - DE/Muenich) > wrote: > >> OTOH I can live with option #5 if pwd authentication and the usage >> of SSH is OPTIONAL. Would this be acceptable for you? > > I do not understand option #5 nor do I understand your statement since > the SSH transport is the mandatory to implement transport for NETCONF > (as per section 2.4 of RFC 4741). Option #5 means that if the manager doesn't implement TLS with certificate or psk-based authentication (the manager or the user wishes to use ala unix password), the manager and the agent can rely on SSH to authenticate the manager according to local policy before password-based authentication. This resort is possible since SSH is mandtory within Netconf. Best regards, > /js > > -- > 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 netconf-bounces@ietf.org Tue Jun 3 05:27:32 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF133A6A51; Tue, 3 Jun 2008 05:27:32 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D0603A688E for ; Tue, 3 Jun 2008 05:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZ9lPQkhyH4T for ; Tue, 3 Jun 2008 05:27:29 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 0A55B3A67D8 for ; Tue, 3 Jun 2008 05:27:27 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m53CRSFD024587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jun 2008 14:27:28 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m53CRElJ028616; Tue, 3 Jun 2008 14:27:28 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 14:27:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Jun 2008 14:27:19 +0200 Message-ID: In-Reply-To: <20080603112216.GA8735@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for EnablingThird Party Authentication using Passwords thread-index: AcjFbCf3jOxZ4TBxQLiQsNUfJeO2mAABiYpw References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> <20080603112216.GA8735@elstar.local> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 03 Jun 2008 12:27:20.0402 (UTC) FILETIME=[2B0A9B20:01C8C575] Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for EnablingThird Party Authentication using Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Juergen, > > OTOH I can live with option #5 if pwd authentication and the usage > > of SSH is OPTIONAL. Would this be acceptable for you? > > I do not understand option #5 nor do I understand your statement since > the SSH transport is the mandatory to implement transport for NETCONF > (as per section 2.4 of RFC 4741). SSH transport is mandatory to implement but use of SSH-based password authentication in case of Netconf over TLS is not. Using 'SSH for password authentication' and 'TLS for endpoint authentication with PSK or certificates' in combination can be introduced as OPTIONAL. People who want to have this kind of access security can do what Badra describes. It would be worded as MAY or OPTIONAL in the TLS draft. Namely, the agent MAY passively listen for the incoming SSH (respectively TLS) connection on port 830 (respectively port ). Cheers, Mehmet > -----Original Message----- > From: ext Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, June 03, 2008 1:22 PM > To: Ersue, Mehmet (NSN - DE/Muenich) > Cc: netconf@ietf.org; Mohamad Badra > Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4,5 > for EnablingThird Party Authentication using Passwords > > On Tue, Jun 03, 2008 at 10:41:51AM +0200, Ersue, Mehmet (NSN > - DE/Muenich) wrote: > > > OTOH I can live with option #5 if pwd authentication and the usage > > of SSH is OPTIONAL. Would this be acceptable for you? > > I do not understand option #5 nor do I understand your statement since > the SSH transport is the mandatory to implement transport for NETCONF > (as per section 2.4 of RFC 4741). > > /js > > -- > 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 netconf-bounces@ietf.org Tue Jun 3 05:27:32 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF133A6A51; Tue, 3 Jun 2008 05:27:32 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D0603A688E for ; Tue, 3 Jun 2008 05:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZ9lPQkhyH4T for ; Tue, 3 Jun 2008 05:27:29 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 0A55B3A67D8 for ; Tue, 3 Jun 2008 05:27:27 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m53CRSFD024587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jun 2008 14:27:28 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m53CRElJ028616; Tue, 3 Jun 2008 14:27:28 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 14:27:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Jun 2008 14:27:19 +0200 Message-ID: In-Reply-To: <20080603112216.GA8735@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for EnablingThird Party Authentication using Passwords thread-index: AcjFbCf3jOxZ4TBxQLiQsNUfJeO2mAABiYpw References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> <20080603112216.GA8735@elstar.local> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 03 Jun 2008 12:27:20.0402 (UTC) FILETIME=[2B0A9B20:01C8C575] Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for EnablingThird Party Authentication using Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Juergen, > > OTOH I can live with option #5 if pwd authentication and the usage > > of SSH is OPTIONAL. Would this be acceptable for you? > > I do not understand option #5 nor do I understand your statement since > the SSH transport is the mandatory to implement transport for NETCONF > (as per section 2.4 of RFC 4741). SSH transport is mandatory to implement but use of SSH-based password authentication in case of Netconf over TLS is not. Using 'SSH for password authentication' and 'TLS for endpoint authentication with PSK or certificates' in combination can be introduced as OPTIONAL. People who want to have this kind of access security can do what Badra describes. It would be worded as MAY or OPTIONAL in the TLS draft. Namely, the agent MAY passively listen for the incoming SSH (respectively TLS) connection on port 830 (respectively port ). Cheers, Mehmet > -----Original Message----- > From: ext Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, June 03, 2008 1:22 PM > To: Ersue, Mehmet (NSN - DE/Muenich) > Cc: netconf@ietf.org; Mohamad Badra > Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4,5 > for EnablingThird Party Authentication using Passwords > > On Tue, Jun 03, 2008 at 10:41:51AM +0200, Ersue, Mehmet (NSN > - DE/Muenich) wrote: > > > OTOH I can live with option #5 if pwd authentication and the usage > > of SSH is OPTIONAL. Would this be acceptable for you? > > I do not understand option #5 nor do I understand your statement since > the SSH transport is the mandatory to implement transport for NETCONF > (as per section 2.4 of RFC 4741). > > /js > > -- > 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 netconf-bounces@ietf.org Tue Jun 3 06:07:19 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8519D28C165; Tue, 3 Jun 2008 06:07:19 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA09428C150 for ; Tue, 3 Jun 2008 06:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5oS-7Lk7rNk for ; Tue, 3 Jun 2008 06:07:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3630028C1AD for ; Tue, 3 Jun 2008 06:03:36 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A620BC000B; Tue, 3 Jun 2008 15:03:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id u84gu8zAu9vm; Tue, 3 Jun 2008 15:03:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94320C002A; Tue, 3 Jun 2008 15:03:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 83A995ACCE7; Tue, 3 Jun 2008 15:03:31 +0200 (CEST) Date: Tue, 3 Jun 2008 15:03:31 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Muenich)" Message-ID: <20080603130331.GA8886@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Muenich)" , netconf@ietf.org, Mohamad Badra References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> <20080603112216.GA8735@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for EnablingThird Party Authentication using Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Tue, Jun 03, 2008 at 02:27:19PM +0200, Ersue, Mehmet (NSN - DE/Muenich) wrote: > SSH transport is mandatory to implement but use of SSH-based > password authentication in case of Netconf over TLS is not. > Using 'SSH for password authentication' and 'TLS for endpoint > authentication with PSK or certificates' in combination can be > introduced as OPTIONAL. > > People who want to have this kind of access security can do > what Badra describes. It would be worded as MAY or OPTIONAL > in the TLS draft. > Namely, the From netconf-bounces@ietf.org Tue Jun 3 06:07:19 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8519D28C165; Tue, 3 Jun 2008 06:07:19 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA09428C150 for ; Tue, 3 Jun 2008 06:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5oS-7Lk7rNk for ; Tue, 3 Jun 2008 06:07:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3630028C1AD for ; Tue, 3 Jun 2008 06:03:36 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A620BC000B; Tue, 3 Jun 2008 15:03:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id u84gu8zAu9vm; Tue, 3 Jun 2008 15:03:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94320C002A; Tue, 3 Jun 2008 15:03:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 83A995ACCE7; Tue, 3 Jun 2008 15:03:31 +0200 (CEST) Date: Tue, 3 Jun 2008 15:03:31 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Muenich)" Message-ID: <20080603130331.GA8886@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Muenich)" , netconf@ietf.org, Mohamad Badra References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> <20080603112216.GA8735@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for EnablingThird Party Authentication using Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Tue, Jun 03, 2008 at 02:27:19PM +0200, Ersue, Mehmet (NSN - DE/Muenich) wrote: > SSH transport is mandatory to implement but use of SSH-based > password authentication in case of Netconf over TLS is not. > Using 'SSH for password authentication' and 'TLS for endpoint > authentication with PSK or certificates' in combination can be > introduced as OPTIONAL. > > People who want to have this kind of access security can do > what Badra describes. It would be worded as MAY or OPTIONAL > in the TLS draft. > Namelyagent MAY passively listen for the incoming SSH > (respectively TLS) connection on port 830 (respectively port > ). My problem is that I read the words, but I do not get the meaning. - What has SSH password authentication to do with TLS?? - Isn't it obvious that I can use SSH? - What is the purpose of MAY or OPTIONAL in this context? The choice of which authentication mechanism I use is a deployment decision not an implementation requirement... - I don't get the port number sentence; is the idea here that both the SSH and the TLS transport share a listening endpoint? I wonder how people should implement this. /js -- 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 , the agent MAY passively listen for the incoming SSH > (respectively TLS) connection on port 830 (respectively port > ). My problem is that I read the words, but I do not get the meaning. - What has SSH password authentication to do with TLS?? - Isn't it obvious that I can use SSH? - What is the purpose of MAY or OPTIONAL in this context? The choice of which authentication mechanism I use is a deployment decision not an implementation requirement... - I don't get the port number sentence; is the idea here that both the SSH and the TLS transport share a listening endpoint? I wonder how people should implement this. /js -- 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 netconf-bounces@ietf.org Tue Jun 3 06:58:12 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8AE23A6B00; Tue, 3 Jun 2008 06:58:12 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7EE3A690A for ; Tue, 3 Jun 2008 06:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnmIKe86DmUn for ; Tue, 3 Jun 2008 06:58:11 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 700B728C12A for ; Tue, 3 Jun 2008 06:55:54 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m53EqP7V774382; Tue, 3 Jun 2008 15:52:25 +0100 Received: from 137.194.26.116 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Tue, 3 Jun 2008 15:55:29 +0200 (CEST) Message-ID: <51957.137.194.26.116.1212501329.squirrel@www.isima.fr> In-Reply-To: <20080603130331.GA8886@elstar.local> References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> <20080603112216.GA8735@elstar.local> <20080603130331.GA8886@elstar.local> Date: Tue, 3 Jun 2008 15:55:29 +0200 (CEST) From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 03 Jun 2008 15:52:25 +0100 (WEST) Cc: Ersue=?utf-8?Q?=2C=C2_Mehmet=C2_?=@core3.amsl.com, =?utf-8?Q?=C2?= Subject: [Netconf] =?utf-8?b?IFJlOsKgwqBXR8KgQ29uc2Vuc3VzwqBvbsKgb3B0aW9u?= =?utf-8?b?c8KgMSzCoDIswqAzLMKgNCw1wqBmb3JFbmFibGluZ1RoaXJkwqBQYXJ0ecKg?= =?utf-8?q?Authentication=C2=A0using=C2=A0Passwords?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear Juergen, > On Tue, Jun 03, 2008 at 02:27:19PM +0200, Ersue, Mehmet (NSN - DE/Muenich) > wrote: > >> SSH transport is mandatory to implement but use of SSH-based >> password authentication in case of Netconf over TLS is not. >> Using 'SSH for password authentication' and 'TLS for endpoint >> authentication with PSK or certificates' in combination can be >> introduced as OPTIONAL. >> >> People who want to have this kind of access security can do >> what Badra describes. It would be worded as MAY or OPTIONAL >> in the TLS draft. >> Namely, the agent MAY passively listen for the incoming SSH >> (respectively TLS) connection on port 830 (respectively port >> ). > > My problem is that I read the words, but I do not get the meaning. > > - What has SSH password authentication to do with TLS?? Nothing. But since TLS don't support a standFrom netconf-bounces@ietf.org Tue Jun 3 06:58:12 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8AE23A6B00; Tue, 3 Jun 2008 06:58:12 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7EE3A690A for ; Tue, 3 Jun 2008 06:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnmIKe86DmUn for ; Tue, 3 Jun 2008 06:58:11 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 700B728C12A for ; Tue, 3 Jun 2008 06:55:54 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m53EqP7V774382; Tue, 3 Jun 2008 15:52:25 +0100 Received: from 137.194.26.116 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Tue, 3 Jun 2008 15:55:29 +0200 (CEST) Message-ID: <51957.137.194.26.116.1212501329.squirrel@www.isima.fr> In-Reply-To: <20080603130331.GA8886@elstar.local> References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> <20080603112216.GA8735@elstar.local> <20080603130331.GA8886@elstar.local> Date: Tue, 3 Jun 2008 15:55:29 +0200 (CEST) From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 03 Jun 2008 15:52:25 +0100 (WEST) Cc: Ersue=?utf-8?Q?=2C=C2_Mehmet=C2_?=@core3.amsl.com, =?utf-8?Q?=C2?= Subject: [Netconf] =?utf-8?b?IFJlOsKgwqBXR8KgQ29uc2Vuc3VzwqBvbsKgb3B0aW9u?= =?utf-8?b?c8KgMSzCoDIswqAzLMKgNCw1wqBmb3JFbmFibGluZ1RoaXJkwqBQYXJ0ecKg?= =?utf-8?q?Authentication=C2=A0using=C2=A0Passwords?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear Juergen, > On Tue, Jun 03, 2008 at 02:27:19PM +0200, Ersue, Mehmet (NSN - DE/Muenich) > wrote: > >> SSH transport is mandatory to implement but use of SSH-based >> password authentication in case of Netconf over TLS is not. >> Using 'SSH for password authentication' and 'TLS for endpoint >> authentication with PSK or certificates' in combination can be >> introduced as OPTIONAL. >> >> People who want to have this kind of access security can do >> what Badra describes. It would be worded as MAY or OPTIONAL >> in the TLS draft. >> Namely, the agent MAY passively listen for the incoming SSH >> (respectively TLS) connection on port 830 (respectively port >> ). > > My problem is that I read the words, but I do not get the meaning. > > - What has SSH password authentication to do with TLS?? Nothing. But since TLS don't support a standard paard password-based authentication (RFC 5054 specifies that but it is informational), so managers that don't have certificates or PSK shared with the agent can rely on SSH to establish password-based authentication. Please look at is as you have SSH and BEEP or SOAP. They are independant and provide security services each one by its own way. > - Isn't it obvious that I can use SSH? You can do that. And each of them has its advantages and drawbacks. > - What is the purpose of MAY or OPTIONAL in this context? The choice > of which authentication mechanism I use is a deployment decision not > an implementation requirement... Yes, but this would help implentors when decision is made. > - I don't get the port number sentence; is the idea here that both > the SSH and the TLS transport share a listening endpoint? I wonder > how people should implement this. The point is that the agent is configured *by default* to accept SSH session, which provides, among others, ala unix authentication. But the agent can also passively listen on a port specific to TLS to authenticate the manager using certificate or psk derived from a password. So I don't see where is the problem of implementing that. Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ssword-based authentication (RFC 5054 specifies that but it is informational), so managers that don't have certificates or PSK shared with the agent can rely on SSH to establish password-based authentication. Please look at is as you have SSH and BEEP or SOAP. They are independant and provide security services each one by its own way. > - Isn't it obvious that I can use SSH? You can do that. And each of them has its advantages and drawbacks. > - What is the purpose of MAY or OPTIONAL in this context? The choice > of which authentication mechanism I use is a deployment decision not > an implementation requirement... Yes, but this would help implentors when decision is made. > - I don't get the port number sentence; is the idea here that both > the SSH and the TLS transport share a listening endpoint? I wonder > how people should implement this. The point is that the agent is configured *by default* to accept SSH session, which provides, among others, ala unix authentication. But the agent can also passively listen on a port specific to TLS to authenticate the manager using certificate or psk derived from a password. So I don't see where is the problem of implementing that. Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jun 3 07:23:36 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 691783A6A73; Tue, 3 Jun 2008 07:23:36 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 103033A6A73 for ; Tue, 3 Jun 2008 07:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.129 X-Spam-Level: X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8x3=0.641] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aU9ixJs7L3p for ; Tue, 3 Jun 2008 07:23:33 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id CBBBF3A6A36 for ; Tue, 3 Jun 2008 07:23:33 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Tue, 03 Jun 2008 07:23:34 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jun 2008 07:22:04 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m53EM3x82358; Tue, 3 Jun 2008 07:22:03 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m53EJqo0075912; Tue, 3 Jun 2008 14:19:52 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806031419.m53EJqo0075912@idle.juniper.net> To: badra@isima.fr In-reply-to: <51957.137.194.26.116.1212501329.squirrel@www.isima.fr> Date: Tue, 03 Jun 2008 10:19:51 -0400 From: Phil Shafer X-OriginalArrivalTime: 03 Jun 2008 14:22:04.0205 (UTC) FILETIME=[321B95D0:01C8C585] Cc: Ersue=?utf-8?Q?=2C=C2_Mehmet=C2_?=@core3.amsl.com, =?utf-8?Q?=C2?= Subject: Re: [Netconf] =?utf-8?b?wqDCoFdHwqBDb25zZW5zdXPCoG9uwqBvcHRpb25zwqAx?= =?utf-8?b?LMKgMizCoDMswqA0LDXCoGZvckVuYWJsaW5nVGhpcmTCoFBhcnR5wqBB?= =?utf-8?q?uthentication=C2=A0using=C2=A0Passwords?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org FWIW I'm confused also. I can't figure out if you are saying: (a) TLS should use the same mechanism that SSH uses (b) TLS doesn't need security, since you could use SSH if you wanted that (c) TLS should generate certs based on SSH credentials (d) TLS has already solved this issue In particular, this paragraph is completely confusing: >Nothing. But since TLS don't support a standard password-based >authentication (RFC 5054 specifies that but it is informational), so >managers that don't have certificates or PSK shared with the agent can >rely on SSH to establish password-based authentication. Please look at is >as you have SSH and BEEP or SOAP. They are independant and provide >security services each one by its own way. How can a manager using TLS rely on SSH? You say they are independent but that one can rely on the other. This is not like From netconf-bounces@ietf.org Tue Jun 3 07:23:36 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 691783A6A73; Tue, 3 Jun 2008 07:23:36 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 103033A6A73 for ; Tue, 3 Jun 2008 07:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.129 X-Spam-Level: X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8x3=0.641] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aU9ixJs7L3p for ; Tue, 3 Jun 2008 07:23:33 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id CBBBF3A6A36 for ; Tue, 3 Jun 2008 07:23:33 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Tue, 03 Jun 2008 07:23:34 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jun 2008 07:22:04 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m53EM3x82358; Tue, 3 Jun 2008 07:22:03 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m53EJqo0075912; Tue, 3 Jun 2008 14:19:52 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806031419.m53EJqo0075912@idle.juniper.net> To: badra@isima.fr In-reply-to: <51957.137.194.26.116.1212501329.squirrel@www.isima.fr> Date: Tue, 03 Jun 2008 10:19:51 -0400 From: Phil Shafer X-OriginalArrivalTime: 03 Jun 2008 14:22:04.0205 (UTC) FILETIME=[321B95D0:01C8C585] Cc: Ersue=?utf-8?Q?=2C=C2_Mehmet=C2_?=@core3.amsl.com, =?utf-8?Q?=C2?= Subject: Re: [Netconf] =?utf-8?b?wqDCoFdHwqBDb25zZW5zdXPCoG9uwqBvcHRpb25zwqAx?= =?utf-8?b?LMKgMizCoDMswqA0LDXCoGZvckVuYWJsaW5nVGhpcmTCoFBhcnR5wqBB?= =?utf-8?q?uthentication=C2=A0using=C2=A0Passwords?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org FWIW I'm confused also. I can't figure out if you are saying: (a) TLS should use the same mechanism that SSH uses (b) TLS doesn't need security, since you could use SSH if you wanted that (c) TLS should generate certs based on SSH credentials (d) TLS has already solved this issue In particular, this paragraph is completely confusing: >Nothing. But since TLS don't support a standard password-based >authentication (RFC 5054 specifies that but it is informational), so >managers that don't have certificates or PSK shared with the agent can >rely on SSH to establish password-based authentication. Please look at is >as you have SSH and BEEP or SOAP. They are independant and provide >security services each one by its own way. How can a manager using TLS rely on SSH? You say they are independent but that one can rely on the other. This is not like BEEP oBEEP or SOAP, which have their own authenitcation schemes. Not to be a pain, but can you give a more detailed description of how this works? Thanks, Phil badra@isima.fr writes: >Dear Juergen, > >> On Tue, Jun 03, 2008 at 02:27:19PM +0200, Ersue, Mehmet (NSN - DE/Muenich) >> wrote: >> >>> SSH transport is mandatory to implement but use of SSH-based >>> password authentication in case of Netconf over TLS is not. >>> Using 'SSH for password authentication' and 'TLS for endpoint >>> authentication with PSK or certificates' in combination can be >>> introduced as OPTIONAL. >>> >>> People who want to have this kind of access security can do >>> what Badra describes. It would be worded as MAY or OPTIONAL >>> in the TLS draft. >>> Namely, the agent MAY passively listen for the incoming SSH >>> (respectively TLS) connection on port 830 (respectively port >>> ). >> >> My problem is that I read the words, but I do not get the meaning. >> >> - What has SSH password authentication to do with TLS?? > >Nothing. But since TLS don't support a standard password-based >authentication (RFC 5054 specifies that but it is informational), so >managers that don't have certificates or PSK shared with the agent can >rely on SSH to establish password-based authentication. Please look at is >as you have SSH and BEEP or SOAP. They are independant and provide >security services each one by its own way. > >> - Isn't it obvious that I can use SSH? > >You can do that. And each of them has its advantages and drawbacks. > >> - What is the purpose of MAY or OPTIONAL in this context? The choice >> of which authentication mechanism I use is a deployment decision not >> an implementation requirement... > >Yes, but this would help implentors when decision is made. > >> - I don't get the port number sentence; is the idea here that both >> the SSH and the TLS transport share a listening endpoint? I wonder >> how people should implement this. > >The point is that the agent is configured *by default* to accept SSH >session, which provides, among others, ala unix authentication. But the >agent can also passively listen on a port specific to TLS to authenticate >the manager using certificate or psk derived from a password. So I don't >see where is the problem of implementing that. > >Best regards, >Badra >_______________________________________________ >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 r SOAP, which have their own authenitcation schemes. Not to be a pain, but can you give a more detailed description of how this works? Thanks, Phil badra@isima.fr writes: >Dear Juergen, > >> On Tue, Jun 03, 2008 at 02:27:19PM +0200, Ersue, Mehmet (NSN - DE/Muenich) >> wrote: >> >>> SSH transport is mandatory to implement but use of SSH-based >>> password authentication in case of Netconf over TLS is not. >>> Using 'SSH for password authentication' and 'TLS for endpoint >>> authentication with PSK or certificates' in combination can be >>> introduced as OPTIONAL. >>> >>> People who want to have this kind of access security can do >>> what Badra describes. It would be worded as MAY or OPTIONAL >>> in the TLS draft. >>> Namely, the agent MAY passively listen for the incoming SSH >>> (respectively TLS) connection on port 830 (respectively port >>> ). >> >> My problem is that I read the words, but I do not get the meaning. >> >> - What has SSH password authentication to do with TLS?? > >Nothing. But since TLS don't support a standard password-based >authentication (RFC 5054 specifies that but it is informational), so >managers that don't have certificates or PSK shared with the agent can >rely on SSH to establish password-based authentication. Please look at is >as you have SSH and BEEP or SOAP. They are independant and provide >security services each one by its own way. > >> - Isn't it obvious that I can use SSH? > >You can do that. And each of them has its advantages and drawbacks. > >> - What is the purpose of MAY or OPTIONAL in this context? The choice >> of which authentication mechanism I use is a deployment decision not >> an implementation requirement... > >Yes, but this would help implentors when decision is made. > >> - I don't get the port number sentence; is the idea here that both >> the SSH and the TLS transport share a listening endpoint? I wonder >> how people should implement this. > >The point is that the agent is configured *by default* to accept SSH >session, which provides, among others, ala unix authentication. But the >agent can also passively listen on a port specific to TLS to authenticate >the manager using certificate or psk derived from a password. So I don't >see where is the problem of implementing that. > >Best regards, >Badra >_______________________________________________ >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 netconf-bounces@ietf.org Tue Jun 3 08:29:23 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CF9B3A6869; Tue, 3 Jun 2008 08:29:23 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCD273A6869 for ; Tue, 3 Jun 2008 08:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mi8RiqBzIBNs for ; Tue, 3 Jun 2008 08:29:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 90C2A3A6868 for ; Tue, 3 Jun 2008 08:29:21 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25AC5C002A; Tue, 3 Jun 2008 17:29:24 +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 9CGnQuOswQKs; Tue, 3 Jun 2008 17:29:18 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 19EF4C000B; Tue, 3 Jun 2008 17:29:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0FDAA5ACF5F; Tue, 3 Jun 2008 17:29:17 +0200 (CEST) Date: Tue, 3 Jun 2008 17:29:17 +0200 From: Juergen Schoenwaelder To: badra@isima.fr Message-ID: <20080603152916.GB9212@elstar.local> Mail-Followup-To: badra@isima.fr, "Ersue,? Mehmet? ?" , ? References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> <20080603112216.GA8735@elstar.local> <20080603130331.GA8886@elstar.local> <51957.137.194.26.116.1212501329.squirrel@www.isima.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <51957.137.194.26.116.1212501329.squirrel@www.isima.fr> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: ? Subject: Re: [Netconf] ????WG??Consensus??on??options??1, ??2, ??3, ??4, 5??forEnablin gThird??Party??Authentication??using??Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Tue, Jun 03, 2008 at 03:55:29PM +0200, badra@isima.fr wrote: > > My problem is that I read the words, but I do not get the meaning. > > > > - What has SSH password authentication to do with TLS?? > > Nothing. But since TLS don't support a standard password-based > authentication (RFC 5054 specifies that but it is informational), so > managers that don't have certificates or PSK shared with the agent can > rely on SSH to establish password-based authentication. Please look at is > as you have SSH and BEEP or SOAP. They are independant and provide > security services each one by its own way. > > > - Isn't it obvious that I can use SSH? > > You can do that. And each of them has its advantages and drawbacks. > > > - What is the purpose of MAY or OPTIONAL in this context? The choice > > of which authentication mechanism I use is a deployment decision not > > an implementation requirement... > > Yes, but this would help implentors when decision is made. > > > - I don't get the port number sentence; is the idea here that both > > the SSH and the TLS transport share a listening endpoint? I wonder > > how people should implement this. > > The point is that the agent is configured *by default* to accept SSH > session, which provides, among others, ala unix authentication. But the > agent can also passively listen on a port specific to TLS to authenticate > the manager using certificate or psk derived from a password. So I don't > see where is the problem of implementing that. The TLS document needs to describe in detail how the TLS transport for NETCONF works and it should IMHO avoid saying anything about the other transports at all. RFC 4741 is pretty clear that SSH is the mandatory to implement transport and I trust operators that they will manage to figure out which of the NETCONF transports or combinations thereof make sense for their environments. So I am back to my preference: do nothing concerning passwords in the TLS transport document. /js -- 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 netconf-bounces@ietf.org Tue Jun 3 08:29:23 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CF9B3A6869; Tue, 3 Jun 2008 08:29:23 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCD273A6869 for ; Tue, 3 Jun 2008 08:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mi8RiqBzIBNs for ; Tue, 3 Jun 2008 08:29:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 90C2A3A6868 for ; Tue, 3 Jun 2008 08:29:21 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25AC5C002A; Tue, 3 Jun 2008 17:29:24 +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 9CGnQuOswQKs; Tue, 3 Jun 2008 17:29:18 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 19EF4C000B; Tue, 3 Jun 2008 17:29:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0FDAA5ACF5F; Tue, 3 Jun 2008 17:29:17 +0200 (CEST) Date: Tue, 3 Jun 2008 17:29:17 +0200 From: Juergen Schoenwaelder To: badra@isima.fr Message-ID: <20080603152916.GB9212@elstar.local> Mail-Followup-To: badra@isima.fr, "Ersue,? Mehmet? ?" , ? References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> <20080603112216.GA8735@elstar.local> <20080603130331.GA8886@elstar.local> <51957.137.194.26.116.1212501329.squirrel@www.isima.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <51957.137.194.26.116.1212501329.squirrel@www.isima.fr> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: ? Subject: Re: [Netconf] ????WG??Consensus??on??options??1, ??2, ??3, ??4, 5??forEnablin gThird??Party??Authentication??using??Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Tue, Jun 03, 2008 at 03:55:29PM +0200, badra@isima.fr wrote: > > My problem is that I read the words, but I do not get the meaning. > > > > - What has SSH password authentication to do with TLS?? > > Nothing. But since TLS don't support a standard password-based > authentication (RFC 5054 specifies that but it is informational), so > managers that don't have certificates or PSK shared with the agent can > rely on SSH to establish password-based authentication. Please look at is > as you have SSH and BEEP or SOAP. They are independant and provide > security services each one by its own way. > > > - Isn't it obvious that I can use SSH? > > You can do that. And each of them has its advantages and drawbacks. > > > - What is the purpose of MAY or OPTIONAL in this context? The choice > > of which authentication mechanism I use is a deployment decision not > > an implementation requirement... > > Yes, but this would help implentors when decision is made. > > > - I don't get the port number sentence; is the idea here that both > > the SSH and the TLS transport share a listening endpoint? I wonder > > how people should implement this. > > The point is that the agent is configured *by default* to accept SSH > session, which provides, among others, ala unix authentication. But the > agent can also passively listen on a port specific to TLS to authenticate > the manager using certificate or psk derived from a password. So I don't > see where is the problem of implementing that. The TLS document needs to describe in detail how the TLS transport for NETCONF works and it should IMHO avoid saying anything about the other transports at all. RFC 4741 is pretty clear that SSH is the mandatory to implement transport and I trust operators that they will manage to figure out which of the NETCONF transports or combinations thereof make sense for their environments. So I am back to my preference: do nothing concerning passwords in the TLS transport document. /js -- 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 netconf-bounces@ietf.org Tue Jun 3 08:43:04 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D02C228C137; Tue, 3 Jun 2008 08:43:04 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47CCA3A6B22 for ; Tue, 3 Jun 2008 08:43:04 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): Subject: ...2=A0usin?=\n =?utf-8?Q?Re:\302\240\302\240WG\302\240Consensu[...] X-Spam-Flag: NO X-Spam-Score: -1.406 X-Spam-Level: X-Spam-Status: No, score=-1.406 tagged_above=-999 required=5 tests=[AWL=-1.195, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, SUBJ_ILLEGAL_CHARS=1.586] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrT-wFl3mW14 for ; Tue, 3 Jun 2008 08:43:03 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9E23A67CC for ; Tue, 3 Jun 2008 08:41:37 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m53Gc9pN782454; Tue, 3 Jun 2008 17:38:09 +0100 Received: from 86.218.101.217 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Tue, 3 Jun 2008 17:41:13 +0200 (CEST) Message-ID: <51604.86.218.101.217.1212507673.squirrel@www.isima.fr> In-Reply-To: <200806031419.m53EJqo0075912@idle.juniper.net> References: <51957.137.194.26.116.1212501329.squirrel@www.isima.fr> <200806031419.m53EJqo0075912@idle.juniper.net> Date: Tue, 3 Jun 2008 17:41:13 +0200 (CEST) From: badra@isima.fr To: phil@juniper.net User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 03 Jun 2008 17:38:09 +0100 (WEST) Cc: netconf@ietf.org Subject: [Netconf] =?utf-8?b?IFJlOsKgwqAgUmU6wqDCoFdHwqBDb25zZW5zdXPCoG9u?= =?utf-8?b?wqBvcHRpb25zwqAxLMKgMizCoDMswqA0LDXCoGZvckVuYWJsaW5nVGhpcmQ=?= =?utf-8?b?wqBQYXJ0ecKgQXV0aGVudGljYXRpb27CoHVzaW5SZTrCoMKgV0fCoENvbnNl?= =?utf-8?b?bnN1c8Kgb27CoG9wdGlvbnPCoDEswqAyLMKgMyzCoDQsNcKgZm9yRW5hYmxp?= =?utf-8?q?ngThird=C2=A0Party=C2=A0Authentication=C2=A0using=C2=A0Password?= =?utf-8?q?s?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > FWIW I'm confused also. I can't figure out if you are saying: > > (a) TLS should use the same mechanism that SSH uses > (b) TLS doesn't need security, since you could use SSH if you wanted that > (c) TLS should generate certs based on SSH credentials > (d) TLS has already solved this issue > > In particular, this paragraph is completely confusing: > >>Nothing. But since TLS don't support a standard password-based >>authentication (RFC 5054 specifies that but it is informational), so >>managers that don't have certificates or PSK shared with the agent can >>rely on SSH to establish password-based authentication. Please look at is >>as you have SSH and BEEP or SOAP. They are independant and provide >>security services each one by its own way. > > How can a manager using TLS rely on SSH? You say they are independent > but that one can rely on the other. This is not like BEEP or SOAP, > which have their own authenitcation schemes. > > Not to be a pain, but can you give a more detailed description of > how this works? > > Thanks, > Phil > > Dear Phil, TLS defines its *own* authentication mechanism and key establishment. It is not depend on SSH at all. TLS use certificates and public keys, or pre-shared keys + psk's identifiers, independately of SSH or any other security protocol. What I am trying to say is the following: In case the manager wishes to authenticate itself to the agent using certificates and/or preshared keys derived from paswords, both the manager and the agent can implement TLS over Netconf (only TLS). In case the manager don't process a certificate or a psk, the manager can authenticate itself using SSH (only SSH). Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jun 3 08:43:04 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D02C228C137; Tue, 3 Jun 2008 08:43:04 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47CCA3A6B22 for ; Tue, 3 Jun 2008 08:43:04 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): Subject: ...2=A0usin?=\n =?utf-8?Q?Re:\302\240\302\240WG\302\240Consensu[...] X-Spam-Flag: NO X-Spam-Score: -1.406 X-Spam-Level: X-Spam-Status: No, score=-1.406 tagged_above=-999 required=5 tests=[AWL=-1.195, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, SUBJ_ILLEGAL_CHARS=1.586] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrT-wFl3mW14 for ; Tue, 3 Jun 2008 08:43:03 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9E23A67CC for ; Tue, 3 Jun 2008 08:41:37 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m53Gc9pN782454; Tue, 3 Jun 2008 17:38:09 +0100 Received: from 86.218.101.217 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Tue, 3 Jun 2008 17:41:13 +0200 (CEST) Message-ID: <51604.86.218.101.217.1212507673.squirrel@www.isima.fr> In-Reply-To: <200806031419.m53EJqo0075912@idle.juniper.net> References: <51957.137.194.26.116.1212501329.squirrel@www.isima.fr> <200806031419.m53EJqo0075912@idle.juniper.net> Date: Tue, 3 Jun 2008 17:41:13 +0200 (CEST) From: badra@isima.fr To: phil@juniper.net User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 03 Jun 2008 17:38:09 +0100 (WEST) Cc: netconf@ietf.org Subject: [Netconf] =?utf-8?b?IFJlOsKgwqAgUmU6wqDCoFdHwqBDb25zZW5zdXPCoG9u?= =?utf-8?b?wqBvcHRpb25zwqAxLMKgMizCoDMswqA0LDXCoGZvckVuYWJsaW5nVGhpcmQ=?= =?utf-8?b?wqBQYXJ0ecKgQXV0aGVudGljYXRpb27CoHVzaW5SZTrCoMKgV0fCoENvbnNl?= =?utf-8?b?bnN1c8Kgb27CoG9wdGlvbnPCoDEswqAyLMKgMyzCoDQsNcKgZm9yRW5hYmxp?= =?utf-8?q?ngThird=C2=A0Party=C2=A0Authentication=C2=A0using=C2=A0Password?= =?utf-8?q?s?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > FWIW I'm confused also. I can't figure out if you are saying: > > (a) TLS should use the same mechanism that SSH uses > (b) TLS doesn't need security, since you could use SSH if you wanted that > (c) TLS should generate certs based on SSH credentials > (d) TLS has already solved this issue > > In particular, this paragraph is completely confusing: > >>Nothing. But since TLS don't support a standard password-based >>authentication (RFC 5054 specifies that but it is informational), so >>managers that don't have certificates or PSK shared with the agent can >>rely on SSH to establish password-based authentication. Please look at is >>as you have SSH and BEEP or SOAP. They are independant and provide >>security services each one by its own way. > > How can a manager using TLS rely on SSH? You say they are independent > but that one can rely on the other. This is not like BEEP or SOAP, > which have their own authenitcation schemes. > > Not to be a pain, but can you give a more detailed description of > how this works? > > Thanks, > Phil > > Dear Phil, TLS defines its *own* authentication mechanism and key establishment. It is not depend on SSH at all. TLS use certificates and public keys, or pre-shared keys + psk's identifiers, independately of SSH or any other security protocol. What I am trying to say is the following: In case the manager wishes to authenticate itself to the agent using certificates and/or preshared keys derived from paswords, both the manager and the agent can implement TLS over Netconf (only TLS). In case the manager don't process a certificate or a psk, the manager can authenticate itself using SSH (only SSH). Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jun 3 08:56:46 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 624953A6ACC; Tue, 3 Jun 2008 08:56:46 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 219BC3A682B for ; Tue, 3 Jun 2008 08:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZrDJQ8V2956 for ; Tue, 3 Jun 2008 08:56:41 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id B97883A6B3F for ; Tue, 3 Jun 2008 08:55:50 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m53GqK3V757930; Tue, 3 Jun 2008 17:52:20 +0100 Received: from 86.218.101.217 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Tue, 3 Jun 2008 17:55:26 +0200 (CEST) Message-ID: <51644.86.218.101.217.1212508526.squirrel@www.isima.fr> In-Reply-To: <20080603152916.GB9212@elstar.local> References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> <20080603112216.GA8735@elstar.local> <20080603130331.GA8886@elstar.local> <51957.137.194.26.116.1212501329.squirrel@www.isima.fr> <20080603152916.GB9212@elstar.local> Date: Tue, 3 Jun 2008 17:55:26 +0200 (CEST) From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 03 Jun 2008 17:52:22 +0100 (WEST) Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear Juergen, > On Tue, Jun 03, 2008 at 03:55:29PM +0200, badra@isima.fr wrote: > The TLS document needs to describe in detail how the TLS transport for > NETCONF works and it should IMHO avoid saying anything about the other > transports at all. RFC 4741 is pretty clear that SSH is the mandatory > to implement transport and I trust operators that they will manage to > figure out which of the NETCONF transports or combinations thereof > make sense for their environments. Well, the only thing that TLS document brings from RFC4742 is tha a special character sequence ]]>]]> Current NETCONF messages don't include a message's length. This document uses consequently the same delimiter sequence defined in [RFC4742] and therefore the special character sequence, ]]>]]>, to delimit XML documents. I think a simple reference to RFC4742 is bettre than duplicating the text related to this special character sequence. > So I am back to my preference: do nothing concerning passwords in the > TLS transport document. I can live with that. I will remove the Appendix B, unless other members disagree. Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jun 3 08:56:46 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 624953A6ACC; Tue, 3 Jun 2008 08:56:46 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 219BC3A682B for ; Tue, 3 Jun 2008 08:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZrDJQ8V2956 for ; Tue, 3 Jun 2008 08:56:41 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id B97883A6B3F for ; Tue, 3 Jun 2008 08:55:50 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m53GqK3V757930; Tue, 3 Jun 2008 17:52:20 +0100 Received: from 86.218.101.217 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Tue, 3 Jun 2008 17:55:26 +0200 (CEST) Message-ID: <51644.86.218.101.217.1212508526.squirrel@www.isima.fr> In-Reply-To: <20080603152916.GB9212@elstar.local> References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> <20080603112216.GA8735@elstar.local> <20080603130331.GA8886@elstar.local> <51957.137.194.26.116.1212501329.squirrel@www.isima.fr> <20080603152916.GB9212@elstar.local> Date: Tue, 3 Jun 2008 17:55:26 +0200 (CEST) From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 03 Jun 2008 17:52:22 +0100 (WEST) Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear Juergen, > On Tue, Jun 03, 2008 at 03:55:29PM +0200, badra@isima.fr wrote: > The TLS document needs to describe in detail how the TLS transport for > NETCONF works and it should IMHO avoid saying anything about the other > transports at all. RFC 4741 is pretty clear that SSH is the mandatory > to implement transport and I trust operators that they will manage to > figure out which of the NETCONF transports or combinations thereof > make sense for their environments. Well, the only thing that TLS document brings from RFC4742 is tha a special character sequence ]]>]]> Current NETCONF messages don't include a message's length. This document uses consequently the same delimiter sequence defined in [RFC4742] and therefore the special character sequence, ]]>]]>, to delimit XML documents. I think a simple reference to RFC4742 is bettre than duplicating the text related to this special character sequence. > So I am back to my preference: do nothing concerning passwords in the > TLS transport document. I can live with that. I will remove the Appendix B, unless other members disagree. Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jun 3 12:05:41 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A3CC28C1D5; Tue, 3 Jun 2008 12:05:41 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9927228C197 for ; Tue, 3 Jun 2008 12:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkseY+FlbxTL for ; Tue, 3 Jun 2008 12:05:38 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 1C90B3A6AAE for ; Tue, 3 Jun 2008 12:01:06 -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 m53J182I006071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jun 2008 21:01:08 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m53J158K000785; Tue, 3 Jun 2008 21:01:07 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 21:01:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Jun 2008 21:01:04 +0200 Message-ID: In-Reply-To: <51644.86.218.101.217.1212508526.squirrel@www.isima.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords thread-index: AcjFklCUwXPSLJZGSMKPZI+m6jTVxgAGE1+w References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> <20080603112216.GA8735@elstar.local> <20080603130331.GA8886@elstar.local> <51957.137.194.26.116.1212501329.squirrel@www.isima.fr> <20080603152916.GB9212@elstar.local> <51644.86.218.101.217.1212508526.squirrel@www.isima.fr> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: , X-OriginalArrivalTime: 03 Jun 2008 19:01:05.0783 (UTC) FILETIME=[2CDDA870:01C8C5AC] Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > > So I am back to my preference: do nothing concerning passwords in the > > TLS transport document. > > > > /js > > I can live with that. I will remove the Appendix B, unless other members > disagree. > > Best regards, > Badra I can live with that too, go for it. Mehmet ___________________From netconf-bounces@ietf.org Tue Jun 3 12:05:41 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A3CC28C1D5; Tue, 3 Jun 2008 12:05:41 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9927228C197 for ; Tue, 3 Jun 2008 12:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkseY+FlbxTL for ; Tue, 3 Jun 2008 12:05:38 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 1C90B3A6AAE for ; Tue, 3 Jun 2008 12:01:06 -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 m53J182I006071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jun 2008 21:01:08 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m53J158K000785; Tue, 3 Jun 2008 21:01:07 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 21:01:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Jun 2008 21:01:04 +0200 Message-ID: In-Reply-To: <51644.86.218.101.217.1212508526.squirrel@www.isima.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords thread-index: AcjFklCUwXPSLJZGSMKPZI+m6jTVxgAGE1+w References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> <20080603112216.GA8735@elstar.local> <20080603130331.GA8886@elstar.local> <51957.137.194.26.116.1212501329.squirrel@www.isima.fr> <20080603152916.GB9212@elstar.local> <51644.86.218.101.217.1212508526.squirrel@www.isima.fr> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: , X-OriginalArrivalTime: 03 Jun 2008 19:01:05.0783 (UTC) FILETIME=[2CDDA870:01C8C5AC] Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > > So I am back to my preference: do nothing concerning passwords in the > > TLS transport document. > > > > /js > > I can live with that. I will remove the Appendix B, unless other members > disagree. > > Best regards, > Badra I can live with that too, go for it. 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 netconf-bounces@ietf.org Tue Jun 3 13:59:50 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A8873A6875; Tue, 3 Jun 2008 13:59:50 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DCD53A681D for ; Tue, 3 Jun 2008 13:59:49 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83jnsDbP7BRN for ; Tue, 3 Jun 2008 13:59:48 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by core3.amsl.com (Postfix) with ESMTP id 44E6B3A6875 for ; Tue, 3 Jun 2008 13:59:48 -0700 (PDT) Received: from df-bhd-01.exchange.corp.microsoft.com (157.54.111.57) by DF-GWY-05.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 3 Jun 2008 14:00:37 -0700 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.10]) by df-bhd-01.exchange.corp.microsoft.com ([157.54.111.57]) with mapi; Tue, 3 Jun 2008 14:00:37 -0700 From: Charlie Kaufman To: "Ersue, Mehmet (NSN - DE/Muenich)" , "badra@isima.fr" , "j.schoenwaelder@jacobs-university.de" Date: Tue, 3 Jun 2008 13:59:43 -0700 Thread-Topic: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords Thread-Index: AcjFklCUwXPSLJZGSMKPZI+m6jTVxgAGE1+wAAORjHA= Message-ID: <30C65F3A3407B943826897E025135BE6012077663F3E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> <20080603112216.GA8735@elstar.local> <20080603130331.GA8886@elstar.local> <51957.137.194.26.116.1212501329.squirrel@www.isima.fr> <20080603152916.GB9212@elstar.local> <51644.86.218.101.217.1212508526.squirrel@www.isima.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Let me try to summarize what I think is being proposed and the feedback on this thread. The problem to be solved is how to pass passwords from manager to agent in the case where TLS is the encapsulating security protocol and the password is to be used with third party authentication (so the agent must get the cleartext password from the manager without depending on any special manager-accessiblFrom netconf-bounces@ietf.org Tue Jun 3 13:59:50 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A8873A6875; Tue, 3 Jun 2008 13:59:50 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DCD53A681D for ; Tue, 3 Jun 2008 13:59:49 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83jnsDbP7BRN for ; Tue, 3 Jun 2008 13:59:48 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by core3.amsl.com (Postfix) with ESMTP id 44E6B3A6875 for ; Tue, 3 Jun 2008 13:59:48 -0700 (PDT) Received: from df-bhd-01.exchange.corp.microsoft.com (157.54.111.57) by DF-GWY-05.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 3 Jun 2008 14:00:37 -0700 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.10]) by df-bhd-01.exchange.corp.microsoft.com ([157.54.111.57]) with mapi; Tue, 3 Jun 2008 14:00:37 -0700 From: Charlie Kaufman To: "Ersue, Mehmet (NSN - DE/Muenich)" , "badra@isima.fr" , "j.schoenwaelder@jacobs-university.de" Date: Tue, 3 Jun 2008 13:59:43 -0700 Thread-Topic: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords Thread-Index: AcjFklCUwXPSLJZGSMKPZI+m6jTVxgAGE1+wAAORjHA= Message-ID: <30C65F3A3407B943826897E025135BE6012077663F3E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> <20080603112216.GA8735@elstar.local> <20080603130331.GA8886@elstar.local> <51957.137.194.26.116.1212501329.squirrel@www.isima.fr> <20080603152916.GB9212@elstar.local> <51644.86.218.101.217.1212508526.squirrel@www.isima.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Let me try to summarize what I think is being proposed and the feedback on this thread. The problem to be solved is how to pass passwords from manager to agent in the case where TLS is the encapsulating security protocol and the password is to be used with third party authentication (so the agent must get the cleartext password from the manager without depending on any special manager-accessible per-user state). Badra (in appendix B) presents 5 options: 1) Add a RPC to NETCONF in this specific scenario in order for the manager to pass the password over the encrypted TLS connection. This is somewhat of a layer violation, since authentication is not supposed to take place in the NETCONF protocol. Given that this exchange takes place only as the first exchange after the TLS connection is set up, one could architecturally pretend that it is part of TLS rather than part of NETCONF, but it really cheating. 2) Enhance TLS to permit passing an encrypted password as part of TLS authentication. From a security perspective, this is equivalent to (1), but it is architecturally correct (and it could be used by any protocol that runs over TLS and needs this feature). It would be most properly specified by the TLS WG, and they are unlikely to do it because they disapprove of building protocols to these requirements. 3) and 5) effectively say to not support third party password authentication over TLS, but rather recommend that implementers with such requirements implement BEEP or SSH as their encapsulating security protocol instead of TLS. This is also called the "do nothing" option. 4) This is like (1) except that instead of implementing a simple RPC, it implements an encapsulation of SASL. This is more work, but might cover more scenarios should there in the future be other authentication protocols that can be encapsulated in SASL. Like (1), it is a layer violation. My reading of this thread is that after confusion about options 3 and 5 were clarified, they were favored (by an admittedly small number of speakers). I agree with Badra that (2) is not going to happen - at least not anytime soon - and is therefore not a plausible solution for NETCONF TLS. Whether (3) and (5) (doing nothing) is acceptable is something I can't judge. Is TLS expected to be the primary protocol for NETCONF, or will SSH be more widely used. It is certainly the easiest solution. Between (1) and (4), I would prefer (1) because it is simpler. Until recently, (4) would have been much more politically acceptable to the Security ADs because in particular Sam Hartman was a fan of SASL. Who is your security AD now? Another argument in favor of doing nothing for now is that TLS may eventually implement something the encapsulates SASL, and if they do you will be able to use that new feature in an architecturally clean way. If you do (1) or (4) now, it will remain as legacy for you to maintain even after TLS is fixed. So I guess my recommendation is that you do nothing for now unless there is some urgent need and hope TLS gets enhanced before your need is urgent. If that doesn't happen, you might describe a simple option #1 in an informational or experimental RFC in order to attract less attention. --Charlie -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Tuesday, June 03, 2008 12:01 PM To: badra@isima.fr; j.schoenwaelder@jacobs-university.de Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords > > So I am back to my preference: do nothing concerning passwords in the > > TLS transport document. > > > > /js > > I can live with that. I will remove the Appendix B, unless other members > disagree. > > Best regards, > Badra I can live with that too, go for it. 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 e per-user state). Badra (in appendix B) presents 5 options: 1) Add a RPC to NETCONF in this specific scenario in order for the manager to pass the password over the encrypted TLS connection. This is somewhat of a layer violation, since authentication is not supposed to take place in the NETCONF protocol. Given that this exchange takes place only as the first exchange after the TLS connection is set up, one could architecturally pretend that it is part of TLS rather than part of NETCONF, but it really cheating. 2) Enhance TLS to permit passing an encrypted password as part of TLS authentication. From a security perspective, this is equivalent to (1), but it is architecturally correct (and it could be used by any protocol that runs over TLS and needs this feature). It would be most properly specified by the TLS WG, and they are unlikely to do it because they disapprove of building protocols to these requirements. 3) and 5) effectively say to not support third party password authentication over TLS, but rather recommend that implementers with such requirements implement BEEP or SSH as their encapsulating security protocol instead of TLS. This is also called the "do nothing" option. 4) This is like (1) except that instead of implementing a simple RPC, it implements an encapsulation of SASL. This is more work, but might cover more scenarios should there in the future be other authentication protocols that can be encapsulated in SASL. Like (1), it is a layer violation. My reading of this thread is that after confusion about options 3 and 5 were clarified, they were favored (by an admittedly small number of speakers). I agree with Badra that (2) is not going to happen - at least not anytime soon - and is therefore not a plausible solution for NETCONF TLS. Whether (3) and (5) (doing nothing) is acceptable is something I can't judge. Is TLS expected to be the primary protocol for NETCONF, or will SSH be more widely used. It is certainly the easiest solution. Between (1) and (4), I would prefer (1) because it is simpler. Until recently, (4) would have been much more politically acceptable to the Security ADs because in particular Sam Hartman was a fan of SASL. Who is your security AD now? Another argument in favor of doing nothing for now is that TLS may eventually implement something the encapsulates SASL, and if they do you will be able to use that new feature in an architecturally clean way. If you do (1) or (4) now, it will remain as legacy for you to maintain even after TLS is fixed. So I guess my recommendation is that you do nothing for now unless there is some urgent need and hope TLS gets enhanced before your need is urgent. If that doesn't happen, you might describe a simple option #1 in an informational or experimental RFC in order to attract less attention. --Charlie -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Tuesday, June 03, 2008 12:01 PM To: badra@isima.fr; j.schoenwaelder@jacobs-university.de Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords > > So I am back to my preference: do nothing concerning passwords in the > > TLS transport document. > > > > /js > > I can live with that. I will remove the Appendix B, unless other members > disagree. > > Best regards, > Badra I can live with that too, go for it. 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 netconf-bounces@ietf.org Wed Jun 4 09:01:55 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1237C3A6CB6; Wed, 4 Jun 2008 09:01:53 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACA503A6AF2 for ; Wed, 4 Jun 2008 09:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIR7hGYAUqJY for ; Wed, 4 Jun 2008 09:01:30 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 413723A68F0 for ; Wed, 4 Jun 2008 09:01:30 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2F8D8208DC; Wed, 4 Jun 2008 18:01:33 +0200 (CEST) X-AuditID: c1b4fb3c-ae09bbb00000193b-cd-4846bc5de08b Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 08D3220893; Wed, 4 Jun 2008 18:01:33 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jun 2008 18:01:32 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jun 2008 18:01:32 +0200 Message-ID: <4846BC5B.5080507@ericsson.com> Date: Wed, 04 Jun 2008 18:01:31 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Wes Hardaker References: In-Reply-To: X-OriginalArrivalTime: 04 Jun 2008 16:01:32.0225 (UTC) FILETIME=[41BCEB10:01C8C65C] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 and Action Items X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello Wes, (Catching up after being drowned by other work.) What would you expect to appear in the partial-lock draft about potential pitfalls of partial locking? In the last part of your mail you write: > A partial-lock is another form of a partial config and that was my only > point in the meeting. It doesn't add new problems, it just compounds > the study case. It already contains: "The system ensures that configuration resources covered by the lock are not be modified by other NETCONF or non-NETCONF management operations such as SNMP and the CLI." Would you like a chapter: Modifications to existing operations containing: Partial lock will prevent the execution of operations effecting the whole datastore e.g. commit, copy-config, delete-config if they would result in modifications to the locked area. regards Balazs Wes Hardaker wrote: >>>>>> "ME" == Mehmet Ersue writes: > > ME> => Wes Hardaker: > ME> Please post your questions on: > ME> - what happens if you copy candidate to running > ME> while a partial lock is held? > > Here's a quick summary about partial vs global commands. Locking is one > type of command that has both a global (in the core netconf model) and > partial (in the newly proposed partial locking draft). > > Global commands are those that operate on entire configuration > datastores at once. EG, , , , ... It > affects the whole configuration datastore or it doesn't. If, when > authorization comes along, a netconf user don't have write access to the > whole configuration store it's currently undefined as to what happens, > though some obvious things are probably apparent (a copy-config by a > user with restricted access shouldn't be allowed to change parts of a > config being copied TO that they're not authorized to change). > > Partial commands are those that operate on pieces of a configuration > datastore. Examples include and (I don't > remember the exact command name for that, unfortunately... That may not > be it). In these types commands the user will or will not have the > ability to execute the command based on what part of a datastore it's > acting upon. IE, a user will be prohibited from partically-locking a > part of a datastore it doesn't have the authorization to lock. > > > The trouble comes in when trying to mix these modes. Consider the case > where two different operators have different access rights to a > particular configuration datastore (if you want an example where this is > going to be required for new work, see > draft-hardaker-dnsops-name-server-management-reqs-02.txt which documents > management requirements for DNS management). If you have two different > users (say U1 and U2) that are responsible for separate pieces of the > configuration datastore you can run into conflicts between them. If, > for example, U1 has the ability to edit only the routing information and > U2 only has the ability to edit DNS service configuration then if > they're both trying to configure their parts of the system at the same > time then everything works just fine as long as they don't use any > global commands. > > EG, if they both partially lock their portions of "running", edit it, > and then unlock they'll never see problems. > > However, if they both partially lock the candidate config, edit it such > that there are outstanding changes to both the routing configuration and > the DNS service configuration then it's possible neither U1 nor U2 will > have access rights to perform the copy-config to actually copy the > changes made from the candidate to the running configuration. U1 won't > be able to since changes exist in the DNS configuration portion and he > doesn't have write access to that portion of the running config, and > vice-versa for U2 with respect to the routing configuration. > > A partial-lock is another form of a partial config and that was my only > point in the meeting. It doesn't add new problems, it just compounds > the study case. EG, if U2 partially locks the DNS service configuration > portion of running then it prevents U1 from performing a copy from > candidate to running which blocks U1 from the edit path they wished to > take. The only choice is for U1 to do edits only on running (or wait > for the partial-lock to be lifted which may be never if mal-intent is > involved). > > ME> - need a matrix that covers the various operations and their > ME> interaction > > That was just a comment that a "nice to have" piece of documentation > would be a chart that displayed which commands had what affect on which > pieces of the whole system. As new pieces/operations/commands keep > getting added to the system it gets more and more complex to study from > any perspective, and most importantly, a security perspective. > > > But to be clear I'm not misunderstood: I think partial-locking is a good > thing, not a bad thing. I actually think the system would be easier if > it disallowed global commands altogether. But that's another story for > another day and will only likely caused me to get flamed off the mailing > list ;-/ -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jun 4 09:01:55 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1237C3A6CB6; Wed, 4 Jun 2008 09:01:53 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACA503A6AF2 for ; Wed, 4 Jun 2008 09:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIR7hGYAUqJY for ; Wed, 4 Jun 2008 09:01:30 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 413723A68F0 for ; Wed, 4 Jun 2008 09:01:30 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2F8D8208DC; Wed, 4 Jun 2008 18:01:33 +0200 (CEST) X-AuditID: c1b4fb3c-ae09bbb00000193b-cd-4846bc5de08b Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 08D3220893; Wed, 4 Jun 2008 18:01:33 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jun 2008 18:01:32 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jun 2008 18:01:32 +0200 Message-ID: <4846BC5B.5080507@ericsson.com> Date: Wed, 04 Jun 2008 18:01:31 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Wes Hardaker References: In-Reply-To: X-OriginalArrivalTime: 04 Jun 2008 16:01:32.0225 (UTC) FILETIME=[41BCEB10:01C8C65C] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 and Action Items X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello Wes, (Catching up after being drowned by other work.) What would you expect to appear in the partial-lock draft about potential pitfalls of partial locking? In the last part of your mail you write: > A partial-lock is another form of a partial config and that was my only > point in the meeting. It doesn't add new problems, it just compounds > the study case. It already contains: "The system ensures that configuration resources covered by the lock are not be modified by other NETCONF or non-NETCONF management operations such as SNMP and the CLI." Would you like a chapter: Modifications to existing operations containing: Partial lock will prevent the execution of operations effecting the whole datastore e.g. commit, copy-config, delete-config if they would result in modifications to the locked area. regards Balazs Wes Hardaker wrote: >>>>>> "ME" == Mehmet Ersue writes: > > ME> => Wes Hardaker: > ME> Please post your questions on: > ME> - what happens if you copy candidate to running > ME> while a partial lock is held? > > Here's a quick summary about partial vs global commands. Locking is one > type of command that has both a global (in the core netconf model) and > partial (in the newly proposed partial locking draft). > > Global commands are those that operate on entire configuration > datastores at once. EG, , , , ... It > affects the whole configuration datastore or it doesn't. If, when > authorization comes along, a netconf user don't have write access to the > whole configuration store it's currently undefined as to what happens, > though some obvious things are probably apparent (a copy-config by a > user with restricted access shouldn't be allowed to change parts of a > config being copied TO that they're not authorized to change). > > Partial commands are those that operate on pieces of a configuration > datastore. Examples include and (I don't > remember the exact command name for that, unfortunately... That may not > be it). In these types commands the user will or will not have the > ability to execute the command based on what part of a datastore it's > acting upon. IE, a user will be prohibited from partically-locking a > part of a datastore it doesn't have the authorization to lock. > > > The trouble comes in when trying to mix these modes. Consider the case > where two different operators have different access rights to a > particular configuration datastore (if you want an example where this is > going to be required for new work, see > draft-hardaker-dnsops-name-server-management-reqs-02.txt which documents > management requirements for DNS management). If you have two different > users (say U1 and U2) that are responsible for separate pieces of the > configuration datastore you can run into conflicts between them. If, > for example, U1 has the ability to edit only the routing information and > U2 only has the ability to edit DNS service configuration then if > they're both trying to configure their parts of the system at the same > time then everything works just fine as long as they don't use any > global commands. > > EG, if they both partially lock their portions of "running", edit it, > and then unlock they'll never see problems. > > However, if they both partially lock the candidate config, edit it such > that there are outstanding changes to both the routing configuration and > the DNS service configuration then it's possible neither U1 nor U2 will > have access rights to perform the copy-config to actually copy the > changes made from the candidate to the running configuration. U1 won't > be able to since changes exist in the DNS configuration portion and he > doesn't have write access to that portion of the running config, and > vice-versa for U2 with respect to the routing configuration. > > A partial-lock is another form of a partial config and that was my only > point in the meeting. It doesn't add new problems, it just compounds > the study case. EG, if U2 partially locks the DNS service configuration > portion of running then it prevents U1 from performing a copy from > candidate to running which blocks U1 from the edit path they wished to > take. The only choice is for U1 to do edits only on running (or wait > for the partial-lock to be lifted which may be never if mal-intent is > involved). > > ME> - need a matrix that covers the various operations and their > ME> interaction > > That was just a comment that a "nice to have" piece of documentation > would be a chart that displayed which commands had what affect on which > pieces of the whole system. As new pieces/operations/commands keep > getting added to the system it gets more and more complex to study from > any perspective, and most importantly, a security perspective. > > > But to be clear I'm not misunderstood: I think partial-locking is a good > thing, not a bad thing. I actually think the system would be easier if > it disallowed global commands altogether. But that's another story for > another day and will only likely caused me to get flamed off the mailing > list ;-/ -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jun 4 15:57:39 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E5783A68FB; Wed, 4 Jun 2008 15:57:39 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A432C3A68DD for ; Wed, 4 Jun 2008 15:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfjZfGrGRr8V for ; Wed, 4 Jun 2008 15:57:37 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id E5AFC3A68A1 for ; Wed, 4 Jun 2008 15:57:35 -0700 (PDT) Received: (qmail 20052 invoked from network); 4 Jun 2008 22:57:38 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 4 Jun 2008 22:57:38 -0000 From: "Bert Wijnen - IETF" To: "Andy Bierman" , "David B Harrington" Date: Thu, 5 Jun 2008 00:57:42 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <484055D2.1090505@netconfcentral.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy and David, Sharon was/is trying to clarify some text in the security considerations section in order to address comments from the IESG review. I don't think we want to go through a long process of debating all the option we have for notifications. We do not have a (satndardized) ACM for NETCONF, and so we do not have to be explicit as to what exactly happens in all cases, do we? We have to warn/explain to the user what he needs to look out for when supporting enabling notifications. If you are not happy with the new text, can you then pls propose your text (as a minimum). Bert Wijnen > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > Andy Bierman > Verzonden: vrijdag 30 mei 2008 21:30 > Aan: David B Harrington > CC: netconf@ietf.org > Onderwerp: Re: [Netconf] Pre-13 Notification (take 2) > > > David B Harrington wrote: > > > > > >> The text is also confusing me because access control for > >> and are not the same at all. A response > >> will only exclude the unauthorized nested elements, and return > >> any other content the user is authorized to view. > >> > >> A must be buffered by the agent so that if any > >> unauthorized sub-nodes are encountered, the entire > >> is considered unauthorized (and dropped for that session). > >> > >> This makes some assumptions about how/why the > >> internal ACM is behaving in certain ways. Why iFrom netconf-bounces@ietf.org Wed Jun 4 15:57:39 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E5783A68FB; Wed, 4 Jun 2008 15:57:39 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A432C3A68DD for ; Wed, 4 Jun 2008 15:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfjZfGrGRr8V for ; Wed, 4 Jun 2008 15:57:37 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id E5AFC3A68A1 for ; Wed, 4 Jun 2008 15:57:35 -0700 (PDT) Received: (qmail 20052 invoked from network); 4 Jun 2008 22:57:38 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 4 Jun 2008 22:57:38 -0000 From: "Bert Wijnen - IETF" To: "Andy Bierman" , "David B Harrington" Date: Thu, 5 Jun 2008 00:57:42 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <484055D2.1090505@netconfcentral.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy and David, Sharon was/is trying to clarify some text in the security considerations section in order to address comments from the IESG review. I don't think we want to go through a long process of debating all the option we have for notifications. We do not have a (satndardized) ACM for NETCONF, and so we do not have to be explicit as to what exactly happens in all cases, do we? We have to warn/explain to the user what he needs to look out for when supporting enabling notifications. If you are not happy with the new text, can you then pls propose your text (as a minimum). Bert Wijnen > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > Andy Bierman > Verzonden: vrijdag 30 mei 2008 21:30 > Aan: David B Harrington > CC: netconf@ietf.org > Onderwerp: Re: [Netconf] Pre-13 Notification (take 2) > > > David B Harrington wrote: > > > > > >> The text is also confusing me because access control for > >> and are not the same at all. A response > >> will only exclude the unauthorized nested elements, and return > >> any other content the user is authorized to view. > >> > >> A must be buffered by the agent so that if any > >> unauthorized sub-nodes are encountered, the entire > >> is considered unauthorized (and dropped for that session). > >> > >> This makes some assumptions about how/why the > >> internal ACM is behaving in certain ways. s is OK > >> for a to drop only the unauthorized content, but > >> it is not OK for a to do the same thing, > >> even for the exact same subset of data? > > > > I agree with this concern about embedded assumptions. > > > > In SNMPv3, if a principal is not allowed access to all the varbinds in > > the notification, the notification gets dropped. This makes sense in > > SNMP because we define the varbinds that must be in the notification > > (although even if an appended varbind is not authorized the whole > > thing gets dropped). > > > > I am not sure this must-drop-behavior should be a requirement for the > > **protocol** definition of Netconf notifications, especially if > > Netconf notifications might carry data from SNMP or syslog. This > > should probably be a function of the access control model(s), not the > > protocol. > > I am also concerned about a MUST drop directive cast-in-stone, > without much thought about the overall access control model or > security use cases. > > Clearly, the method needs to work as currently defined. > NETCONF would be completely unusable if an operator had to > specify exact leafs to retrieve because access control on some > nested subtree causes normal filters to be unusable. > > Won't the all-or-nothing restriction cause similar problems > for operators wrt/ notification receiver applications? > Won't this force data model writers to create multiple > versions of any notification that includes some (but not all) > sensitive data? > > SNMP is somewhat different because the varbinds are all leafs > and non-extensible. NETCONF content can be complex, nested, > and include multiple namespaces. The likelihood that a > complex structure sill have some optional (yet sensitive) data > is much higher. SNMP is UDP-based, and very few mandatory varbinds > are usually defined for a notification. If implementors take > advantage of NETCONF's unlimited notification payload size, > this all-or-nothing restriction is going to become a DM design > factor. This would be a serious protocol design flaw. > > It should be up to the network administrator, not the protocol, > to decide how access control should handle notification content > (and all other content). > > At a minimum, the draft should explain in detail why the > entire notification must be dropped but no access control > restrictions for other types of NETCONF operations exist at all. > Explain the access control model in detail or take out the > ad-hoc bits and pieces. > > Andy > > > > > > -- > > There may be a case for arguing that notifications are different than > > . If a system reports on an event, specifying certain related > > information, and the subscription only allows the operator to see a > > subset of the information, might that be misleading to the operator? > > In SNMPv1, we had to deal with implementations that, when they didn't > > support a counter, returned a zero value. This was misleading because, > > even if the underlying functionality was operating, and the events > > that were to be counted (e.g., packets out) occurred, the SNMP > > counters still said '0'. We want to avoid misleading the operator. > > > > Would reporting only part of the data, and not reporting exceptions > > for the missing data, be worse than reporting no data for some events? > > Would reporting exceptions for the missing data be a problem because > > it gives an attacker information about what a user is not authorized > > to see? > > > > Maybe the data model for notification definitions should be able to > > specify whether 1) all info must be authorized or do not send, or 2) > > unauthorized data should have an exception reported, or 3) partial > > data is acceptable. > > > > I think an access control model is a better place than either the > > protocol or the data model to make such a determination. I can > > envision wanting to let the helpdesk (support level 1) receive an > > alert with only partial information to make him aware that an event > > occurred, while a level 2 support Why is is OK > >> for a to drop only the unauthorized content, but > >> it is not OK for a to do the same thing, > >> even for the exact same subset of data? > > > > I agree with this concern about embedded assumptions. > > > > In SNMPv3, if a principal is not allowed access to all the varbinds in > > the notification, the notification gets dropped. This makes sense in > > SNMP because we define the varbinds that must be in the notification > > (although even if an appended varbind is not authorized the whole > > thing gets dropped). > > > > I am not sure this must-drop-behavior should be a requirement for the > > **protocol** definition of Netconf notifications, especially if > > Netconf notifications might carry data from SNMP or syslog. This > > should probably be a function of the access control model(s), not the > > protocol. > > I am also concerned about a MUST drop directive cast-in-stone, > without much thought about the overall access control model or > security use cases. > > Clearly, the method needs to work as currently defined. > NETCONF would be completely unusable if an operator had to > specify exact leafs to retrieve because access control on some > nested subtree causes normal filters to be unusable. > > Won't the all-or-nothing restriction cause similar problems > for operators wrt/ notification receiver applications? > Won't this force data model writers to create multiple > versions of any notification that includes some (but not all) > sensitive data? > > SNMP is somewhat different because the varbinds are all leafs > and non-extensible. NETCONF content can be complex, nested, > and include multiple namespaces. The likelihood that a > complex structure sill have some optional (yet sensitive) data > is much higher. SNMP is UDP-based, and very few mandatory varbinds > are usually defined for a notification. If implementors take > advantage of NETCONF's unlimited notification payload size, > this all-or-nothing restriction is going to become a DM design > factor. This would be a serious protocol design flaw. > > It should be up to the network administrator, not the protocol, > to decide how access control should handle notification content > (and all other content). > > At a minimum, the draft should explain in detail why the > entire notification must be dropped but no access control > restrictions for other types of NETCONF operations exist at all. > Explain the access control model in detail or take out the > ad-hoc bits and pieces. > > Andy > > > > > > -- > > There may be a case for arguing that notifications are different than > > . If a system reports on an event, specifying certain related > > information, and the subscription only allows the operator to see a > > subset of the information, might that be misleading to the operator? > > In SNMPv1, we had to deal with implementations that, when they didn't > > support a counter, returned a zero value. This was misleading because, > > even if the underlying functionality was operating, and the events > > that were to be counted (e.g., packets out) occurred, the SNMP > > counters still said '0'. We want to avoid misleading the operator. > > > > Would reporting only part of the data, and not reporting exceptions > > for the missing data, be worse than reporting no data for some events? > > Would reporting exceptions for the missing data be a problem because > > it gives an attacker information about what a user is not authorized > > to see? > > > > Maybe the data model for notification definitions should be able to > > specify whether 1) all info must be authorized or do not send, or 2) > > unauthorized data should have an exception reported, or 3) partial > > data is acceptable. > > > > I think an access control model is a better place than either the > > protocol or the data model to make such a determination. I can > > envision wanting to let the helpdesk (support level 1) receive an > > alert with only partial information to make him aware that an event > > occurred, while a level 2 superson can subscribe for the same > > notification, and get more (potentially sensitive) information in the > > notification he receives. > > > > But I am not an operator, and operators may be fine with an > > all-or-nothing decision. > > > > dbh > > > > > > > > > > > > > _______________________________________________ > 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 pport person can subscribe for the same > > notification, and get more (potentially sensitive) information in the > > notification he receives. > > > > But I am not an operator, and operators may be fine with an > > all-or-nothing decision. > > > > dbh > > > > > > > > > > > > > _______________________________________________ > 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 netconf-bounces@ietf.org Wed Jun 4 17:36:41 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE3813A69CE; Wed, 4 Jun 2008 17:36:40 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1BF53A6919 for ; Wed, 4 Jun 2008 17:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byiAEkM33Lof for ; Wed, 4 Jun 2008 17:36:39 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id E62B43A68BC for ; Wed, 4 Jun 2008 17:36:38 -0700 (PDT) Received: (qmail 5082 invoked from network); 5 Jun 2008 00:36:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.69 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 5 Jun 2008 00:36:37 -0000 X-YMail-OSG: H3pmWWoVM1lzK7T6eO.uOsoerxMsQlJd3ILH_TdWEG4VQO9NB_DzPP5SdES.b5Tx48onRTFyr1Ixmilk_B.PSp0UF.t1DkWKIWH7sYLP8Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48473512.6070306@netconfcentral.com> Date: Wed, 04 Jun 2008 17:36:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Bert Wijnen - IETF References: In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Bert Wijnen - IETF wrote: > Andy and David, > > Sharon was/is trying to clarify some text in the security > considerations section in order to address comments from > the IESG review. > > I don't think we want to go through a long process of > debating all the option we have for notifications. We do not > have a (satndardized) ACM for NETCONF, and so we do not have > to be explicit as to what exactly happens in all cases, > do we? We have to warn/explain to the user what he needs > to look out for when supporting enabling notifications. > > If you are not happy with the new text, can you then pls > propose your text (as a minimum). I am not happy with the text because typical notification receiver deployment (via a dispatcher) may break because of 3 words. Even the use-case that Sharon proposed breaks if the tree showing the edit-config or commit changes contains any restricted config. IMO, the operator should decide if circumstances favor pruning a restricted subtree, rather than dropping the whole notification. pg 35, para 7, sentence 2: OLD: If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user. ^^^^^^ NEW: If a user is not authorized to view all elements in the content of the notification, the notification SHOULD NOT be sent to that user. ^^^^^^^^^^^^^ This new text leaves some room for conditions under which it would be OK to prune instead of drop. When the WG adds a coherent and well-thought-out ACM in the future for all of NETCONF (not just one verb), this issue might come up again. > > Bert Wijnen Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jun 4 17:36:41 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE3813A69CE; Wed, 4 Jun 2008 17:36:40 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1BF53A6919 for ; Wed, 4 Jun 2008 17:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byiAEkM33Lof for ; Wed, 4 Jun 2008 17:36:39 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id E62B43A68BC for ; Wed, 4 Jun 2008 17:36:38 -0700 (PDT) Received: (qmail 5082 invoked from network); 5 Jun 2008 00:36:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.69 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 5 Jun 2008 00:36:37 -0000 X-YMail-OSG: H3pmWWoVM1lzK7T6eO.uOsoerxMsQlJd3ILH_TdWEG4VQO9NB_DzPP5SdES.b5Tx48onRTFyr1Ixmilk_B.PSp0UF.t1DkWKIWH7sYLP8Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48473512.6070306@netconfcentral.com> Date: Wed, 04 Jun 2008 17:36:34 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Bert Wijnen - IETF References: In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Bert Wijnen - IETF wrote: > Andy and David, > > Sharon was/is trying to clarify some text in the security > considerations section in order to address comments from > the IESG review. > > I don't think we want to go through a long process of > debating all the option we have for notifications. We do not > have a (satndardized) ACM for NETCONF, and so we do not have > to be explicit as to what exactly happens in all cases, > do we? We have to warn/explain to the user what he needs > to look out for when supporting enabling notifications. > > If you are not happy with the new text, can you then pls > propose your text (as a minimum). I am not happy with the text because typical notification receiver deployment (via a dispatcher) may break because of 3 words. Even the use-case that Sharon proposed breaks if the tree showing the edit-config or commit changes contains any restricted config. IMO, the operator should decide if circumstances favor pruning a restricted subtree, rather than dropping the whole notification. pg 35, para 7, sentence 2: OLD: If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user. ^^^^^^ NEW: If a user is not authorized to view all elements in the content of the notification, the notification SHOULD NOT be sent to that user. ^^^^^^^^^^^^^ This new text leaves some room for conditions under which it would be OK to prune instead of drop. When the WG adds a coherent and well-thought-out ACM in the future for all of NETCONF (not just one verb), this issue might come up again. > > Bert Wijnen Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jun 4 20:39:09 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56FF3A6B2D; Wed, 4 Jun 2008 20:39:09 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 911BA3A695F for ; Wed, 4 Jun 2008 20:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZBAPnWzWfRu for ; Wed, 4 Jun 2008 20:39:07 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id AACE93A6974 for ; Wed, 4 Jun 2008 20:39:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=cbspeeBq+RKJA19q7DzdRFBTogYwo1uIQeCxLFiV9hJRxtAm7sYC5dT5mqjL7tW5; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.188.58] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1K46Jh-0004vt-8H for netconf@ietf.org; Wed, 04 Jun 2008 23:39:09 -0400 Message-ID: <000d01c8c6bd$cb60daa0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <48473512.6070306@netconfcentral.com> Date: Wed, 4 Jun 2008 20:39:42 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b33d7909def4cefd3c6466a75117f7aa7e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.188.58 Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi - > From: "Andy Bierman" > To: "Bert Wijnen - IETF" > Cc: > Sent: Wednesday, June 04, 2008 5:36 PM > Subject: Re: [Netconf] Pre-13 Notification (take 2) ... > I am not happy with the text because typical notification > receiver deployment (via a dispatcher) may break because of 3 words. > Even the use-case that Sharon proposed breaks > if the tree showing the edit-config or commit changes contains > any restricted config. IMO, the operator should decide if > circumstances favor pruning a restricted subtree, rather > than dropping the whole notification. > > > pg 35, para 7, sentence 2: > > OLD: > > If a user is not > authorized to view all elements in the content of the notification, > the notification is not sent to that user. > ^^^^^^ > > NEW: > > If a user is not > authorized to view all elements in the content of the notification, > the notification SHOULD NOT be sent to that user. > ^^^^^^^^^^^^^ > > > This new text leaves some room for conditions under which > it would be OK to prune instead of drop. When the WG > adds a coherent and well-thought-out ACM in the future > for all of NETCONF (not just one verb), this issue might > come up again. ... I don't see how the new text permits what you seem to want. It's still phrased in terms of whether the notification is sent, not in terms of permissible transformations of the notification payload, which is what you seem to be talking about. Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jun 4 20:39:09 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56FF3A6B2D; Wed, 4 Jun 2008 20:39:09 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 911BA3A695F for ; Wed, 4 Jun 2008 20:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZBAPnWzWfRu for ; Wed, 4 Jun 2008 20:39:07 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id AACE93A6974 for ; Wed, 4 Jun 2008 20:39:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=cbspeeBq+RKJA19q7DzdRFBTogYwo1uIQeCxLFiV9hJRxtAm7sYC5dT5mqjL7tW5; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.188.58] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1K46Jh-0004vt-8H for netconf@ietf.org; Wed, 04 Jun 2008 23:39:09 -0400 Message-ID: <000d01c8c6bd$cb60daa0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <48473512.6070306@netconfcentral.com> Date: Wed, 4 Jun 2008 20:39:42 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b33d7909def4cefd3c6466a75117f7aa7e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.188.58 Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi - > From: "Andy Bierman" > To: "Bert Wijnen - IETF" > Cc: > Sent: Wednesday, June 04, 2008 5:36 PM > Subject: Re: [Netconf] Pre-13 Notification (take 2) ... > I am not happy with the text because typical notification > receiver deployment (via a dispatcher) may break because of 3 words. > Even the use-case that Sharon proposed breaks > if the tree showing the edit-config or commit changes contains > any restricted config. IMO, the operator should decide if > circumstances favor pruning a restricted subtree, rather > than dropping the whole notification. > > > pg 35, para 7, sentence 2: > > OLD: > > If a user is not > authorized to view all elements in the content of the notification, > the notification is not sent to that user. > ^^^^^^ > > NEW: > > If a user is not > authorized to view all elements in the content of the notification, > the notification SHOULD NOT be sent to that user. > ^^^^^^^^^^^^^ > > > This new text leaves some room for conditions under which > it would be OK to prune instead of drop. When the WG > adds a coherent and well-thought-out ACM in the future > for all of NETCONF (not just one verb), this issue might > come up again. ... I don't see how the new text permits what you seem to want. It's still phrased in terms of whether the notification is sent, not in terms of permissible transformations of the notification payload, which is what you seem to be talking about. Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 5 01:29:51 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51B73A6BEA; Thu, 5 Jun 2008 01:29:51 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EBA43A6BD2 for ; Thu, 5 Jun 2008 01:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jg-kkcTjbdzV for ; Thu, 5 Jun 2008 01:29:46 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0E76E3A67DA for ; Thu, 5 Jun 2008 01:29:43 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2EAC62100D for ; Thu, 5 Jun 2008 10:29:48 +0200 (CEST) X-AuditID: c1b4fb3e-ae999bb000004ec0-09-4847a3fc8b7a Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 16E6F20570 for ; Thu, 5 Jun 2008 10:29:48 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jun 2008 10:29:33 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jun 2008 10:29:33 +0200 Message-ID: <4847A3EC.3030609@ericsson.com> Date: Thu, 05 Jun 2008 10:29:32 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf@ietf.org X-OriginalArrivalTime: 05 Jun 2008 08:29:33.0239 (UTC) FILETIME=[47F9CC70:01C8C6E6] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Capability to handle the full configuration in one operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, Recently I came across 2 cases where it is difficult to handle the complete datastore in one operation due to memory constraints: 1) Big nodes that contain subscriber data might have multiple gigaBytes in their datastore. It does not seem feasible to handle the complete datastore in one edit-config. 2) Small nodes that don't have enough memory to store their configuration in XML format in addition to the internal binary format. Can these nodes still claim to be NETCONF compliant or is it a MUST that an edit-config containing the full datastore must be handled irrespective from memory constraints? Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 5 01:29:51 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51B73A6BEA; Thu, 5 Jun 2008 01:29:51 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EBA43A6BD2 for ; Thu, 5 Jun 2008 01:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jg-kkcTjbdzV for ; Thu, 5 Jun 2008 01:29:46 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0E76E3A67DA for ; Thu, 5 Jun 2008 01:29:43 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2EAC62100D for ; Thu, 5 Jun 2008 10:29:48 +0200 (CEST) X-AuditID: c1b4fb3e-ae999bb000004ec0-09-4847a3fc8b7a Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 16E6F20570 for ; Thu, 5 Jun 2008 10:29:48 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jun 2008 10:29:33 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jun 2008 10:29:33 +0200 Message-ID: <4847A3EC.3030609@ericsson.com> Date: Thu, 05 Jun 2008 10:29:32 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf@ietf.org X-OriginalArrivalTime: 05 Jun 2008 08:29:33.0239 (UTC) FILETIME=[47F9CC70:01C8C6E6] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Capability to handle the full configuration in one operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, Recently I came across 2 cases where it is difficult to handle the complete datastore in one operation due to memory constraints: 1) Big nodes that contain subscriber data might have multiple gigaBytes in their datastore. It does not seem feasible to handle the complete datastore in one edit-config. 2) Small nodes that don't have enough memory to store their configuration in XML format in addition to the internal binary format. Can these nodes still claim to be NETCONF compliant or is it a MUST that an edit-config containing the full datastore must be handled irrespective from memory constraints? Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 5 01:44:17 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6AE23A6C7B; Thu, 5 Jun 2008 01:44:17 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15D503A6BF0 for ; Thu, 5 Jun 2008 01:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azHjNNYsSEJj for ; Thu, 5 Jun 2008 01:44:15 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 5103D3A6BBF for ; Thu, 5 Jun 2008 01:44:15 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id DF4101B80C5; Thu, 5 Jun 2008 10:44:19 +0200 (CEST) Date: Thu, 05 Jun 2008 10:44:20 +0200 (CEST) Message-Id: <20080605.104420.03387265.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <4847A3EC.3030609@ericsson.com> References: <4847A3EC.3030609@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Capability to handle the full configuration in one operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Balazs Lengyel wrote: > Hello, > Recently I came across 2 cases where it is difficult to handle the > complete datastore in one operation due to memory constraints: [...] > Can these nodes still claim to be NETCONF compliant or is it a MUST > that an edit-config containing the full datastore must be handled > irrespective from memory constraints? You can always return the std error code 'resource-denied', which is describes as: Request could not be completed because of insufficient resources. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 5 01:44:17 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6AE23A6C7B; Thu, 5 Jun 2008 01:44:17 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15D503A6BF0 for ; Thu, 5 Jun 2008 01:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azHjNNYsSEJj for ; Thu, 5 Jun 2008 01:44:15 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 5103D3A6BBF for ; Thu, 5 Jun 2008 01:44:15 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id DF4101B80C5; Thu, 5 Jun 2008 10:44:19 +0200 (CEST) Date: Thu, 05 Jun 2008 10:44:20 +0200 (CEST) Message-Id: <20080605.104420.03387265.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <4847A3EC.3030609@ericsson.com> References: <4847A3EC.3030609@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Capability to handle the full configuration in one operation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Balazs Lengyel wrote: > Hello, > Recently I came across 2 cases where it is difficult to handle the > complete datastore in one operation due to memory constraints: [...] > Can these nodes still claim to be NETCONF compliant or is it a MUST > that an edit-config containing the full datastore must be handled > irrespective from memory constraints? You can always return the std error code 'resource-denied', which is describes as: Request could not be completed because of insufficient resources. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 5 04:08:55 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0673928C173; Thu, 5 Jun 2008 04:08:55 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEABB28C17A for ; Thu, 5 Jun 2008 04:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32pfNfKYo5Qu for ; Thu, 5 Jun 2008 04:08:52 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id D5D6128C179 for ; Thu, 5 Jun 2008 04:08:51 -0700 (PDT) Received: (qmail 41007 invoked from network); 5 Jun 2008 11:08:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.69 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 5 Jun 2008 11:08:51 -0000 X-YMail-OSG: APDWczcVM1mOkyEPV89bYHhbAwSEP7sgd99sUIIkh6b_TNq8pKhltK1jhkW63tcFsGuVW7wAN4mGWWCGEydRBqkvw41vQjhnENczZGydPjJL5X2lA4QSR12kI5aREf92CIY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4847C941.6000401@netconfcentral.com> Date: Thu, 05 Jun 2008 04:08:49 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Randy Presuhn References: <48473512.6070306@netconfcentral.com> <000d01c8c6bd$cb60daa0$6801a8c0@oemcomputer> In-Reply-To: <000d01c8c6bd$cb60daa0$6801a8c0@oemcomputer> Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Bert Wijnen - IETF" >> Cc: >> Sent: Wednesday, June 04, 2008 5:36 PM >> Subject: Re: [Netconf] Pre-13 Notification (take 2) > ... >> I am not happy with the text because typical notification >> receiver deployment (via a dispatcher) may break because of 3 words. >> Even the use-case that Sharon proposed breaks >> if the tree showing the edit-config or commit changes contains >> any restricted config. IMO, the operator should decide if >> circumstances favor pruning a restricted subtree, rather >> than dropping the whole notification. >> >> >> pg 35, para 7, sentence 2: >> >> OLD: >> >> If a user is not >> authorized to view all elements in the content of the notification, >> the notification is not sent to that user. >> ^^^^^^ >> >> NEW: >> >> If a user is not >> authorized to view all elements in the content of the notification, >> the notification SHOULD NOT be sent to that user. >> ^^^^^^^^^^^^^ >> >> >> This new text leaves some room for conditions under which >> it would be OK to prune instead of drop. When the WG From netconf-bounces@ietf.org Thu Jun 5 04:08:55 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0673928C173; Thu, 5 Jun 2008 04:08:55 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEABB28C17A for ; Thu, 5 Jun 2008 04:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32pfNfKYo5Qu for ; Thu, 5 Jun 2008 04:08:52 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id D5D6128C179 for ; Thu, 5 Jun 2008 04:08:51 -0700 (PDT) Received: (qmail 41007 invoked from network); 5 Jun 2008 11:08:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.69 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 5 Jun 2008 11:08:51 -0000 X-YMail-OSG: APDWczcVM1mOkyEPV89bYHhbAwSEP7sgd99sUIIkh6b_TNq8pKhltK1jhkW63tcFsGuVW7wAN4mGWWCGEydRBqkvw41vQjhnENczZGydPjJL5X2lA4QSR12kI5aREf92CIY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4847C941.6000401@netconfcentral.com> Date: Thu, 05 Jun 2008 04:08:49 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Randy Presuhn References: <48473512.6070306@netconfcentral.com> <000d01c8c6bd$cb60daa0$6801a8c0@oemcomputer> In-Reply-To: <000d01c8c6bd$cb60daa0$6801a8c0@oemcomputer> Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Bert Wijnen - IETF" >> Cc: >> Sent: Wednesday, June 04, 2008 5:36 PM >> Subject: Re: [Netconf] Pre-13 Notification (take 2) > ... >> I am not happy with the text because typical notification >> receiver deployment (via a dispatcher) may break because of 3 words. >> Even the use-case that Sharon proposed breaks >> if the tree showing the edit-config or commit changes contains >> any restricted config. IMO, the operator should decide if >> circumstances favor pruning a restricted subtree, rather >> than dropping the whole notification. >> >> >> pg 35, para 7, sentence 2: >> >> OLD: >> >> If a user is not >> authorized to view all elements in the content of the notification, >> the notification is not sent to that user. >> ^^^^^^ >> >> NEW: >> >> If a user is not >> authorized to view all elements in the content of the notification, >> the notification SHOULD NOT be sent to that user. >> ^^^^^^^^^^^^^ >> >> >> This new text leaves some room for conditions under which >> it would be OK to prune instead of drop. When t>> adds a coherent and well-thought-out ACM in the future >> for all of NETCONF (not just one verb), this issue might >> come up again. > ... > > I don't see how the new text permits what you seem to want. > It's still phrased in terms of whether the notification is sent, > not in terms of permissible transformations of the notification > payload, which is what you seem to be talking about. > I prefer to remove this sentence from the draft entirely. If I am the only one who thinks that blindly following what SNMP did is a bad idea, then fine. I ask newbie security questions like "how come pruning data is fine for but not for ?" Clearly, any data that can be retrieved with a can also be transported as a , yet they generate very different security concerns within the IESG. > Randy Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf he WG >> adds a coherent and well-thought-out ACM in the future >> for all of NETCONF (not just one verb), this issue might >> come up again. > ... > > I don't see how the new text permits what you seem to want. > It's still phrased in terms of whether the notification is sent, > not in terms of permissible transformations of the notification > payload, which is what you seem to be talking about. > I prefer to remove this sentence from the draft entirely. If I am the only one who thinks that blindly following what SNMP did is a bad idea, then fine. I ask newbie security questions like "how come pruning data is fine for but not for ?" Clearly, any data that can be retrieved with a can also be transported as a , yet they generate very different security concerns within the IESG. > Randy Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 5 04:15:13 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0C4B28C1E0; Thu, 5 Jun 2008 04:15:13 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6744028C168 for ; Thu, 5 Jun 2008 04:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tr8rbftT2m7n for ; Thu, 5 Jun 2008 04:15:08 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 9768A28C145 for ; Thu, 5 Jun 2008 04:15:08 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 62AEF1B80C8; Thu, 5 Jun 2008 13:15:13 +0200 (CEST) Date: Thu, 05 Jun 2008 13:15:14 +0200 (CEST) Message-Id: <20080605.131514.04372074.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4847C941.6000401@netconfcentral.com> References: <48473512.6070306@netconfcentral.com> <000d01c8c6bd$cb60daa0$6801a8c0@oemcomputer> <4847C941.6000401@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > I ask newbie security questions like "how come pruning data > is fine for but not for ?" I agree with Andy that the text should not preclude pruning data in notifications. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 5 04:15:13 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0C4B28C1E0; Thu, 5 Jun 2008 04:15:13 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6744028C168 for ; Thu, 5 Jun 2008 04:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tr8rbftT2m7n for ; Thu, 5 Jun 2008 04:15:08 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 9768A28C145 for ; Thu, 5 Jun 2008 04:15:08 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 62AEF1B80C8; Thu, 5 Jun 2008 13:15:13 +0200 (CEST) Date: Thu, 05 Jun 2008 13:15:14 +0200 (CEST) Message-Id: <20080605.131514.04372074.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4847C941.6000401@netconfcentral.com> References: <48473512.6070306@netconfcentral.com> <000d01c8c6bd$cb60daa0$6801a8c0@oemcomputer> <4847C941.6000401@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > I ask newbie security questions like "how come pruning data > is fine for but not for ?" I agree with Andy that the text should not preclude pruning data in notifications. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 5 05:29:41 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881D93A6CB7; Thu, 5 Jun 2008 05:29:41 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C4E43A6862 for ; Thu, 5 Jun 2008 05:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyr7B-dJTlKB for ; Thu, 5 Jun 2008 05:29:36 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E4D5328C17A for ; Thu, 5 Jun 2008 05:26:42 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 408D92084B; Thu, 5 Jun 2008 14:26:47 +0200 (CEST) X-AuditID: c1b4fb3c-ae09bbb00000193b-83-4847db871b4d Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2D7C3207A6; Thu, 5 Jun 2008 14:26:47 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jun 2008 14:26:46 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jun 2008 14:26:46 +0200 Message-ID: <4847DB86.2080803@ericsson.com> Date: Thu, 05 Jun 2008 14:26:46 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <48473512.6070306@netconfcentral.com> <000d01c8c6bd$cb60daa0$6801a8c0@oemcomputer> <4847C941.6000401@netconfcentral.com> <20080605.131514.04372074.mbj@tail-f.com> In-Reply-To: <20080605.131514.04372074.mbj@tail-f.com> X-OriginalArrivalTime: 05 Jun 2008 12:26:46.0250 (UTC) FILETIME=[6B82ECA0:01C8C707] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I also agree with Andy and Martin. Balazs Martin Bjorklund wrote: > Andy Bierman wrote: >> I ask newbie security questions like "how come pruning data >> is fine for but not for ?" > > I agree with Andy that the text should not preclude pruning data in > notifications. > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 5 05:29:41 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881D93A6CB7; Thu, 5 Jun 2008 05:29:41 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C4E43A6862 for ; Thu, 5 Jun 2008 05:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyr7B-dJTlKB for ; Thu, 5 Jun 2008 05:29:36 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E4D5328C17A for ; Thu, 5 Jun 2008 05:26:42 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 408D92084B; Thu, 5 Jun 2008 14:26:47 +0200 (CEST) X-AuditID: c1b4fb3c-ae09bbb00000193b-83-4847db871b4d Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2D7C3207A6; Thu, 5 Jun 2008 14:26:47 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jun 2008 14:26:46 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jun 2008 14:26:46 +0200 Message-ID: <4847DB86.2080803@ericsson.com> Date: Thu, 05 Jun 2008 14:26:46 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <48473512.6070306@netconfcentral.com> <000d01c8c6bd$cb60daa0$6801a8c0@oemcomputer> <4847C941.6000401@netconfcentral.com> <20080605.131514.04372074.mbj@tail-f.com> In-Reply-To: <20080605.131514.04372074.mbj@tail-f.com> X-OriginalArrivalTime: 05 Jun 2008 12:26:46.0250 (UTC) FILETIME=[6B82ECA0:01C8C707] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I also agree with Andy and Martin. Balazs Martin Bjorklund wrote: > Andy Bierman wrote: >> I ask newbie security questions like "how come pruning data >> is fine for but not for ?" > > I agree with Andy that the text should not preclude pruning data in > notifications. > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 5 07:30:03 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DE1628C180; Thu, 5 Jun 2008 07:30:03 -0700 (PDT) X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3ED1A3A6ABF; Thu, 5 Jun 2008 07:30:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080605143001.3ED1A3A6ABF@core3.amsl.com> Date: Thu, 5 Jun 2008 07:30:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-tls-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --NextPart 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) : M. Badra, I. Hajjeh Filename : draft-ietf-netconf-tls-03.txt Pages : 11 Date : 2008-06-05 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 Protocol (TLS) to secure NETCONF exchanges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-tls-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-05072325.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --NextPart-- From netconf-bounces@ietf.org Thu Jun 5 07:30:03 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DE1628C180; Thu, 5 Jun 2008 07:30:03 -0700 (PDT) X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3ED1A3A6ABF; Thu, 5 Jun 2008 07:30:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080605143001.3ED1A3A6ABF@core3.amsl.com> Date: Thu, 5 Jun 2008 07:30:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-tls-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --NextPart 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) : M. Badra, I. Hajjeh Filename : draft-ietf-netconf-tls-03.txt Pages : 11 Date : 2008-06-05 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 Protocol (TLS) to secure NETCONF exchanges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-tls-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-05072325.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --NextPart-- From netconf-bounces@ietf.org Thu Jun 5 07:49:52 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D674428C25C; Thu, 5 Jun 2008 07:49:52 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2773C28C254 for ; Thu, 5 Jun 2008 07:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfldhU5EKfWP for ; Thu, 5 Jun 2008 07:49:46 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 6FC7828C261 for ; Thu, 5 Jun 2008 07:47:59 -0700 (PDT) Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m55FiUSV749794; Thu, 5 Jun 2008 16:44:31 +0100 Message-ID: <4847FC6A.3040205@isima.fr> Date: Thu, 05 Jun 2008 16:47:06 +0200 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: netconf@ietf.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Thu, 05 Jun 2008 16:44:31 +0100 (WEST) Subject: [Netconf] New version of Netconf over TLS and two independent and interoperable implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear all, I updated a new version of "Netconf over TLS" that takes into consideration the comments from WG members regarding the third party authentication. A URL for this version is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-03.txt I take the opportunity to kindly inform you that two independent and interoperable implementations are realized. The first is based on GNUTLS and the second on OpenSSL. A- GNUTLS: GNUTLS 2.3.12 archive should implement everything. Thanks to Simon Josefsson. Here are the compressed sources: http://alpha.gnu.org/gnu/gnutls/gnutls-2.3.12.tar.bz2 ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.3.12.tar.bz2 Here is the Windows binaries: http://josefsson.org/gnutls4win/gnutls-2.3.12.exe http://josefsson.org/gnutls4win/gnutls-2.3.12.zip Documentation is available online at: http://www.gnu.org/software/gnutls/manual/html_node/Example-server-PSK-connection.html http://www.gnu.org/software/gnutls/manual/html_node/Example-client-PSK-connection.html http://www.gnu.org/software/gnutls/manual/html_node/Authentication-using-PSK.html B- OpenSSL: The patch is available at: http://ineovation.fr/netconfovertls/tls_netconf.patch To test it, follow the instructions available at: http://ineovation.fr/netconfovertls/readme.txt Please let me know if you encounter any problems with these two implementations and don't hesitate to suggest any improvement. Best regards, -- Mohamad Badra CNRS - LIMOS Laboratory _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 5 07:49:52 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D674428C25C; Thu, 5 Jun 2008 07:49:52 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2773C28C254 for ; Thu, 5 Jun 2008 07:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfldhU5EKfWP for ; Thu, 5 Jun 2008 07:49:46 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 6FC7828C261 for ; Thu, 5 Jun 2008 07:47:59 -0700 (PDT) Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m55FiUSV749794; Thu, 5 Jun 2008 16:44:31 +0100 Message-ID: <4847FC6A.3040205@isima.fr> Date: Thu, 05 Jun 2008 16:47:06 +0200 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: netconf@ietf.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Thu, 05 Jun 2008 16:44:31 +0100 (WEST) Subject: [Netconf] New version of Netconf over TLS and two independent and interoperable implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear all, I updated a new version of "Netconf over TLS" that takes into consideration the comments from WG members regarding the third party authentication. A URL for this version is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-03.txt I take the opportunity to kindly inform you that two independent and interoperable implementations are realized. The first is based on GNUTLS and the second on OpenSSL. A- GNUTLS: GNUTLS 2.3.12 archive should implement everything. Thanks to Simon Josefsson. Here are the compressed sources: http://alpha.gnu.org/gnu/gnutls/gnutls-2.3.12.tar.bz2 ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.3.12.tar.bz2 Here is the Windows binaries: http://josefsson.org/gnutls4win/gnutls-2.3.12.exe http://josefsson.org/gnutls4win/gnutls-2.3.12.zip Documentation is available online at: http://www.gnu.org/software/gnutls/manual/html_node/Example-server-PSK-connection.html http://www.gnu.org/software/gnutls/manual/html_node/Example-client-PSK-connection.html http://www.gnu.org/software/gnutls/manual/html_node/Authentication-using-PSK.html B- OpenSSL: The patch is available at: http://ineovation.fr/netconfovertls/tls_netconf.patch To test it, follow the instructions available at: http://ineovation.fr/netconfovertls/readme.txt Please let me know if you encounter any problems with these two implementations and don't hesitate to suggest any improvement. Best regards, -- Mohamad Badra CNRS - LIMOS Laboratory _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 5 11:26:09 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C17728C1C6; Thu, 5 Jun 2008 11:26:09 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB1228C197 for ; Thu, 5 Jun 2008 11:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E1kKjXZBVYu for ; Thu, 5 Jun 2008 11:26:06 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id DAC6928C10F for ; Thu, 5 Jun 2008 11:21:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=dt8pZTBBhNhz90y+k+xN8+xO8AMl6+JbLYDE+u5dQKFaAQdiOww3t+fAaLMwYrP5; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.84.214] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1K4K5r-0003C8-IR for netconf@ietf.org; Thu, 05 Jun 2008 14:21:47 -0400 Message-ID: <006f01c8c739$1adfd880$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <48473512.6070306@netconfcentral.com> <000d01c8c6bd$cb60daa0$6801a8c0@oemcomputer> <4847C941.6000401@netconfcentral.com> Date: Thu, 5 Jun 2008 11:22:24 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b335273445e65195a404f4e8a20fa7b8b5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.84.214 Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi - > From: "Andy Bierman" > To: "Randy Presuhn" > Cc: > Sent: Thursday, June 05, 2008 4:08 AM > Subject: Re: [Netconf] Pre-13 Notification (take 2) ... > I prefer to remove this sentence from the draft entirely. > If I am the only one who thinks that blindly following > what SNMP did is a bad idea, then fine. > > I ask newbie security questions like "how come pruning data > is fine for but not for ?" Clearly, any > data that can be retrieved with a can also be transported > as a , yet they generate very different security > concerns within the IESG. ... I'm agnostic on the question. My concern was simply that the proposed edit did not appear to have the desired effect. Regarding the underlying question of "pruning" notification payloads, I think it's a question not just of security policy, but also of what conformance to a notification type means. If any arbitrary piece of a notification payload may be omitted, then the bar for claiming to support a particular notification is rather low. This might be ok, but it should be a conscious decision. Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 5 11:26:09 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C17728C1C6; Thu, 5 Jun 2008 11:26:09 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB1228C197 for ; Thu, 5 Jun 2008 11:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E1kKjXZBVYu for ; Thu, 5 Jun 2008 11:26:06 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id DAC6928C10F for ; Thu, 5 Jun 2008 11:21:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=dt8pZTBBhNhz90y+k+xN8+xO8AMl6+JbLYDE+u5dQKFaAQdiOww3t+fAaLMwYrP5; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.84.214] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1K4K5r-0003C8-IR for netconf@ietf.org; Thu, 05 Jun 2008 14:21:47 -0400 Message-ID: <006f01c8c739$1adfd880$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <48473512.6070306@netconfcentral.com> <000d01c8c6bd$cb60daa0$6801a8c0@oemcomputer> <4847C941.6000401@netconfcentral.com> Date: Thu, 5 Jun 2008 11:22:24 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b335273445e65195a404f4e8a20fa7b8b5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.84.214 Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi - > From: "Andy Bierman" > To: "Randy Presuhn" > Cc: > Sent: Thursday, June 05, 2008 4:08 AM > Subject: Re: [Netconf] Pre-13 Notification (take 2) ... > I prefer to remove this sentence from the draft entirely. > If I am the only one who thinks that blindly following > what SNMP did is a bad idea, then fine. > > I ask newbie security questions like "how come pruning data > is fine for but not for ?" Clearly, any > data that can be retrieved with a can also be transported > as a , yet they generate very different security > concerns within the IESG. ... I'm agnostic on the question. My concern was simply that the proposed edit did not appear to have the desired effect. Regarding the underlying question of "pruning" notification payloads, I think it's a question not just of security policy, but also of what conformance to a notification type means. If any arbitrary piece of a notification payload may be omitted, then the bar for claiming to support a particular notification is rather low. This might be ok, but it should be a conscious decision. Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 5 13:23:58 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 731B53A6A45; Thu, 5 Jun 2008 13:23:58 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 927D83A6A45 for ; Thu, 5 Jun 2008 13:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Jq8ti6Z4t9Z for ; Thu, 5 Jun 2008 13:23:52 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id E06EF3A6B32 for ; Thu, 5 Jun 2008 13:23:49 -0700 (PDT) Received: (qmail 2916 invoked from network); 5 Jun 2008 20:23:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.69 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 5 Jun 2008 20:23:52 -0000 X-YMail-OSG: A4x2Fb0VM1kg3v4WdIl7pxoKaZvP0KEVCm3Zb_XMujvhZvL6OjMmzbgbQNqTCbOLGO2wdbcDgPT2MzJA.s8gkBPS5lrkxImxLBMQWvZ7ZjpQQbXlodxNrcNrrYv8rJ1qZQU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48484B56.30705@netconfcentral.com> Date: Thu, 05 Jun 2008 13:23:50 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Randy Presuhn References: <48473512.6070306@netconfcentral.com> <000d01c8c6bd$cb60daa0$6801a8c0@oemcomputer> <4847C941.6000401@netconfcentral.com> <006f01c8c739$1adfd880$6801a8c0@oemcomputer> In-Reply-To: <006f01c8c739$1adfd880$6801a8c0@oemcomputer> Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Randy Presuhn" >> Cc: >> Sent: Thursday, June 05, 2008 4:08 AM >> Subject: Re: [Netconf] Pre-13 Notification (take 2) > ... >> I prefer to remove this sentence from the draft entirely. >> If I am the only one who thinks that blindly following >> what SNMP did is a bad idea, then fine. >> >> I ask newbie security questions like "how come pruning data >> is fine for but not for ?" Clearly, any >> data that can be retrieved with a can also be transported >> as a , yet they generate very different security >> concerns within the IESG. > ... > > I'm agnostic on the question. My concern was simply that the proposed > edit did not appear to have the desired effect. > I know. I realized a sentence was missing after I sent the original mail: If a user is not authorized to view all elements in the content of the notification, the notification SHOULD NOT be sent to that user. The agent MUST NOT include any content which the user is not authorized to view. > RegaFrom netconf-bounces@ietf.org Thu Jun 5 13:23:58 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 731B53A6A45; Thu, 5 Jun 2008 13:23:58 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 927D83A6A45 for ; Thu, 5 Jun 2008 13:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Jq8ti6Z4t9Z for ; Thu, 5 Jun 2008 13:23:52 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id E06EF3A6B32 for ; Thu, 5 Jun 2008 13:23:49 -0700 (PDT) Received: (qmail 2916 invoked from network); 5 Jun 2008 20:23:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.69 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 5 Jun 2008 20:23:52 -0000 X-YMail-OSG: A4x2Fb0VM1kg3v4WdIl7pxoKaZvP0KEVCm3Zb_XMujvhZvL6OjMmzbgbQNqTCbOLGO2wdbcDgPT2MzJA.s8gkBPS5lrkxImxLBMQWvZ7ZjpQQbXlodxNrcNrrYv8rJ1qZQU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48484B56.30705@netconfcentral.com> Date: Thu, 05 Jun 2008 13:23:50 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Randy Presuhn References: <48473512.6070306@netconfcentral.com> <000d01c8c6bd$cb60daa0$6801a8c0@oemcomputer> <4847C941.6000401@netconfcentral.com> <006f01c8c739$1adfd880$6801a8c0@oemcomputer> In-Reply-To: <006f01c8c739$1adfd880$6801a8c0@oemcomputer> Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Randy Presuhn" >> Cc: >> Sent: Thursday, June 05, 2008 4:08 AM >> Subject: Re: [Netconf] Pre-13 Notification (take 2) > ... >> I prefer to remove this sentence from the draft entirely. >> If I am the only one who thinks that blindly following >> what SNMP did is a bad idea, then fine. >> >> I ask newbie security questions like "how come pruning data >> is fine for but not for ?" Clearly, any >> data that can be retrieved with a can also be transported >> as a , yet they generate very different security >> concerns within the IESG. > ... > > I'm agnostic on the question. My concern was simply that the proposed > edit did not appear to have the desired effect. > I know. I realized a sentence was missing after I sent the original mail: If a user is not authorized to view all elements in the content of the notification, the notification SHOULD NOT be sent to that user. The agent MUST NOT include any content which the user is not authorized to view. rding the underlying question of "pruning" notification payloads, > I think it's a question not just of security policy, but also of what > conformance to a notification type means. If any arbitrary piece of > a notification payload may be omitted, then the bar for claiming to > support a particular notification is rather low. This might be ok, > but it should be a conscious decision. The problem is data-model dependent, not protocol-dependent. That is what Dave and I have been trying to point out. When a proper ACM is created for NETCONF, the WG may in fact decide on some constraints and control knobs, or decide not to ever allow pruning of notification data. I guess I am clueless on security, but I fail to see how a manager application would handle pruned data from a differently than from a . If access control is in effect, and some data is hidden from the user's view, than the application either breaks or copes with the partial data set. I don't see what vs. has to do with it. > > Randy > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf > Regarding the underlying question of "pruning" notification payloads, > I think it's a question not just of security policy, but also of what > conformance to a notification type means. If any arbitrary piece of > a notification payload may be omitted, then the bar for claiming to > support a particular notification is rather low. This might be ok, > but it should be a conscious decision. The problem is data-model dependent, not protocol-dependent. That is what Dave and I have been trying to point out. When a proper ACM is created for NETCONF, the WG may in fact decide on some constraints and control knobs, or decide not to ever allow pruning of notification data. I guess I am clueless on security, but I fail to see how a manager application would handle pruned data from a differently than from a . If access control is in effect, and some data is hidden from the user's view, than the application either breaks or copes with the partial data set. I don't see what vs. has to do with it. > > Randy > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jun 6 03:31:56 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E371A3A6B0E; Fri, 6 Jun 2008 03:31:56 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86043A6AF4 for ; Fri, 6 Jun 2008 03:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF2Fg1lcwXCd for ; Fri, 6 Jun 2008 03:31:52 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 20CC83A6A4A for ; Fri, 6 Jun 2008 03:31:49 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CB99B214DF; Fri, 6 Jun 2008 12:31:56 +0200 (CEST) X-AuditID: c1b4fb3e-ad997bb000004ec0-87-4849121ce58a Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B86C7211C3; Fri, 6 Jun 2008 12:31:56 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jun 2008 12:31:56 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jun 2008 12:31:56 +0200 Message-ID: <4849121C.10202@ericsson.com> Date: Fri, 06 Jun 2008 12:31:56 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Sharon Chisholm , netconf@ietf.org X-OriginalArrivalTime: 06 Jun 2008 10:31:56.0453 (UTC) FILETIME=[8B491550:01C8C7C0] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Notification IANA considerations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, A small comment: In the IANA considerations section it states "This document registers three URIs ..." and then it defines actually 4 URIs not 3. Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jun 6 03:31:56 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E371A3A6B0E; Fri, 6 Jun 2008 03:31:56 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86043A6AF4 for ; Fri, 6 Jun 2008 03:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF2Fg1lcwXCd for ; Fri, 6 Jun 2008 03:31:52 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 20CC83A6A4A for ; Fri, 6 Jun 2008 03:31:49 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CB99B214DF; Fri, 6 Jun 2008 12:31:56 +0200 (CEST) X-AuditID: c1b4fb3e-ad997bb000004ec0-87-4849121ce58a Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B86C7211C3; Fri, 6 Jun 2008 12:31:56 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jun 2008 12:31:56 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jun 2008 12:31:56 +0200 Message-ID: <4849121C.10202@ericsson.com> Date: Fri, 06 Jun 2008 12:31:56 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Sharon Chisholm , netconf@ietf.org X-OriginalArrivalTime: 06 Jun 2008 10:31:56.0453 (UTC) FILETIME=[8B491550:01C8C7C0] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Notification IANA considerations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, A small comment: In the IANA considerations section it states "This document registers three URIs ..." and then it defines actually 4 URIs not 3. Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Jun 7 08:45:55 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 992313A698A; Sat, 7 Jun 2008 08:45:55 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95BEB3A682D for ; Sat, 7 Jun 2008 08:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJxymKcDVr1l for ; Sat, 7 Jun 2008 08:45:46 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 191493A6B12 for ; Sat, 7 Jun 2008 08:45:30 -0700 (PDT) Received: (qmail 65313 invoked from network); 7 Jun 2008 15:45:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.69 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 7 Jun 2008 15:45:31 -0000 X-YMail-OSG: xhupWtoVM1msIOXEp7jlSyeZ0EaYvD58pel3SHBizbQnK82NYWpvJYNA71nHubm.zYpiVYIfMsuj8eVwDyrFmLX26MCO0KrSalmpweWbMg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <484AAD19.1080609@netconfcentral.com> Date: Sat, 07 Jun 2008 08:45:29 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Randy Presuhn References: <48473512.6070306@netconfcentral.com> <000d01c8c6bd$cb60daa0$6801a8c0@oemcomputer> <4847C941.6000401@netconfcentral.com> <006f01c8c739$1adfd880$6801a8c0@oemcomputer> <48484B56.30705@netconfcentral.com> In-Reply-To: <48484B56.30705@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Randy, >... > >> Regarding the underlying question of "pruning" notification payloads, >> I think it's a question not just of security policy, but also of what >> conformance to a notification type means. If any arbitrary piece of >> a notification payload may be omitted, then the bar for claiming to >> support a particular notification is rather low. This might be ok, >> but it should be a conscious decision. > >... I misinterpreted your comment. Conformance levels for data model definitions and operational decisions to restrict data access for better security are two very different issues. Data is not really omitted. Think of the and operations as requests to retrieve the (possibly filtered) subset of the configuration database that the user is authorized to view. IMO, the access control is conceptually applied to the target database before the filters. That means an agent would never return an 'access-denied' error for a in this case -- it would just return an empty data set, but that is how current implementations work. The most important problem with the notification-13 draft is that it contains sloppy normative text that will almost certainly impact future access control standardization efforts. I would rather put aside the notification RFC until a standard access model is done, than to decide now and forever how access control MUST work for notifications alone. This one sentence should be sufficient (to replace the paragraph in question): The agent MUST NOT include any content in a notification which the user is not authorized to view. Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Jun 7 08:45:55 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 992313A698A; Sat, 7 Jun 2008 08:45:55 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95BEB3A682D for ; Sat, 7 Jun 2008 08:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJxymKcDVr1l for ; Sat, 7 Jun 2008 08:45:46 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 191493A6B12 for ; Sat, 7 Jun 2008 08:45:30 -0700 (PDT) Received: (qmail 65313 invoked from network); 7 Jun 2008 15:45:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.129.69 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 7 Jun 2008 15:45:31 -0000 X-YMail-OSG: xhupWtoVM1msIOXEp7jlSyeZ0EaYvD58pel3SHBizbQnK82NYWpvJYNA71nHubm.zYpiVYIfMsuj8eVwDyrFmLX26MCO0KrSalmpweWbMg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <484AAD19.1080609@netconfcentral.com> Date: Sat, 07 Jun 2008 08:45:29 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Randy Presuhn References: <48473512.6070306@netconfcentral.com> <000d01c8c6bd$cb60daa0$6801a8c0@oemcomputer> <4847C941.6000401@netconfcentral.com> <006f01c8c739$1adfd880$6801a8c0@oemcomputer> <48484B56.30705@netconfcentral.com> In-Reply-To: <48484B56.30705@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Randy, >... > >> Regarding the underlying question of "pruning" notification payloads, >> I think it's a question not just of security policy, but also of what >> conformance to a notification type means. If any arbitrary piece of >> a notification payload may be omitted, then the bar for claiming to >> support a particular notification is rather low. This might be ok, >> but it should be a conscious decision. > >... I misinterpreted your comment. Conformance levels for data model definitions and operational decisions to restrict data access for better security are two very different issues. Data is not really omitted. Think of the and operations as requests to retrieve the (possibly filtered) subset of the configuration database that the user is authorized to view. IMO, the access control is conceptually applied to the target database before the filters. That means an agent would never return an 'access-denied' error for a in this case -- it would just return an empty data set, but that is how current implementations work. The most important problem with the notification-13 draft is that it contains sloppy normative text that will almost certainly impact future access control standardization efforts. I would rather put aside the notification RFC until a standard access model is done, than to decide now and forever how access control MUST work for notifications alone. This one sentence should be sufficient (to replace the paragraph in question): The agent MUST NOT include any content in a notification which the user is not authorized to view. Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Jun 8 09:44:21 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA9D3A68B4; Sun, 8 Jun 2008 09:44:21 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 123363A68B4 for ; Sun, 8 Jun 2008 09:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WNu1JXkpkuA for ; Sun, 8 Jun 2008 09:44:19 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 24F913A6813 for ; Sun, 8 Jun 2008 09:44:19 -0700 (PDT) Received: (qmail 47978 invoked from network); 8 Jun 2008 16:44:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.172.122 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 8 Jun 2008 16:44:32 -0000 X-YMail-OSG: HbY.jRQVM1nlJskxf1DHouYrhGKAIeP1l2RNgexy8WTMS_yTbzALMGcVke3DyF4eZymJA1DOUP0YooPRNCv1LIIWq7xsgCbRUts4RxVw0w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <484C0C6C.1020606@netconfcentral.com> Date: Sun, 08 Jun 2008 09:44:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Bert Wijnen - IETF References: In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Bert Wijnen - IETF wrote: > Andy and David, > > Sharon was/is trying to clarify some text in the security > considerations section in order to address comments from > the IESG review. > > I don't think we want to go through a long process of > debating all the option we have for notifications. We do not > have a (satndardized) ACM for NETCONF, and so we do not have > to be explicit as to what exactly happens in all cases, > do we? We have to warn/explain to the user what he needs > to look out for when supporting enabling notifications. > > If you are not happy with the new text, can you then pls > propose your text (as a minimum). Since I'm the one who seems to be holding this up, let me ask if the IESG considered this use case: Notifications should be conceptually divided into a header and a payload section. This was originally built into Sharon's draft, but the WG could not agree on any content for the header except 'eventTime'. IMO, more standard header fields will be needed, and eventually added (e.g. eventType, eventSeverity). One simple 'partial data' use case is the ability for an application to receive at least the headers for the notifications it requested (and is authorized to receive). Remember that this corner-case occurs when a user is authorized to receive the specific notification, but not some data within the conceptual payload sectFrom netconf-bounces@ietf.org Sun Jun 8 09:44:21 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA9D3A68B4; Sun, 8 Jun 2008 09:44:21 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 123363A68B4 for ; Sun, 8 Jun 2008 09:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WNu1JXkpkuA for ; Sun, 8 Jun 2008 09:44:19 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 24F913A6813 for ; Sun, 8 Jun 2008 09:44:19 -0700 (PDT) Received: (qmail 47978 invoked from network); 8 Jun 2008 16:44:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.172.122 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 8 Jun 2008 16:44:32 -0000 X-YMail-OSG: HbY.jRQVM1nlJskxf1DHouYrhGKAIeP1l2RNgexy8WTMS_yTbzALMGcVke3DyF4eZymJA1DOUP0YooPRNCv1LIIWq7xsgCbRUts4RxVw0w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <484C0C6C.1020606@netconfcentral.com> Date: Sun, 08 Jun 2008 09:44:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Bert Wijnen - IETF References: In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Bert Wijnen - IETF wrote: > Andy and David, > > Sharon was/is trying to clarify some text in the security > considerations section in order to address comments from > the IESG review. > > I don't think we want to go through a long process of > debating all the option we have for notifications. We do not > have a (satndardized) ACM for NETCONF, and so we do not have > to be explicit as to what exactly happens in all cases, > do we? We have to warn/explain to the user what he needs > to look out for when supporting enabling notifications. > > If you are not happy with the new text, can you then pls > propose your text (as a minimum). Since I'm the one who seems to be holding this up, let me ask if the IESG considered this use case: Notifications should be conceptually divided into a header and a payload section. This was originally built into Sharon's draft, but the WG could not agree on any content for the header except 'eventTime'. IMO, more standard header fields will be needed, and eventually added (e.g. eventType, eventSeverity). One simple 'partial data' use case is the ability for an application to receive at least the headers for the notifications it requested (and is authorized to receive). Remember that this corner-case occurs when a user is authorized to receive the specific notification, but not some data within the conceptual payloaion. This scenario could easily occur if the notification contained arbitrary config snippets (e.g., configChangeEvent). > > Bert Wijnen Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf d section. This scenario could easily occur if the notification contained arbitrary config snippets (e.g., configChangeEvent). > > Bert Wijnen Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jun 10 06:32:12 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F88E3A6873; Tue, 10 Jun 2008 06:32:12 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB5BC3A682E for ; Tue, 10 Jun 2008 06:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-opE2gMJrXN for ; Tue, 10 Jun 2008 06:32:07 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id B0C9F28C106 for ; Tue, 10 Jun 2008 06:32:06 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA09.westchester.pa.mail.comcast.net with comcast id cAip1Z0090ldTLk590FA00; Tue, 10 Jun 2008 13:32:28 +0000 Received: from Harrington73653 ([222.210.104.239]) by OMTA04.westchester.pa.mail.comcast.net with comcast id cDY81Z00559vUzA3QDYEsa; Tue, 10 Jun 2008 13:32:25 +0000 X-Authority-Analysis: v=1.0 c=1 a=BaajDAp7ME0A:10 a=iNPBq3vamVAA:10 a=Hm0Y8ziSBarSG2PUgcsA:9 a=uR1FGC9JUk8jzZjCKVUA:7 a=t3H-B5Cx9tPo4UusVzhqd4R6MEcA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Andy Bierman'" , "'Bert Wijnen - IETF'" References: <484C0C6C.1020606@netconfcentral.com> Date: Tue, 10 Jun 2008 21:32:07 +0800 Message-ID: <003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjJhwYXPsPP1NIiTUm+r661XcgBDwBcaMHw In-Reply-To: <484C0C6C.1020606@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Monday, June 09, 2008 12:44 AM > To: Bert Wijnen - IETF > Cc: netconf@ietf.org > Subject: Re: [Netconf] Pre-13 Notification (take 2) > > Bert Wijnen - IETF wrote: > > Andy and David, > > > > Sharon was/is trying to clarify some text in the security > > considerations section in order to address comments from > > the IESG review. > > > > I don't think we want to go through a long process of > > debating all the option we have for notifications. We do not > > have a (satndardized) ACM for NETCONF, and so we do not have > > to be explicit as to what exactly happens in all cases, > > do we? We have to warn/explain to the user what he needs > > to look out for when supporting enabling notifications. > > > > If you are not happy with the new text, can you then pls > > propose your text (as a minimum). > > Since I'm the one who seems to be holding this up, I don't think you're the only one holding this up. I am too. The problem is that the loose wording in this document imposes restrictions on future access control models, including using RFC2119 reserved words "informally". It should not do that. We have proposed alternate text that would resolve the problem, but the editor usually insists on rewording the proposed text, and puts the problem back in. I think we finally got the most egregious paragraph fixed, and another paragraph (I think it was introduced in the new revision) now does the same thing. One of the big problems Andy has raised is that what is meant to be non-normative text ends up being normative. Remember the whole debate about RFC3411's title being "An Architecture" rather than "The Architecture" because it was not meant to be normative? Well all subsequent IETF WG work has had the RFC3411 treated as normative; all subsequent approved charters have insisted that the WGs MUST NOT violate the RFC3411 architecture. That took non-normative text and made it normative. Andy and I have experience with non-normative text becoming normative and we want to avoid that happening here. It is not acceptable to argue that "it's just informal and not normative"; we should not be making vague informal statements that could be treated as normative in the future. Another big problem is that consensus is that netconf notifications can carry data from syslog and/or snmp notifications. Without addressing access control models now, and the interaction between netconf/syslog/snmp data models and possibly interactions between the authentication of identities used by the protocols, we cannot possibly understand the implications of saying something like "if the user does not have access to all the data contained in the notification, then the netconf notification will not be sent." The netconf implementation will presumably have no idea what access the user will have to syslog data elements or syslog messages or snmp objects; therefore, if the notification contains syslog or snmp data, it cannot tell whether to send the netconf notification or not. A third problem, as raised by Andy, is that the document should not say that the notification will or will not be sent based on user access to all the content according to some other operation, because the matching alforithm for operations might differ. We have not decided what content must be in a notification or how the access controls will work, and the decision on those points should be made explicitly, not as a side-effect of some sloppy text in the notifications document. We need to make sure the notifications document makes no presumptions about the content of the notifications, or the user's access to that content, as long as user identities, data models and access controls have not been standardized yet. The loose wording in this document imposes restrictions on future models. It should not do that. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jun 10 06:32:12 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F88E3A6873; Tue, 10 Jun 2008 06:32:12 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB5BC3A682E for ; Tue, 10 Jun 2008 06:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-opE2gMJrXN for ; Tue, 10 Jun 2008 06:32:07 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id B0C9F28C106 for ; Tue, 10 Jun 2008 06:32:06 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA09.westchester.pa.mail.comcast.net with comcast id cAip1Z0090ldTLk590FA00; Tue, 10 Jun 2008 13:32:28 +0000 Received: from Harrington73653 ([222.210.104.239]) by OMTA04.westchester.pa.mail.comcast.net with comcast id cDY81Z00559vUzA3QDYEsa; Tue, 10 Jun 2008 13:32:25 +0000 X-Authority-Analysis: v=1.0 c=1 a=BaajDAp7ME0A:10 a=iNPBq3vamVAA:10 a=Hm0Y8ziSBarSG2PUgcsA:9 a=uR1FGC9JUk8jzZjCKVUA:7 a=t3H-B5Cx9tPo4UusVzhqd4R6MEcA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Andy Bierman'" , "'Bert Wijnen - IETF'" References: <484C0C6C.1020606@netconfcentral.com> Date: Tue, 10 Jun 2008 21:32:07 +0800 Message-ID: <003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjJhwYXPsPP1NIiTUm+r661XcgBDwBcaMHw In-Reply-To: <484C0C6C.1020606@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Monday, June 09, 2008 12:44 AM > To: Bert Wijnen - IETF > Cc: netconf@ietf.org > Subject: Re: [Netconf] Pre-13 Notification (take 2) > > Bert Wijnen - IETF wrote: > > Andy and David, > > > > Sharon was/is trying to clarify some text in the security > > considerations section in order to address comments from > > the IESG review. > > > > I don't think we want to go through a long process of > > debating all the option we have for notifications. We do not > > have a (satndardized) ACM for NETCONF, and so we do not have > > to be explicit as to what exactly happens in all cases, > > do we? We have to warn/explain to the user what he needs > > to look out for when supporting enabling notifications. > > > > If you are not happy with the new text, can you then pls > > propose your text (as a minimum). > > Since I'm the one who seems to be holding this up, I don't think you're the only one holding this up. I am too. The problem is that the loose wording in this document imposes restrictions on future access control models, including using RFC2119 reserved words "informally". It should not do that. We have proposed alternate text that would resolve the problem, but the editor usually insists on rewording the proposed text, and puts the problem back in. I think we finally got the most egregious paragraph fixed, and another paragraph (I think it was introduced in the new revision) now does the same thing. One of the big problems Andy has raised is that what is meant to be non-normative text ends up being normative. Remember the whole debate about RFC3411's title being "An Architecture" rather than "The Architecture" because it was not meant to be normative? Well all subsequent IETF WG work has had the RFC3411 treated as normative; all subsequent approved charters have insisted that the WGs MUST NOT violate the RFC3411 architecture. That took non-normative text and made it normative. Andy and I have experience with non-normative text becoming normative and we want to avoid that happening here. It is not acceptable to argue that "it's just informal and not normative"; we should not be making vague informal statements that could be treated as normative in the future. Another big problem is that consensus is that netconf notifications can carry data from syslog and/or snmp notifications. Without addressing access control models now, and the interaction between netconf/syslog/snmp data models and possibly interactions between the authentication of identities used by the protocols, we cannot possibly understand the implications of saying something like "if the user does not have access to all the data contained in the notification, then the netconf notification will not be sent." The netconf implementation will presumably have no idea what access the user will have to syslog data elements or syslog messages or snmp objects; therefore, if the notification contains syslog or snmp data, it cannot tell whether to send the netconf notification or not. A third problem, as raised by Andy, is that the document should not say that the notification will or will not be sent based on user access to all the content according to some other operation, because the matching alforithm for operations might differ. We have not decided what content must be in a notification or how the access controls will work, and the decision on those points should be made explicitly, not as a side-effect of some sloppy text in the notifications document. We need to make sure the notifications document makes no presumptions about the content of the notifications, or the user's access to that content, as long as user identities, data models and access controls have not been standardized yet. The loose wording in this document imposes restrictions on future models. It should not do that. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jun 10 07:00:11 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 144673A68FA; Tue, 10 Jun 2008 07:00:11 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8594E3A687A for ; Tue, 10 Jun 2008 07:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.091 X-Spam-Level: X-Spam-Status: No, score=-6.091 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUN8B+vLV21C for ; Tue, 10 Jun 2008 07:00:08 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 369403A6874 for ; Tue, 10 Jun 2008 07:00:08 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5AE0KM14268; Tue, 10 Jun 2008 14:00:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 10:00:15 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com> In-Reply-To: <003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Choosing Solution for partial authorization (was RE: [Netconf] Pre-13 Notification (take 2)) Thread-Index: AcjJhwYXPsPP1NIiTUm+r661XcgBDwBcaMHwAAHWOTA= References: <484C0C6C.1020606@netconfcentral.com> <003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com> From: "Sharon Chisholm" To: "David Harrington" , "Andy Bierman" , "Bert Wijnen - IETF" Cc: netconf@ietf.org Subject: [Netconf] Choosing Solution for partial authorization (was RE: Pre-13 Notification (take 2)) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi The text we are arguing about at the moment was added a long time ago (May 2007). The goal at the time was to try and drive consistent behaviour in the case where the Notification contained information the user was not allowed to see. The agreement at the time was to just not send anything. I think some good points have been raised, particularly with Andy's analogy to the operation, that question whether the working group made the right decision at the time. So, we have three options here. Please indicate your preference: 1) Leave it ambiguous as to whether any of the Notification message is sent. I.e., delete the sentence "If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user." 2) Clarify that nothing is sent. I.e., keep text the same. 3) Clarify that those portions the user is permitted to see are sent. I.e., replace the above sentence with something along the lines of "Similar to a operation, the user only sees content within a Notification that they are From netconf-bounces@ietf.org Tue Jun 10 07:00:11 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 144673A68FA; Tue, 10 Jun 2008 07:00:11 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8594E3A687A for ; Tue, 10 Jun 2008 07:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.091 X-Spam-Level: X-Spam-Status: No, score=-6.091 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUN8B+vLV21C for ; Tue, 10 Jun 2008 07:00:08 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 369403A6874 for ; Tue, 10 Jun 2008 07:00:08 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5AE0KM14268; Tue, 10 Jun 2008 14:00:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 10:00:15 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com> In-Reply-To: <003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Choosing Solution for partial authorization (was RE: [Netconf] Pre-13 Notification (take 2)) Thread-Index: AcjJhwYXPsPP1NIiTUm+r661XcgBDwBcaMHwAAHWOTA= References: <484C0C6C.1020606@netconfcentral.com> <003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com> From: "Sharon Chisholm" To: "David Harrington" , "Andy Bierman" , "Bert Wijnen - IETF" Cc: netconf@ietf.org Subject: [Netconf] Choosing Solution for partial authorization (was RE: Pre-13 Notification (take 2)) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi The text we are arguing about at the moment was added a long time ago (May 2007). The goal at the time was to try and drive consistent behaviour in the case where the Notification contained information the user was not allowed to see. The agreement at the time was to just not send anything. I think some good points have been raised, particularly with Andy's analogy to the operation, that question whether the working group made the right decision at the time. So, we have three options here. Please indicate your preference: 1) Leave it ambiguous as to whether any of the Notification message is sent. I.e., delete the sentence "If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user." 2) Clarify that nothing is sent. I.e., keep text the same. 3) Clarify that those portions the user is permitted to see are sent. I.e., replace the above sentence with something along the lines of "Similar to a operation, the user only sees content within a Notification that theauthorized to see." Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of David Harrington Sent: Tuesday, June 10, 2008 9:32 AM To: 'Andy Bierman'; 'Bert Wijnen - IETF' Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) Hi, > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Monday, June 09, 2008 12:44 AM > To: Bert Wijnen - IETF > Cc: netconf@ietf.org > Subject: Re: [Netconf] Pre-13 Notification (take 2) > > Bert Wijnen - IETF wrote: > > Andy and David, > > > > Sharon was/is trying to clarify some text in the security > > considerations section in order to address comments from the IESG > > review. > > > > I don't think we want to go through a long process of debating all > > the option we have for notifications. We do not have a > > (satndardized) ACM for NETCONF, and so we do not have to be explicit > > as to what exactly happens in all cases, do we? We have to > > warn/explain to the user what he needs to look out for when > > supporting enabling notifications. > > > > If you are not happy with the new text, can you then pls propose > > your text (as a minimum). > > Since I'm the one who seems to be holding this up, I don't think you're the only one holding this up. I am too. The problem is that the loose wording in this document imposes restrictions on future access control models, including using RFC2119 reserved words "informally". It should not do that. We have proposed alternate text that would resolve the problem, but the editor usually insists on rewording the proposed text, and puts the problem back in. I think we finally got the most egregious paragraph fixed, and another paragraph (I think it was introduced in the new revision) now does the same thing. One of the big problems Andy has raised is that what is meant to be non-normative text ends up being normative. Remember the whole debate about RFC3411's title being "An Architecture" rather than "The Architecture" because it was not meant to be normative? Well all subsequent IETF WG work has had the RFC3411 treated as normative; all subsequent approved charters have insisted that the WGs MUST NOT violate the RFC3411 architecture. That took non-normative text and made it normative. Andy and I have experience with non-normative text becoming normative and we want to avoid that happening here. It is not acceptable to argue that "it's just informal and not normative"; we should not be making vague informal statements that could be treated as normative in the future. Another big problem is that consensus is that netconf notifications can carry data from syslog and/or snmp notifications. Without addressing access control models now, and the interaction between netconf/syslog/snmp data models and possibly interactions between the authentication of identities used by the protocols, we cannot possibly understand the implications of saying something like "if the user does not have access to all the data contained in the notification, then the netconf notification will not be sent." The netconf implementation will presumably have no idea what access the user will have to syslog data elements or syslog messages or snmp objects; therefore, if the notification contains syslog or snmp data, it cannot tell whether to send the netconf notification or not. A third problem, as raised by Andy, is that the document should not say that the notification will or will not be sent based on user access to all the content according to some other operation, because the matching alforithm for operations might differ. We have not decided what content must be in a notification or how the access controls will work, and the decision on those points should be made explicitly, not as a side-effect of some sloppy text in the notifications document. We need to make sure the notifications document makes no presumptions about the content of the notifications, or the user's access to that content, as long as user identities, data models and access controls have not been standardized yet. The loose wording in this document imposes restrictions on future models. It should not do that. _______________________________________________ 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 y are authorized to see." Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of David Harrington Sent: Tuesday, June 10, 2008 9:32 AM To: 'Andy Bierman'; 'Bert Wijnen - IETF' Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) Hi, > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Monday, June 09, 2008 12:44 AM > To: Bert Wijnen - IETF > Cc: netconf@ietf.org > Subject: Re: [Netconf] Pre-13 Notification (take 2) > > Bert Wijnen - IETF wrote: > > Andy and David, > > > > Sharon was/is trying to clarify some text in the security > > considerations section in order to address comments from the IESG > > review. > > > > I don't think we want to go through a long process of debating all > > the option we have for notifications. We do not have a > > (satndardized) ACM for NETCONF, and so we do not have to be explicit > > as to what exactly happens in all cases, do we? We have to > > warn/explain to the user what he needs to look out for when > > supporting enabling notifications. > > > > If you are not happy with the new text, can you then pls propose > > your text (as a minimum). > > Since I'm the one who seems to be holding this up, I don't think you're the only one holding this up. I am too. The problem is that the loose wording in this document imposes restrictions on future access control models, including using RFC2119 reserved words "informally". It should not do that. We have proposed alternate text that would resolve the problem, but the editor usually insists on rewording the proposed text, and puts the problem back in. I think we finally got the most egregious paragraph fixed, and another paragraph (I think it was introduced in the new revision) now does the same thing. One of the big problems Andy has raised is that what is meant to be non-normative text ends up being normative. Remember the whole debate about RFC3411's title being "An Architecture" rather than "The Architecture" because it was not meant to be normative? Well all subsequent IETF WG work has had the RFC3411 treated as normative; all subsequent approved charters have insisted that the WGs MUST NOT violate the RFC3411 architecture. That took non-normative text and made it normative. Andy and I have experience with non-normative text becoming normative and we want to avoid that happening here. It is not acceptable to argue that "it's just informal and not normative"; we should not be making vague informal statements that could be treated as normative in the future. Another big problem is that consensus is that netconf notifications can carry data from syslog and/or snmp notifications. Without addressing access control models now, and the interaction between netconf/syslog/snmp data models and possibly interactions between the authentication of identities used by the protocols, we cannot possibly understand the implications of saying something like "if the user does not have access to all the data contained in the notification, then the netconf notification will not be sent." The netconf implementation will presumably have no idea what access the user will have to syslog data elements or syslog messages or snmp objects; therefore, if the notification contains syslog or snmp data, it cannot tell whether to send the netconf notification or not. A third problem, as raised by Andy, is that the document should not say that the notification will or will not be sent based on user access to all the content according to some other operation, because the matching alforithm for operations might differ. We have not decided what content must be in a notification or how the access controls will work, and the decision on those points should be made explicitly, not as a side-effect of some sloppy text in the notifications document. We need to make sure the notifications document makes no presumptions about the content of the notifications, or the user's access to that content, as long as user identities, data models and access controls have not been standardized yet. The loose wording in this document imposes restrictions on future models. It should not do that. _______________________________________________ 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 netconf-bounces@ietf.org Tue Jun 10 07:21:00 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7A23A687A; Tue, 10 Jun 2008 07:21:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E3103A687A for ; Tue, 10 Jun 2008 07:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.26 X-Spam-Level: X-Spam-Status: No, score=-6.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHT9hOAMvewF for ; Tue, 10 Jun 2008 07:20:54 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 53D7D3A6874 for ; Tue, 10 Jun 2008 07:20:54 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5AEL7M17661; Tue, 10 Jun 2008 14:21:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 10:21:05 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B414F90EBD@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Choosing Solution for partial authorization (was RE: Pre-13 Notification (take 2)) Thread-Index: AcjJhwYXPsPP1NIiTUm+r661XcgBDwBcaMHwAAHWOTAAAUR0AA== References: <484C0C6C.1020606@netconfcentral.com> <003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: "Sharon Chisholm" , "David Harrington" , "Andy Bierman" , "Bert Wijnen - IETF" Cc: netconf@ietf.org Subject: Re: [Netconf] Choosing Solution for partial authorization (was RE: Pre-13 Notification (take 2)) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi For option 3, a slight modification to some text suggested by Andy (we don't have agents ;-)) would work nicely The NETCONF server MUST NOT include any content in a notification which the user is not authorized to view. Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Chisholm, Sharon (CAR:ZZ00) Sent: Tuesday, June 10, 2008 10:00 AM To: David Harrington; Andy Bierman; Bert Wijnen - IETF Cc: netconf@ietf.org Subject: [Netconf] Choosing Solution for partial authorization (was RE: Pre-13 Notification (take 2)) Hi The text we are arguing about at the moment was added a long time ago (May 2007). The goal at the time was to try and drive consistent behaviour in the case where the Notification contained information the user was not allowed to see. The agreement at the time was to just not send anything. I think some good points have been raised, particularly with Andy's analogy to the operation, that question whether the working group made the right decision at the time. So, we have three options here. Please indicate your preference: 1) Leave it ambiguous as to whether any of the Notification message is sent. I.e., delete the sentence "If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user." 2) Clarify that nothing is sent. I.e., keep text the same. 3) Clarify that those portions the user is permitted to see are sent. I.e., replace the above sentence with something along the lines of "Similar to a operation, the user only sees content within a Notification that they are authorized to see." Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of David Harrington Sent: Tuesday, June 10, 2008 9:32 AM To: 'Andy Bierman'; 'Bert Wijnen - IETF' Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) Hi, > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Monday, June 09, 2008 12:44 AM > To: Bert Wijnen - IETF > Cc: netconf@ietf.org > Subject: Re: [Netconf] Pre-13 Notification (take 2) > > Bert Wijnen - IETF wrote: > > Andy and David, > > > > Sharon was/is trying to clarify some text in the security > > considerations section in order to address comments from the IESG > > review. > > > > I don't think we want to go through a long process of debating all > > the option we have for notifications. We do not have a > > (satndardized) ACM for NETCONF, and so we do not have to be explicit > > as to what exactly happens in all cases, do we? We have to > > warn/explain to the user what he needs to look out for when > > supporting enabling notifications. > > > > If you are not happy with the new text, can you then pls propose > > your text (as a minimum). > > Since I'm the one who seems to be holding this up, I don't think you're the only one holding this up. I am too. The problem is that the loose wording in this document imposes restrictions on future access control models, including using RFC2119 reserved words "informally". It should not do that. We have proposed alternate text that would resolve the problem, but the editor usually insists on rewording the proposed text, and puts the problem back in. I think we finally got the most egregious paragraph fixed, and another paragraph (I think it was introduced in the new revision) now does the same thing. One of the big problems Andy has raised is that what is meant to be non-normative text ends up being normative. Remember the whole debate about RFC3411's title being "An Architecture" rather than "The Architecture" because it was not meant to be normative? Well all subsequent IETF WG work has had the RFC3411 treated as normative; all subsequent approved charters have insisted that the WGs MUST NOT violate the RFC3411 architecture. That took non-normative text and made it normative. Andy and I have experience with non-normative text becoming normative and we want to avoid that happening here. It is not acceptable to argue that "it's just informal and not normative"; we should not be making vague informal statements that could be treated as normative in the future. Another big problem is that consensus is that netconf notifications can carry data from syslog and/or snmp notifications. Without addressing access control models now, and the interaction between netconf/syslog/snmp data models and possibly interactions between the authentication of identities used by the protocols, we cannot possibly understand the implications of saying something like "if the user does not have access to all the data contained in the notification, then the netconf notification will not be sent." The netconf implementation will presumably have no idea what access the user will have to syslog data elements or syslog messages or snmp objects; therefore, if the notification contains syslog or snmp data, it cannot tell whether to send the netconf notification or not. A third problem, as raised by Andy, is that the document should not say that the notification will or will not be sent based on user access to all the content according to some other operation, because the matching alforithm for operations might differ. We have not decided what content must be in a notification or how the access controls will work, and the decision on those points should be made explicitly, not as a side-effect of some sloppy text in the notifications document. We need to make sure the notifications document makes no presumptions about the content of the notifications, or the user's access to that content, as long as user identities, data models and access controls have not been standardized yet. The loose wording in this document imposes restrictions on future models. It should not do that. _______________________________________________ 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 netconf-bounces@ietf.org Tue Jun 10 07:21:00 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7A23A687A; Tue, 10 Jun 2008 07:21:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E3103A687A for ; Tue, 10 Jun 2008 07:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.26 X-Spam-Level: X-Spam-Status: No, score=-6.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHT9hOAMvewF for ; Tue, 10 Jun 2008 07:20:54 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 53D7D3A6874 for ; Tue, 10 Jun 2008 07:20:54 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5AEL7M17661; Tue, 10 Jun 2008 14:21:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 10:21:05 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B414F90EBD@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Choosing Solution for partial authorization (was RE: Pre-13 Notification (take 2)) Thread-Index: AcjJhwYXPsPP1NIiTUm+r661XcgBDwBcaMHwAAHWOTAAAUR0AA== References: <484C0C6C.1020606@netconfcentral.com> <003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: "Sharon Chisholm" , "David Harrington" , "Andy Bierman" , "Bert Wijnen - IETF" Cc: netconf@ietf.org Subject: Re: [Netconf] Choosing Solution for partial authorization (was RE: Pre-13 Notification (take 2)) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi For option 3, a slight modification to some text suggested by Andy (we don't have agents ;-)) would work nicely The NETCONF server MUST NOT include any content in a notification which the user is not authorized to view. Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Chisholm, Sharon (CAR:ZZ00) Sent: Tuesday, June 10, 2008 10:00 AM To: David Harrington; Andy Bierman; Bert Wijnen - IETF Cc: netconf@ietf.org Subject: [Netconf] Choosing Solution for partial authorization (was RE: Pre-13 Notification (take 2)) Hi The text we are arguing about at the moment was added a long time ago (May 2007). The goal at the time was to try and drive consistent behaviour in the case where the Notification contained information the user was not allowed to see. The agreement at the time was to just not send anything. I think some good points have been raised, particularly with Andy's analogy to the operation, that question whether the working group made the right decision at the time. So, we have three options here. Please indicate your preference: 1) Leave it ambiguous as to whether any of the Notification message is sent. I.e., delete the sentence "If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user." 2) Clarify that nothing is sent. I.e., keep text the same. 3) Clarify that those portions the user is permitted to see are sent. I.e., replace the above sentence with something along the lines of "Similar to a operation, the user only sees content within a Notification that they are authorized to see." Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of David Harrington Sent: Tuesday, June 10, 2008 9:32 AM To: 'Andy Bierman'; 'Bert Wijnen - IETF' Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) Hi, > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Monday, June 09, 2008 12:44 AM > To: Bert Wijnen - IETF > Cc: netconf@ietf.org > Subject: Re: [Netconf] Pre-13 Notification (take 2) > > Bert Wijnen - IETF wrote: > > Andy and David, > > > > Sharon was/is trying to clarify some text in the security > > considerations section in order to address comments from the IESG > > review. > > > > I don't think we want to go through a long process of debating all > > the option we have for notifications. We do not have a > > (satndardized) ACM for NETCONF, and so we do not have to be explicit > > as to what exactly happens in all cases, do we? We have to > > warn/explain to the user what he needs to look out for when > > supporting enabling notifications. > > > > If you are not happy with the new text, can you then pls propose > > your text (as a minimum). > > Since I'm the one who seems to be holding this up, I don't think you're the only one holding this up. I am too. The problem is that the loose wording in this document imposes restrictions on future access control models, including using RFC2119 reserved words "informally". It should not do that. We have proposed alternate text that would resolve the problem, but the editor usually insists on rewording the proposed text, and puts the problem back in. I think we finally got the most egregious paragraph fixed, and another paragraph (I think it was introduced in the new revision) now does the same thing. One of the big problems Andy has raised is that what is meant to be non-normative text ends up being normative. Remember the whole debate about RFC3411's title being "An Architecture" rather than "The Architecture" because it was not meant to be normative? Well all subsequent IETF WG work has had the RFC3411 treated as normative; all subsequent approved charters have insisted that the WGs MUST NOT violate the RFC3411 architecture. That took non-normative text and made it normative. Andy and I have experience with non-normative text becoming normative and we want to avoid that happening here. It is not acceptable to argue that "it's just informal and not normative"; we should not be making vague informal statements that could be treated as normative in the future. Another big problem is that consensus is that netconf notifications can carry data from syslog and/or snmp notifications. Without addressing access control models now, and the interaction between netconf/syslog/snmp data models and possibly interactions between the authentication of identities used by the protocols, we cannot possibly understand the implications of saying something like "if the user does not have access to all the data contained in the notification, then the netconf notification will not be sent." The netconf implementation will presumably have no idea what access the user will have to syslog data elements or syslog messages or snmp objects; therefore, if the notification contains syslog or snmp data, it cannot tell whether to send the netconf notification or not. A third problem, as raised by Andy, is that the document should not say that the notification will or will not be sent based on user access to all the content according to some other operation, because the matching alforithm for operations might differ. We have not decided what content must be in a notification or how the access controls will work, and the decision on those points should be made explicitly, not as a side-effect of some sloppy text in the notifications document. We need to make sure the notifications document makes no presumptions about the content of the notifications, or the user's access to that content, as long as user identities, data models and access controls have not been standardized yet. The loose wording in this document imposes restrictions on future models. It should not do that. _______________________________________________ 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 netconf-bounces@ietf.org Tue Jun 10 07:23:42 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8873C3A68FF; Tue, 10 Jun 2008 07:23:42 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7C683A687A for ; Tue, 10 Jun 2008 07:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hz8N9+zGEtUm for ; Tue, 10 Jun 2008 07:23:39 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 9AE6C3A6874 for ; Tue, 10 Jun 2008 07:23:39 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 8A8671B80C5; Tue, 10 Jun 2008 16:24:00 +0200 (CEST) Date: Tue, 10 Jun 2008 16:24:00 +0200 (CEST) Message-Id: <20080610.162400.257616676.mbj@tail-f.com> To: schishol@nortel.com From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B414F90EBD@zcarhxm2.corp.nortel.com> References: <003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B414F90EBD@zcarhxm2.corp.nortel.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Choosing Solution for partial authorization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, "Sharon Chisholm" wrote: > For option 3, a slight modification to some text suggested by Andy (we > don't have agents ;-)) would work nicely > > The NETCONF server MUST NOT include any content in a notification > which the user is not authorized to view. I prefer this one. It leaves the decision to drop or prune the notification to the future authorization discussions. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jun 10 07:23:42 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8873C3A68FF; Tue, 10 Jun 2008 07:23:42 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7C683A687A for ; Tue, 10 Jun 2008 07:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hz8N9+zGEtUm for ; Tue, 10 Jun 2008 07:23:39 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 9AE6C3A6874 for ; Tue, 10 Jun 2008 07:23:39 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 8A8671B80C5; Tue, 10 Jun 2008 16:24:00 +0200 (CEST) Date: Tue, 10 Jun 2008 16:24:00 +0200 (CEST) Message-Id: <20080610.162400.257616676.mbj@tail-f.com> To: schishol@nortel.com From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B414F90EBD@zcarhxm2.corp.nortel.com> References: <003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B414F90EBD@zcarhxm2.corp.nortel.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Choosing Solution for partial authorization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, "Sharon Chisholm" wrote: > For option 3, a slight modification to some text suggested by Andy (we > don't have agents ;-)) would work nicely > > The NETCONF server MUST NOT include any content in a notification > which the user is not authorized to view. I prefer this one. It leaves the decision to drop or prune the notification to the future authorization discussions. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jun 10 10:17:12 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8343A6874; Tue, 10 Jun 2008 10:17:12 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF523A6874 for ; Tue, 10 Jun 2008 10:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItceqqgHJby0 for ; Tue, 10 Jun 2008 10:17:10 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 78B043A67E2 for ; Tue, 10 Jun 2008 10:17:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,618,1204531200"; d="scan'208";a="40095340" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 10 Jun 2008 10:17:33 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m5AHHXFg023065; Tue, 10 Jun 2008 10:17:33 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5AHHWfK001681; Tue, 10 Jun 2008 17:17:33 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 10:17:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 10:17:07 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB05D81CA9@xmb-sjc-236.amer.cisco.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Choosing Solution for partial authorization (was RE:Pre-13 Notification (take 2)) Thread-Index: AcjJhwYXPsPP1NIiTUm+r661XcgBDwBcaMHwAAHWOTAABvhuAA== References: <484C0C6C.1020606@netconfcentral.com><003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com> From: "Alexander Clemm (alex)" To: "Sharon Chisholm" , "David Harrington" , "Andy Bierman" , "Bert Wijnen - IETF" X-OriginalArrivalTime: 10 Jun 2008 17:17:08.0397 (UTC) FILETIME=[CFFC55D0:01C8CB1D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6686; t=1213118253; x=1213982253; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alex@cisco.com; z=From:=20=22Alexander=20Clemm=20(alex)=22=20 |Subject:=20RE=3A=20[Netconf]=20Choosing=20Solution=20for=2 0partial=20authorization=20(was=20RE=3APre-13=20Notification =20(take=202)) |Sender:=20; bh=sQjPXusvvQEdJtyTLbDVM35eul5nbRAj0K+Q9mbhxzI=; b=bQRxOH/CSUN+YP0PAzeMFmlNnNH1yqteENtZC9B0uFUz1BDhN3eb9o5tBo XF8H230l6ryLRCtthjvnzK3HldVkEIBycK5RWAb7oZeaCurJDNPTaiWxvYAN Pi76voeWws; Authentication-Results: sj-dkim-4; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: netconf@ietf.org Subject: Re: [Netconf] Choosing Solution for partial authorization (was RE:Pre-13 Notification (take 2)) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Shouldn't there be a 4th option, to indicate whether users are authorized to view/receive the notification (as opposed to specifying it indirectly)? I can see the appeal of 2 and 3, but both are somewhat unsatisfactory. 2 will lead to some unintended and difficult to explain side effects from the perspective of end users, who may be unaware of the fact that a conflict exists with regards to one parameter with regards to a particular message. Similarly, option 3 appears to lead to unexpected "heterogeneity" regarding the same type of message. --- Alex -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Sharon Chisholm Sent: Tuesday, June 10, 2008 7:00 AM To: David Harrington; Andy Bierman; Bert Wijnen - IETF Cc: netconf@ietf.org Subject: [Netconf] Choosing Solution for partial authorization (was RE:Pre-13 Notification (take 2)) Hi The text we are arguing about at the moment was added a long time ago (May 2007). The goal at the time was to try and drive consistent behaviour in the case where the Notification contained information the user was not allowed to see. The agreement at the time was to just not send anything. I think some good points have been raised, particularly with Andy's analogy to the operation, that question whether the working group made the right decision at the time. So, we have three options here. Please indicate your preference: 1) Leave it ambiguous as to whether any of the Notification message is sent. I.e., delete the sentence "If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user." 2) Clarify that nothing is sent. I.e., keep text the same. 3) Clarify that those portions the user is permitted to see are sent. I.e., replace the above sentence with something along the lines of "Similar to a operation, the user only sees content within a Notification that they are authorized to see." Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of David Harrington Sent: Tuesday, June 10, 2008 9:32 AM To: 'Andy Bierman'; 'Bert Wijnen - IETF' Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) Hi, > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Monday, June 09, 2008 12:44 AM > To: Bert Wijnen - IETF > Cc: netconf@ietf.org > Subject: Re: [Netconf] Pre-13 Notification (take 2) > > Bert Wijnen - IETF wrote: > > Andy and David, > > > > Sharon was/is trying to clarify some text in the security > > considerations section in order to address comments from the IESG > > review. > > > > I don't think we want to go through a long process of debating all > > the option we have for notifications. We do not have a > > (satndardized) ACM for NETCONF, and so we do not have to be explicit > > as to what exactly happens in all cases, do we? We have to > > warn/explain to the user what he needs to look out for when > > supporting enabling notifications. > > > > If you are not happy with the new text, can you then pls propose > > your text (as a minimum). > > Since I'm the one who seems to be holding this up, I don't think you're the only one holding this up. I am too. The problem is that the loose wording in this document imposes restrictions on future access control models, including using RFC2119 reserved words "informally". It should not do that. We have proposed alternate text that would resolve the problem, but the editor usually insists on rewording the proposed text, and puts the problem back in. I think we finally got the most egregious paragraph fixed, and another paragraph (I think it was introduced in the new revision) now does the same thing. One of the big problems Andy has raised is that what is meant to be non-normative text ends up being normative. Remember the whole debate about RFC3411's title being "An Architecture" rather than "The Architecture" because it was not meant to be normative? Well all subsequent IETF WG work has had the RFC3411 treated as normative; all subsequent approved charters have insisted that the WGs MUST NOT violate the RFC3411 architecture. That took non-normative text and made it normative. Andy and I have experience with non-normative text becoming normative and we want to avoid that happening here. It is not acceptable to argue that "it's just informal and not normative"; we should not be making vague informal statements that could be treated as normative in the future. Another big problem is that consensus is that netconf notifications can carry data from syslog and/or snmp notifications. Without addressing access control models now, and the interaction between netconf/syslog/snmp data models and possibly interactions between the authentication of identities used by the protocols, we cannot possibly understand the implications of saying something like "if the user does not have access to all the data contained in the notification, then the netconf notification will not be sent." The netconf implementation will presumably have no idea what access the user will have to syslog data elements or syslog messages or snmp objects; therefore, if the notification contains syslog or snmp data, it cannot tell whether to send the netconf notification or not. A third problem, as raised by Andy, is that the document should not say that the notification will or will not be sent based on user access to all the content according to some other operation, because the matching alforithm for operations might differ. We have not decided what content must be in a notification or how the access controls will work, and the decision on those points should be made explicitly, not as a side-effect of some sloppy text in the notifications document. We need to make sure the notifications document makes no presumptions about the content of the notifications, or the user's access to that content, as long as user identities, data models and access controls have not been standardized yet. The loose wording in this document imposes restrictions on future models. It should not do that. _______________________________________________ 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 netconf-bounces@ietf.org Tue Jun 10 10:17:12 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8343A6874; Tue, 10 Jun 2008 10:17:12 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF523A6874 for ; Tue, 10 Jun 2008 10:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItceqqgHJby0 for ; Tue, 10 Jun 2008 10:17:10 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 78B043A67E2 for ; Tue, 10 Jun 2008 10:17:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,618,1204531200"; d="scan'208";a="40095340" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 10 Jun 2008 10:17:33 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m5AHHXFg023065; Tue, 10 Jun 2008 10:17:33 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5AHHWfK001681; Tue, 10 Jun 2008 17:17:33 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 10:17:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 10:17:07 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB05D81CA9@xmb-sjc-236.amer.cisco.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Choosing Solution for partial authorization (was RE:Pre-13 Notification (take 2)) Thread-Index: AcjJhwYXPsPP1NIiTUm+r661XcgBDwBcaMHwAAHWOTAABvhuAA== References: <484C0C6C.1020606@netconfcentral.com><003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com> From: "Alexander Clemm (alex)" To: "Sharon Chisholm" , "David Harrington" , "Andy Bierman" , "Bert Wijnen - IETF" X-OriginalArrivalTime: 10 Jun 2008 17:17:08.0397 (UTC) FILETIME=[CFFC55D0:01C8CB1D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6686; t=1213118253; x=1213982253; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alex@cisco.com; z=From:=20=22Alexander=20Clemm=20(alex)=22=20 |Subject:=20RE=3A=20[Netconf]=20Choosing=20Solution=20for=2 0partial=20authorization=20(was=20RE=3APre-13=20Notification =20(take=202)) |Sender:=20; bh=sQjPXusvvQEdJtyTLbDVM35eul5nbRAj0K+Q9mbhxzI=; b=bQRxOH/CSUN+YP0PAzeMFmlNnNH1yqteENtZC9B0uFUz1BDhN3eb9o5tBo XF8H230l6ryLRCtthjvnzK3HldVkEIBycK5RWAb7oZeaCurJDNPTaiWxvYAN Pi76voeWws; Authentication-Results: sj-dkim-4; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: netconf@ietf.org Subject: Re: [Netconf] Choosing Solution for partial authorization (was RE:Pre-13 Notification (take 2)) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Shouldn't there be a 4th option, to indicate whether users are authorized to view/receive the notification (as opposed to specifying it indirectly)? I can see the appeal of 2 and 3, but both are somewhat unsatisfactory. 2 will lead to some unintended and difficult to explain side effects from the perspective of end users, who may be unaware of the fact that a conflict exists with regards to one parameter with regards to a particular message. Similarly, option 3 appears to lead to unexpected "heterogeneity" regarding the same type of message. --- Alex -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Sharon Chisholm Sent: Tuesday, June 10, 2008 7:00 AM To: David Harrington; Andy Bierman; Bert Wijnen - IETF Cc: netconf@ietf.org Subject: [Netconf] Choosing Solution for partial authorization (was RE:Pre-13 Notification (take 2)) Hi The text we are arguing about at the moment was added a long time ago (May 2007). The goal at the time was to try and drive consistent behaviour in the case where the Notification contained information the user was not allowed to see. The agreement at the time was to just not send anything. I think some good points have been raised, particularly with Andy's analogy to the operation, that question whether the working group made the right decision at the time. So, we have three options here. Please indicate your preference: 1) Leave it ambiguous as to whether any of the Notification message is sent. I.e., delete the sentence "If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user." 2) Clarify that nothing is sent. I.e., keep text the same. 3) Clarify that those portions the user is permitted to see are sent. I.e., replace the above sentence with something along the lines of "Similar to a operation, the user only sees content within a Notification that they are authorized to see." Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of David Harrington Sent: Tuesday, June 10, 2008 9:32 AM To: 'Andy Bierman'; 'Bert Wijnen - IETF' Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) Hi, > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Monday, June 09, 2008 12:44 AM > To: Bert Wijnen - IETF > Cc: netconf@ietf.org > Subject: Re: [Netconf] Pre-13 Notification (take 2) > > Bert Wijnen - IETF wrote: > > Andy and David, > > > > Sharon was/is trying to clarify some text in the security > > considerations section in order to address comments from the IESG > > review. > > > > I don't think we want to go through a long process of debating all > > the option we have for notifications. We do not have a > > (satndardized) ACM for NETCONF, and so we do not have to be explicit > > as to what exactly happens in all cases, do we? We have to > > warn/explain to the user what he needs to look out for when > > supporting enabling notifications. > > > > If you are not happy with the new text, can you then pls propose > > your text (as a minimum). > > Since I'm the one who seems to be holding this up, I don't think you're the only one holding this up. I am too. The problem is that the loose wording in this document imposes restrictions on future access control models, including using RFC2119 reserved words "informally". It should not do that. We have proposed alternate text that would resolve the problem, but the editor usually insists on rewording the proposed text, and puts the problem back in. I think we finally got the most egregious paragraph fixed, and another paragraph (I think it was introduced in the new revision) now does the same thing. One of the big problems Andy has raised is that what is meant to be non-normative text ends up being normative. Remember the whole debate about RFC3411's title being "An Architecture" rather than "The Architecture" because it was not meant to be normative? Well all subsequent IETF WG work has had the RFC3411 treated as normative; all subsequent approved charters have insisted that the WGs MUST NOT violate the RFC3411 architecture. That took non-normative text and made it normative. Andy and I have experience with non-normative text becoming normative and we want to avoid that happening here. It is not acceptable to argue that "it's just informal and not normative"; we should not be making vague informal statements that could be treated as normative in the future. Another big problem is that consensus is that netconf notifications can carry data from syslog and/or snmp notifications. Without addressing access control models now, and the interaction between netconf/syslog/snmp data models and possibly interactions between the authentication of identities used by the protocols, we cannot possibly understand the implications of saying something like "if the user does not have access to all the data contained in the notification, then the netconf notification will not be sent." The netconf implementation will presumably have no idea what access the user will have to syslog data elements or syslog messages or snmp objects; therefore, if the notification contains syslog or snmp data, it cannot tell whether to send the netconf notification or not. A third problem, as raised by Andy, is that the document should not say that the notification will or will not be sent based on user access to all the content according to some other operation, because the matching alforithm for operations might differ. We have not decided what content must be in a notification or how the access controls will work, and the decision on those points should be made explicitly, not as a side-effect of some sloppy text in the notifications document. We need to make sure the notifications document makes no presumptions about the content of the notifications, or the user's access to that content, as long as user identities, data models and access controls have not been standardized yet. The loose wording in this document imposes restrictions on future models. It should not do that. _______________________________________________ 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 netconf-bounces@ietf.org Tue Jun 10 12:23:37 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672373A6AA7; Tue, 10 Jun 2008 12:23:37 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C63428C0F8 for ; Tue, 10 Jun 2008 12:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.345 X-Spam-Level: X-Spam-Status: No, score=-6.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UO2B090jNJgD for ; Tue, 10 Jun 2008 12:23:29 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 282293A6AEE for ; Tue, 10 Jun 2008 12:23:06 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5AJNF514020; Tue, 10 Jun 2008 19:23:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 15:23:07 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B414F917E9@zcarhxm2.corp.nortel.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB05D81CA9@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Choosing Solution for partial authorization (was RE:Pre-13 Notification (take 2)) Thread-Index: AcjJhwYXPsPP1NIiTUm+r661XcgBDwBcaMHwAAHWOTAABvhuAAAEuBOA References: <484C0C6C.1020606@netconfcentral.com><003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com> <85B2F271FDF6B949B3672BA5A7BB62FB05D81CA9@xmb-sjc-236.amer.cisco.com> From: "Sharon Chisholm" To: "Alexander Clemm (alex)" , "David Harrington" , "Andy Bierman" , "Bert Wijnen - IETF" Cc: netconf@ietf.org Subject: Re: [Netconf] Choosing Solution for partial authorization (was RE:Pre-13 Notification (take 2)) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Let me see if I understand what you are saying. You are saying that option 3 is still ambiguous (which I think I agree with after Martin's comment) so you are looking for a fourth option where either 4a. While defining the notification it is captured whether or not Notifications get sent for partial authorization 4b. It is left strictly to the authorization policy whether partially authorized Notifications get sent. If I understand these options, I think I still prefer some form of 3. 3a. The Andy text I indicated below 3b. A stricter version that indicates that the Notification is still sent without the non-authorized information. Sharon -----Original Message----- From: Alexander Clemm (alex) [mailto:alex@cisco.com] Sent: Tuesday, June 10, 2008 1:17 PM To: Chisholm, Sharon (CAR:ZZ00); David Harrington; Andy Bierman; Bert Wijnen - IETF Cc: netconf@ietf.org Subject: RE: [Netconf] Choosing Solution for partial authorization (was RE:Pre-13 Notification (take 2)) Shouldn't there be a 4th option, to indicate whether users are authorized to view/receive the notification (as opposed to specifying it indirectly)? I can see the appeal of 2 and 3, but both are somewhat unsatisfactory. 2 will lead to some unintended and difficult to explain side effects from the perspective of end users, who may be unaware of the fact that a conflict exists with regards to one parameter with regards to a particular message. Similarly, option 3 appears to lead to unexpected "heterogeneity" regarding the same type of message. --- Alex -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Sharon Chisholm Sent: Tuesday, June 10, 2008 7:00 AM To: David Harrington; Andy Bierman; Bert Wijnen - IETF Cc: netconf@ietf.org Subject: [Netconf] Choosing Solution for partial authorization (was RE:Pre-13 Notification (take 2)) Hi The text we are arguing about at the moment was added a long time ago (May 2007). The goal at the time was to try and drive consistent behaviour in the case where the Notification contained information the user was not allowed to see. The agreement at the time was to just not send anything. I think some good points have been raised, particularly with Andy's analogy to the operation, that question whether the working group made the right decision at the time. So, we have three options here. Please indicate your preference: 1) Leave it ambiguous as to whether any of the Notification message is sent. I.e., delete the sentence "If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user." 2) Clarify that nothing is sent. I.e., keep text the same. 3) Clarify that those portions the user is permitted to see are sent. I.e., replace the above sentence with something along the lines of "Similar to a operation, the user only sees content within a Notification that they are authorized to see." Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of David Harrington Sent: Tuesday, June 10, 2008 9:32 AM To: 'Andy Bierman'; 'Bert Wijnen - IETF' Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) Hi, > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Monday, June 09, 2008 12:44 AM > To: Bert Wijnen - IETF > Cc: netconf@ietf.org > Subject: Re: [Netconf] Pre-13 Notification (take 2) > > Bert Wijnen - IETF wrote: > > Andy and David, > > > > Sharon was/is trying to clarify some text in the security > > considerations section in order to address comments from the IESG > > review. > > > > I don't think we want to go through a long process of debating all > > the option we have for notifications. We do not have a > > (satndardized) ACM for NETCONF, and so we do not have to be explicit > > as to what exactly happens in all cases, do we? We have to > > warn/explain to the user what he needs to look out for when > > supporting enabling notifications. > > > > If you are not happy with the new text, can you then pls propose > > your text (as a minimum). > > Since I'm the one who seems to be holding this up, I don't think you're the only one holding this up. I am too. The problem is that the loose wording in this document imposes restrictions on future access control models, including using RFC2119 reserved words "informally". It should not do that. We have proposed alternate text that would resolve the problem, but the editor usually insists on rewording the proposed text, and puts the problem back in. I think we finally got the most egregious paragraph fixed, and another paragraph (I think it was introduced in the new revision) now does the same thing. One of the big problems Andy has raised is that what is meant to be non-normative text ends up being normative. Remember the whole debate about RFC3411's title being "An Architecture" rather than "The Architecture" because it was not meant to be normative? Well all subsequent IETF WG work has had the RFC3411 treated as normative; all subsequent approved charters have insisted that the WGs MUST NOT violate the RFC3411 architecture. That took non-normative text and made it normative. Andy and I have experience with non-normative text becoming normative and we want to avoid that happening here. It is not acceptable to argue that "it's just informal and not normative"; we should not be making vague informal statements that could be treated as normative in the future. Another big problem is that consensus is that netconf notifications can carry data from syslog and/or snmp notifications. Without addressing access control models now, and the interaction between netconf/syslog/snmp data models and possibly interactions between the authentication of identities used by the protocols, we cannot possibly understand the implications of saying something like "if the user does not have access to all the data contained in the notification, then the netconf notification will not be sent." The netconf implementation will presumably have no idea what access the user will have to syslog data elements or syslog messages or snmp objects; therefore, if the notification contains syslog or snmp data, it cannot tell whether to send the netconf notification or not. A third problem, as raised by Andy, is that the document should not say that the notification will or will not be sent based on user access to all the content according to some other operation, because the matching alforithm for operations might differ. We have not decided what content must be in a notification or how the access controls will work, and the decision on those points should be made explicitly, not as a side-effect of some sloppy text in the notifications document. We need to make sure the notifications document makes no presumptions about the content of the notifications, or the user's access to that content, as long as user identities, data models and access controls have not been standardized yet. The loose wording in this document imposes restrictions on future models. It should not do that. _______________________________________________ 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 netconf-bounces@ietf.org Tue Jun 10 12:23:37 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672373A6AA7; Tue, 10 Jun 2008 12:23:37 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C63428C0F8 for ; Tue, 10 Jun 2008 12:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.345 X-Spam-Level: X-Spam-Status: No, score=-6.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UO2B090jNJgD for ; Tue, 10 Jun 2008 12:23:29 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 282293A6AEE for ; Tue, 10 Jun 2008 12:23:06 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5AJNF514020; Tue, 10 Jun 2008 19:23:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 15:23:07 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B414F917E9@zcarhxm2.corp.nortel.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB05D81CA9@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Choosing Solution for partial authorization (was RE:Pre-13 Notification (take 2)) Thread-Index: AcjJhwYXPsPP1NIiTUm+r661XcgBDwBcaMHwAAHWOTAABvhuAAAEuBOA References: <484C0C6C.1020606@netconfcentral.com><003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com> <85B2F271FDF6B949B3672BA5A7BB62FB05D81CA9@xmb-sjc-236.amer.cisco.com> From: "Sharon Chisholm" To: "Alexander Clemm (alex)" , "David Harrington" , "Andy Bierman" , "Bert Wijnen - IETF" Cc: netconf@ietf.org Subject: Re: [Netconf] Choosing Solution for partial authorization (was RE:Pre-13 Notification (take 2)) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Let me see if I understand what you are saying. You are saying that option 3 is still ambiguous (which I think I agree with after Martin's comment) so you are looking for a fourth option where either 4a. While defining the notification it is captured whether or not Notifications get sent for partial authorization 4b. It is left strictly to the authorization policy whether partially authorized Notifications get sent. If I understand these options, I think I still prefer some form of 3. 3a. The Andy text I indicated below 3b. A stricter version that indicates that the Notification is still sent without the non-authorized information. Sharon -----Original Message----- From: Alexander Clemm (alex) [mailto:alex@cisco.com] Sent: Tuesday, June 10, 2008 1:17 PM To: Chisholm, Sharon (CAR:ZZ00); David Harrington; Andy Bierman; Bert Wijnen - IETF Cc: netconf@ietf.org Subject: RE: [Netconf] Choosing Solution for partial authorization (was RE:Pre-13 Notification (take 2)) Shouldn't there be a 4th option, to indicate whether users are authorized to view/receive the notification (as opposed to specifying it indirectly)? I can see the appeal of 2 and 3, but both are somewhat unsatisfactory. 2 will lead to some unintended and difficult to explain side effects from the perspective of end users, who may be unaware of the fact that a conflict exists with regards to one parameter with regards to a particular message. Similarly, option 3 appears to lead to unexpected "heterogeneity" regarding the same type of message. --- Alex -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Sharon Chisholm Sent: Tuesday, June 10, 2008 7:00 AM To: David Harrington; Andy Bierman; Bert Wijnen - IETF Cc: netconf@ietf.org Subject: [Netconf] Choosing Solution for partial authorization (was RE:Pre-13 Notification (take 2)) Hi The text we are arguing about at the moment was added a long time ago (May 2007). The goal at the time was to try and drive consistent behaviour in the case where the Notification contained information the user was not allowed to see. The agreement at the time was to just not send anything. I think some good points have been raised, particularly with Andy's analogy to the operation, that question whether the working group made the right decision at the time. So, we have three options here. Please indicate your preference: 1) Leave it ambiguous as to whether any of the Notification message is sent. I.e., delete the sentence "If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user." 2) Clarify that nothing is sent. I.e., keep text the same. 3) Clarify that those portions the user is permitted to see are sent. I.e., replace the above sentence with something along the lines of "Similar to a operation, the user only sees content within a Notification that they are authorized to see." Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of David Harrington Sent: Tuesday, June 10, 2008 9:32 AM To: 'Andy Bierman'; 'Bert Wijnen - IETF' Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) Hi, > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Monday, June 09, 2008 12:44 AM > To: Bert Wijnen - IETF > Cc: netconf@ietf.org > Subject: Re: [Netconf] Pre-13 Notification (take 2) > > Bert Wijnen - IETF wrote: > > Andy and David, > > > > Sharon was/is trying to clarify some text in the security > > considerations section in order to address comments from the IESG > > review. > > > > I don't think we want to go through a long process of debating all > > the option we have for notifications. We do not have a > > (satndardized) ACM for NETCONF, and so we do not have to be explicit > > as to what exactly happens in all cases, do we? We have to > > warn/explain to the user what he needs to look out for when > > supporting enabling notifications. > > > > If you are not happy with the new text, can you then pls propose > > your text (as a minimum). > > Since I'm the one who seems to be holding this up, I don't think you're the only one holding this up. I am too. The problem is that the loose wording in this document imposes restrictions on future access control models, including using RFC2119 reserved words "informally". It should not do that. We have proposed alternate text that would resolve the problem, but the editor usually insists on rewording the proposed text, and puts the problem back in. I think we finally got the most egregious paragraph fixed, and another paragraph (I think it was introduced in the new revision) now does the same thing. One of the big problems Andy has raised is that what is meant to be non-normative text ends up being normative. Remember the whole debate about RFC3411's title being "An Architecture" rather than "The Architecture" because it was not meant to be normative? Well all subsequent IETF WG work has had the RFC3411 treated as normative; all subsequent approved charters have insisted that the WGs MUST NOT violate the RFC3411 architecture. That took non-normative text and made it normative. Andy and I have experience with non-normative text becoming normative and we want to avoid that happening here. It is not acceptable to argue that "it's just informal and not normative"; we should not be making vague informal statements that could be treated as normative in the future. Another big problem is that consensus is that netconf notifications can carry data from syslog and/or snmp notifications. Without addressing access control models now, and the interaction between netconf/syslog/snmp data models and possibly interactions between the authentication of identities used by the protocols, we cannot possibly understand the implications of saying something like "if the user does not have access to all the data contained in the notification, then the netconf notification will not be sent." The netconf implementation will presumably have no idea what access the user will have to syslog data elements or syslog messages or snmp objects; therefore, if the notification contains syslog or snmp data, it cannot tell whether to send the netconf notification or not. A third problem, as raised by Andy, is that the document should not say that the notification will or will not be sent based on user access to all the content according to some other operation, because the matching alforithm for operations might differ. We have not decided what content must be in a notification or how the access controls will work, and the decision on those points should be made explicitly, not as a side-effect of some sloppy text in the notifications document. We need to make sure the notifications document makes no presumptions about the content of the notifications, or the user's access to that content, as long as user identities, data models and access controls have not been standardized yet. The loose wording in this document imposes restrictions on future models. It should not do that. _______________________________________________ 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 netconf-bounces@ietf.org Tue Jun 10 12:26:40 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4E033A6AEA; Tue, 10 Jun 2008 12:26:40 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F7E13A6AEA for ; Tue, 10 Jun 2008 12:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1rZRM3zuTea for ; Tue, 10 Jun 2008 12:26:38 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 6F0923A6AD0 for ; Tue, 10 Jun 2008 12:26:38 -0700 (PDT) Received: (qmail 32290 invoked from network); 10 Jun 2008 19:27:00 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.137.251 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 10 Jun 2008 19:26:57 -0000 X-YMail-OSG: 4EcITsYVM1kgqZbSyEZmOjKpUJo4SsfB9awNyvZZGk_Am_eTlHd6CUZ6tqSUQE21_JzFmTW3zLYO3v62WUIaUI2ThorE9HNwrAVZSDfSAA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <484ED57E.6060209@netconfcentral.com> Date: Tue, 10 Jun 2008 12:26:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B414F90EBD@zcarhxm2.corp.nortel.com> <20080610.162400.257616676.mbj@tail-f.com> In-Reply-To: <20080610.162400.257616676.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Choosing Solution for partial authorization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > "Sharon Chisholm" wrote: > >> For option 3, a slight modification to some text suggested by Andy (we >> don't have agents ;-)) would work nicely >> >> The NETCONF server MUST NOT include any content in a notification >> which the user is not authorized to view. > > I prefer this one. It leaves the decision to drop or prune the > notification to the future authorization discussions. > yes -- it might turn out (when a well-designed and agreed-upon access control model is done) that there is some good reason to treat access differently than access. Until then, the standard should be silent on the issue. Can we get consensus on this edit and close the thread? > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jun 10 12:26:40 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4E033A6AEA; Tue, 10 Jun 2008 12:26:40 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F7E13A6AEA for ; Tue, 10 Jun 2008 12:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1rZRM3zuTea for ; Tue, 10 Jun 2008 12:26:38 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 6F0923A6AD0 for ; Tue, 10 Jun 2008 12:26:38 -0700 (PDT) Received: (qmail 32290 invoked from network); 10 Jun 2008 19:27:00 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.122.137.251 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 10 Jun 2008 19:26:57 -0000 X-YMail-OSG: 4EcITsYVM1kgqZbSyEZmOjKpUJo4SsfB9awNyvZZGk_Am_eTlHd6CUZ6tqSUQE21_JzFmTW3zLYO3v62WUIaUI2ThorE9HNwrAVZSDfSAA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <484ED57E.6060209@netconfcentral.com> Date: Tue, 10 Jun 2008 12:26:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B414F90EBD@zcarhxm2.corp.nortel.com> <20080610.162400.257616676.mbj@tail-f.com> In-Reply-To: <20080610.162400.257616676.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Choosing Solution for partial authorization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: > Hi, > > "Sharon Chisholm" wrote: > >> For option 3, a slight modification to some text suggested by Andy (we >> don't have agents ;-)) would work nicely >> >> The NETCONF server MUST NOT include any content in a notification >> which the user is not authorized to view. > > I prefer this one. It leaves the decision to drop or prune the > notification to the future authorization discussions. > yes -- it might turn out (when a well-designed and agreed-upon access control model is done) that there is some good reason to treat access differently than access. Until then, the standard should be silent on the issue. Can we get consensus on this edit and close the thread? > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jun 11 08:37:23 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB0AD3A6A5D; Wed, 11 Jun 2008 08:37:23 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7D13A6879 for ; Wed, 11 Jun 2008 08:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxBFNMNtL8TR for ; Wed, 11 Jun 2008 08:37:15 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 9C2A23A6933 for ; Wed, 11 Jun 2008 08:37:10 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5BFbQu05683; Wed, 11 Jun 2008 15:37:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Jun 2008 11:36:42 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B414FDA819@zcarhxm2.corp.nortel.com> In-Reply-To: <484ED57E.6060209@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Choosing Solution for partial authorization Thread-Index: AcjLL/YZIzCWoLu8Sea5QYSw1ujjnQAqFr4w References: <003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B414F90EBD@zcarhxm2.corp.nortel.com> <20080610.162400.257616676.mbj@tail-f.com> <484ED57E.6060209@netconfcentral.com> From: "Sharon Chisholm" To: "Andy Bierman" , "Martin Bjorklund" Cc: netconf@ietf.org Subject: Re: [Netconf] Choosing Solution for partial authorization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Does anyone then disagree with making this change (3a) Replace "If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user." With " The NETCONF server MUST NOT include any content in a notification which the user is not authorized to view." If not, then I will make this change, publish as -14 and then I think we can send the document on its way. I believe this means sending it back to the IESG for approval again. Sharon -----Original Message----- From: Andy Bierman [mailto:andy@netconfcentral.com] Sent: Tuesday, June 10, 2008 3:27 PM To: Martin Bjorklund Cc: Chisholm, Sharon (CAR:ZZ00); ietfdbh@comcast.net; bertietf@bwijnen.net; netconf@ietf.org Subject: Re: [Netconf] Choosing Solution for partial authorization Martin Bjorklund wrote: > Hi, > > "Sharon Chisholm" wrote: > >> For option 3, a slight modification to some text suggested by Andy >> (we don't have agents ;-)) would work nicely >> >> The NETCONF server MUST NOT include any content in a notificaFrom netconf-bounces@ietf.org Wed Jun 11 08:37:23 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB0AD3A6A5D; Wed, 11 Jun 2008 08:37:23 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7D13A6879 for ; Wed, 11 Jun 2008 08:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxBFNMNtL8TR for ; Wed, 11 Jun 2008 08:37:15 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 9C2A23A6933 for ; Wed, 11 Jun 2008 08:37:10 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5BFbQu05683; Wed, 11 Jun 2008 15:37:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Jun 2008 11:36:42 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B414FDA819@zcarhxm2.corp.nortel.com> In-Reply-To: <484ED57E.6060209@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Choosing Solution for partial authorization Thread-Index: AcjLL/YZIzCWoLu8Sea5QYSw1ujjnQAqFr4w References: <003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B414F90EBD@zcarhxm2.corp.nortel.com> <20080610.162400.257616676.mbj@tail-f.com> <484ED57E.6060209@netconfcentral.com> From: "Sharon Chisholm" To: "Andy Bierman" , "Martin Bjorklund" Cc: netconf@ietf.org Subject: Re: [Netconf] Choosing Solution for partial authorization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Does anyone then disagree with making this change (3a) Replace "If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user." With " The NETCONF server MUST NOT include any content in a notification which the user is not authorized to view." If not, then I will make this change, publish as -14 and then I think we can send the document on its way. I believe this means sending it back to the IESG for approval again. Sharon -----Original Message----- From: Andy Bierman [mailto:andy@netconfcentral.com] Sent: Tuesday, June 10, 2008 3:27 PM To: Martin Bjorklund Cc: Chisholm, Sharon (CAR:ZZ00); ietfdbh@comcast.net; bertietf@bwijnen.net; netconf@ietf.org Subject: Re: [Netconf] Choosing Solution for partial authorization Martin Bjorklund wrote: > Hi, > > "Sharon Chisholm" wrote: > >> For option 3, a slight modification to some text suggested by Andy >> (we don't have agents ;-)) would work nicely >> >> The NETCONF server MUST NOT include any content in a notion >> which the user is not authorized to view. > > I prefer this one. It leaves the decision to drop or prune the > notification to the future authorization discussions. > yes -- it might turn out (when a well-designed and agreed-upon access control model is done) that there is some good reason to treat access differently than access. Until then, the standard should be silent on the issue. Can we get consensus on this edit and close the thread? > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf tification >> which the user is not authorized to view. > > I prefer this one. It leaves the decision to drop or prune the > notification to the future authorization discussions. > yes -- it might turn out (when a well-designed and agreed-upon access control model is done) that there is some good reason to treat access differently than access. Until then, the standard should be silent on the issue. Can we get consensus on this edit and close the thread? > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jun 11 09:00:37 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401263A690C; Wed, 11 Jun 2008 09:00:37 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 870C43A690C for ; Wed, 11 Jun 2008 09:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4tDqW2PRcTK for ; Wed, 11 Jun 2008 09:00:35 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 1F9E83A67B2 for ; Wed, 11 Jun 2008 09:00:34 -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 m5BG0w8C016402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2008 18:00:58 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5BG0qnA021172; Wed, 11 Jun 2008 18:00:54 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jun 2008 18:00:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Jun 2008 18:00:51 +0200 Message-ID: In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B414FDA819@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Choosing Solution for partial authorization thread-index: AcjLL/YZIzCWoLu8Sea5QYSw1ujjnQAqFr4wAAB2maA= References: <003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com><713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com><713043CE8B8E1348AF3C546DBE02C1B414F90EBD@zcarhxm2.corp.nortel.com><20080610.162400.257616676.mbj@tail-f.com><484ED57E.6060209@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B414FDA819@zcarhxm2.corp.nortel.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Sharon Chisholm" X-OriginalArrivalTime: 11 Jun 2008 16:00:52.0324 (UTC) FILETIME=[52D8C240:01C8CBDC] Cc: netconf@ietf.org Subject: Re: [Netconf] Choosing Solution for partial authorization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Sharon, All, I personally support the proposed text change. Let us close the issue and have a consensus on this edit asap. If there is anybody who has any objections (hopefully not) please speak up. Otherwise, as Sharon says, we will send it as -14 back to the IESG. Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Sharon Chisholm > Sent: Wednesday, June 11, 2008 5:37 PM > To: Andy Bierman; Martin Bjorklund > Cc: netconf@ietf.org > Subject: Re: [Netconf] Choosing Solution for partial authorization > > Hi > > Does anyone then disagree with making this change (3a) > > Replace > > "If a user is not authorized to view all elements in the > content of the > notification, the notification is not sent to that user." > > With > > " The NETCONF server MUST NOT include any content in a notification > which the user is not authorized to view." > > If not, then I will make this change, publish as -14 and then > I think we > can send the document on its way. I believe this means sending it back > to the IESG for approval again. > > Sharon > > -----Original Message----- > From: Andy Bierman [mailto:andy@netconfcentral.com] > Sent: Tuesday, June 10, 2008 3:27 PM > To: Martin Bjorklund > Cc: Chisholm, Sharon (CAR:ZZ00); ietfdbh@comcast.net; > bertietf@bwijnen.net; netconf@ietf.org > Subject: Re: [Netconf] Choosing Solution for partial authorization > > Martin Bjorklund wrote: > > Hi, > > > > "Sharon Chisholm" wrote: > > > >> For option 3, a slight modification to some text suggested by Andy > >> (we don't have agents ;-)) would work nicely > >> > >> The NETCONF server MUST NOT include any content in a > notification > >> which the user is not authorized to view. > > > > I prefer this one. It leaves the decision to drop or prune the > > notification to the future authorization discussions. > > > > yes -- it might turn out (when a well-designed and agreed-upon access > control model is done) that there is some good reason to treat > access differently than access. > Until then, the standard should be silent on the issue. > > Can we get consensus on this edit and close the thread? > > > > > /martin > > > > > > > > Andy > > _______________________________________________ > 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 netconf-bounces@ietf.org Wed Jun 11 09:00:37 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401263A690C; Wed, 11 Jun 2008 09:00:37 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 870C43A690C for ; Wed, 11 Jun 2008 09:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4tDqW2PRcTK for ; Wed, 11 Jun 2008 09:00:35 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 1F9E83A67B2 for ; Wed, 11 Jun 2008 09:00:34 -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 m5BG0w8C016402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2008 18:00:58 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5BG0qnA021172; Wed, 11 Jun 2008 18:00:54 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jun 2008 18:00:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Jun 2008 18:00:51 +0200 Message-ID: In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B414FDA819@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Choosing Solution for partial authorization thread-index: AcjLL/YZIzCWoLu8Sea5QYSw1ujjnQAqFr4wAAB2maA= References: <003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com><713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com><713043CE8B8E1348AF3C546DBE02C1B414F90EBD@zcarhxm2.corp.nortel.com><20080610.162400.257616676.mbj@tail-f.com><484ED57E.6060209@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B414FDA819@zcarhxm2.corp.nortel.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Sharon Chisholm" X-OriginalArrivalTime: 11 Jun 2008 16:00:52.0324 (UTC) FILETIME=[52D8C240:01C8CBDC] Cc: netconf@ietf.org Subject: Re: [Netconf] Choosing Solution for partial authorization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Sharon, All, I personally support the proposed text change. Let us close the issue and have a consensus on this edit asap. If there is anybody who has any objections (hopefully not) please speak up. Otherwise, as Sharon says, we will send it as -14 back to the IESG. Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Sharon Chisholm > Sent: Wednesday, June 11, 2008 5:37 PM > To: Andy Bierman; Martin Bjorklund > Cc: netconf@ietf.org > Subject: Re: [Netconf] Choosing Solution for partial authorization > > Hi > > Does anyone then disagree with making this change (3a) > > Replace > > "If a user is not authorized to view all elements in the > content of the > notification, the notification is not sent to that user." > > With > > " The NETCONF server MUST NOT include any content in a notification > which the user is not authorized to view." > > If not, then I will make this change, publish as -14 and then > I think we > can send the document on its way. I believe this means sending it back > to the IESG for approval again. > > Sharon > > -----Original Message----- > From: Andy Bierman [mailto:andy@netconfcentral.com] > Sent: Tuesday, June 10, 2008 3:27 PM > To: Martin Bjorklund > Cc: Chisholm, Sharon (CAR:ZZ00); ietfdbh@comcast.net; > bertietf@bwijnen.net; netconf@ietf.org > Subject: Re: [Netconf] Choosing Solution for partial authorization > > Martin Bjorklund wrote: > > Hi, > > > > "Sharon Chisholm" wrote: > > > >> For option 3, a slight modification to some text suggested by Andy > >> (we don't have agents ;-)) would work nicely > >> > >> The NETCONF server MUST NOT include any content in a > notification > >> which the user is not authorized to view. > > > > I prefer this one. It leaves the decision to drop or prune the > > notification to the future authorization discussions. > > > > yes -- it might turn out (when a well-designed and agreed-upon access > control model is done) that there is some good reason to treat > access differently than access. > Until then, the standard should be silent on the issue. > > Can we get consensus on this edit and close the thread? > > > > > /martin > > > > > > > > Andy > > _______________________________________________ > 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 netconf-bounces@ietf.org Wed Jun 11 11:05:51 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD0F3A689A; Wed, 11 Jun 2008 11:05:51 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5EC3A6958 for ; Wed, 11 Jun 2008 11:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.515 X-Spam-Level: X-Spam-Status: No, score=-1.515 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YY5OBp7okZic for ; Wed, 11 Jun 2008 11:05:49 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0893A689A for ; Wed, 11 Jun 2008 11:05:49 -0700 (PDT) X-Trace: 42584736/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-temporary-group/213.116.52.85 X-SBRS: None X-RemoteIP: 213.116.52.85 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAOewT0jVdDRV/2dsb2JhbACLeaYhAw X-IronPort-AV: E=Sophos;i="4.27,625,1204502400"; d="scan'208";a="42584736" X-IP-Direction: IN Received: from 1cust85.tnt102.lnd4.gbr.da.uu.net (HELO allison) ([213.116.52.85]) by smtp.pipex.tiscali.co.uk with SMTP; 11 Jun 2008 19:06:13 +0100 Message-ID: <000201c8cbe4$c0a85b20$0601a8c0@allison> From: "tom.petch" To: , "Martin Bjorklund" References: <003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com><713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com><713043CE8B8E1348AF3C546DBE02C1B414F90EBD@zcarhxm2.corp.nortel.com> <20080610.162400.257616676.mbj@tail-f.com> Date: Tue, 10 Jun 2008 18:22:24 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netconf@ietf.org Subject: Re: [Netconf] Choosing Solution for partial authorization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org +1 Tom Petch ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Tuesday, June 10, 2008 4:24 PM Subject: Re: [Netconf] Choosing Solution for partial authorization > Hi, > > "Sharon Chisholm" wrote: > > > For option 3, a slight modification to some text suggested by Andy (we > > don't have agents ;-)) would work nicely > > > > The NETCONF server MUST NOT include any content in a notification > > which the user is not authorized to view. > > I prefer this one. It leaves the decision to drop or prune the > notification to the future authorization discussions. > > > /martin > _______________________________________________ > 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 netconf-bounces@ietf.org Wed Jun 11 11:05:51 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD0F3A689A; Wed, 11 Jun 2008 11:05:51 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5EC3A6958 for ; Wed, 11 Jun 2008 11:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.515 X-Spam-Level: X-Spam-Status: No, score=-1.515 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YY5OBp7okZic for ; Wed, 11 Jun 2008 11:05:49 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0893A689A for ; Wed, 11 Jun 2008 11:05:49 -0700 (PDT) X-Trace: 42584736/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-temporary-group/213.116.52.85 X-SBRS: None X-RemoteIP: 213.116.52.85 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAOewT0jVdDRV/2dsb2JhbACLeaYhAw X-IronPort-AV: E=Sophos;i="4.27,625,1204502400"; d="scan'208";a="42584736" X-IP-Direction: IN Received: from 1cust85.tnt102.lnd4.gbr.da.uu.net (HELO allison) ([213.116.52.85]) by smtp.pipex.tiscali.co.uk with SMTP; 11 Jun 2008 19:06:13 +0100 Message-ID: <000201c8cbe4$c0a85b20$0601a8c0@allison> From: "tom.petch" To: , "Martin Bjorklund" References: <003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com><713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com><713043CE8B8E1348AF3C546DBE02C1B414F90EBD@zcarhxm2.corp.nortel.com> <20080610.162400.257616676.mbj@tail-f.com> Date: Tue, 10 Jun 2008 18:22:24 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netconf@ietf.org Subject: Re: [Netconf] Choosing Solution for partial authorization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org +1 Tom Petch ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Tuesday, June 10, 2008 4:24 PM Subject: Re: [Netconf] Choosing Solution for partial authorization > Hi, > > "Sharon Chisholm" wrote: > > > For option 3, a slight modification to some text suggested by Andy (we > > don't have agents ;-)) would work nicely > > > > The NETCONF server MUST NOT include any content in a notification > > which the user is not authorized to view. > > I prefer this one. It leaves the decision to drop or prune the > notification to the future authorization discussions. > > > /martin > _______________________________________________ > 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 netconf-bounces@ietf.org Thu Jun 12 01:21:18 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEC003A69D9; Thu, 12 Jun 2008 01:21:18 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA3FA3A69DC for ; Thu, 12 Jun 2008 01:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIWFw1iN5FoM for ; Thu, 12 Jun 2008 01:20:50 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 93BC93A69D9 for ; Thu, 12 Jun 2008 01:20:50 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0AEDB2154B; Thu, 12 Jun 2008 10:21:17 +0200 (CEST) X-AuditID: c1b4fb3e-ae999bb000004ec0-8d-4850dc7cf84c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EDE4921556; Thu, 12 Jun 2008 10:21:16 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 10:21:23 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 10:21:23 +0200 Message-ID: <4850DC7C.2030903@ericsson.com> Date: Thu, 12 Jun 2008 10:21:16 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Sharon Chisholm References: <003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B414F90EBD@zcarhxm2.corp.nortel.com> <20080610.162400.257616676.mbj@tail-f.com> <484ED57E.6060209@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B414FDA819@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B414FDA819@zcarhxm2.corp.nortel.com> X-OriginalArrivalTime: 12 Jun 2008 08:21:23.0553 (UTC) FILETIME=[4CFDE510:01C8CC65] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Choosing Solution for partial authorization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I like the text. Balazs Sharon Chisholm wrote: > Hi > > Does anyone then disagree with making this change (3a) > > Replace > > "If a user is not authorized to view all elements in the content of the > notification, the notification is not sent to that user." > > With > > " The NETCONF server MUST NOT include any content in a notification > which the user is not authorized to view." > > If not, then I will make this change, publish as -14 and then I think we > can send the document on its way. I believe this means sending it back > to the IESG for approval again. > > SharFrom netconf-bounces@ietf.org Thu Jun 12 01:21:18 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEC003A69D9; Thu, 12 Jun 2008 01:21:18 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA3FA3A69DC for ; Thu, 12 Jun 2008 01:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIWFw1iN5FoM for ; Thu, 12 Jun 2008 01:20:50 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 93BC93A69D9 for ; Thu, 12 Jun 2008 01:20:50 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0AEDB2154B; Thu, 12 Jun 2008 10:21:17 +0200 (CEST) X-AuditID: c1b4fb3e-ae999bb000004ec0-8d-4850dc7cf84c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EDE4921556; Thu, 12 Jun 2008 10:21:16 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 10:21:23 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 10:21:23 +0200 Message-ID: <4850DC7C.2030903@ericsson.com> Date: Thu, 12 Jun 2008 10:21:16 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Sharon Chisholm References: <003e01c8cafe$6b0b8480$9106a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B414F90DE9@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B414F90EBD@zcarhxm2.corp.nortel.com> <20080610.162400.257616676.mbj@tail-f.com> <484ED57E.6060209@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B414FDA819@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B414FDA819@zcarhxm2.corp.nortel.com> X-OriginalArrivalTime: 12 Jun 2008 08:21:23.0553 (UTC) FILETIME=[4CFDE510:01C8CC65] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Choosing Solution for partial authorization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I like the text. Balazs Sharon Chisholm wrote: > Hi > > Does anyone then disagree with making this change (3a) > > Replace > > "If a user is not authorized to view all elements in the content of the > notification, the notification is not sent to that user." > > With > > " The NETCONF server MUST NOT include any content in a notification > which the user is not authorized to view." > > If not, then I will make this change, publish as -14 and then I think we > can send the document on its way. I believe this means sending it back > to the IESG for approval again. > > Sharon > on > > -----Original Message----- > From: Andy Bierman [mailto:andy@netconfcentral.com] > Sent: Tuesday, June 10, 2008 3:27 PM > To: Martin Bjorklund > Cc: Chisholm, Sharon (CAR:ZZ00); ietfdbh@comcast.net; > bertietf@bwijnen.net; netconf@ietf.org > Subject: Re: [Netconf] Choosing Solution for partial authorization > > Martin Bjorklund wrote: >> Hi, >> >> "Sharon Chisholm" wrote: >> >>> For option 3, a slight modification to some text suggested by Andy >>> (we don't have agents ;-)) would work nicely >>> >>> The NETCONF server MUST NOT include any content in a notification >>> which the user is not authorized to view. >> I prefer this one. It leaves the decision to drop or prune the >> notification to the future authorization discussions. >> > > yes -- it might turn out (when a well-designed and agreed-upon access > control model is done) that there is some good reason to treat > access differently than access. > Until then, the standard should be silent on the issue. > > Can we get consensus on this edit and close the thread? > >> /martin >> >> >> > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf > -----Original Message----- > From: Andy Bierman [mailto:andy@netconfcentral.com] > Sent: Tuesday, June 10, 2008 3:27 PM > To: Martin Bjorklund > Cc: Chisholm, Sharon (CAR:ZZ00); ietfdbh@comcast.net; > bertietf@bwijnen.net; netconf@ietf.org > Subject: Re: [Netconf] Choosing Solution for partial authorization > > Martin Bjorklund wrote: >> Hi, >> >> "Sharon Chisholm" wrote: >> >>> For option 3, a slight modification to some text suggested by Andy >>> (we don't have agents ;-)) would work nicely >>> >>> The NETCONF server MUST NOT include any content in a notification >>> which the user is not authorized to view. >> I prefer this one. It leaves the decision to drop or prune the >> notification to the future authorization discussions. >> > > yes -- it might turn out (when a well-designed and agreed-upon access > control model is done) that there is some good reason to treat > access differently than access. > Until then, the standard should be silent on the issue. > > Can we get consensus on this edit and close the thread? > >> /martin >> >> >> > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jun 13 01:30:04 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432013A6B3D; Fri, 13 Jun 2008 01:30:04 -0700 (PDT) X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 571763A68C2; Fri, 13 Jun 2008 01:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080613083002.571763A68C2@core3.amsl.com> Date: Fri, 13 Jun 2008 01:30:02 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-partial-lock-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --NextPart 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 : Partial Lock RPC for NETCONF Author(s) : B. Lengyel, M. Bjorklund Filename : draft-ietf-netconf-partial-lock-02.txt Pages : 19 Date : 2008-06-13 The NETCONF protocol defines the lock and unlock RPCs that lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-partial-lock-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-partial-lock-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-13012440.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --NextPart-- From netconf-bounces@ietf.org Fri Jun 13 01:30:04 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432013A6B3D; Fri, 13 Jun 2008 01:30:04 -0700 (PDT) X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 571763A68C2; Fri, 13 Jun 2008 01:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080613083002.571763A68C2@core3.amsl.com> Date: Fri, 13 Jun 2008 01:30:02 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-partial-lock-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --NextPart 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 : Partial Lock RPC for NETCONF Author(s) : B. Lengyel, M. Bjorklund Filename : draft-ietf-netconf-partial-lock-02.txt Pages : 19 Date : 2008-06-13 The NETCONF protocol defines the lock and unlock RPCs that lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-partial-lock-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-partial-lock-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-13012440.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --NextPart-- From netconf-bounces@ietf.org Fri Jun 13 01:37:18 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117163A690E; Fri, 13 Jun 2008 01:37:18 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4D583A690E for ; Fri, 13 Jun 2008 01:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNKRWxY9bE9q for ; Fri, 13 Jun 2008 01:37:13 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id BC1A03A68F2 for ; Fri, 13 Jun 2008 01:37:13 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AF71C204EF for ; Fri, 13 Jun 2008 10:37:43 +0200 (CEST) X-AuditID: c1b4fb3e-b019cbb000004ec0-e0-485231d7113c Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9BFBA20104 for ; Fri, 13 Jun 2008 10:37:43 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 10:37:05 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 10:36:48 +0200 Message-ID: <48523197.5010008@ericsson.com> Date: Fri, 13 Jun 2008 10:36:39 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf@ietf.org X-OriginalArrivalTime: 13 Jun 2008 08:36:48.0548 (UTC) FILETIME=[9EBEAE40:01C8CD30] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] New Version for draft-ietf-netconf-partial-lock-02 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello All, I updated the partial lock draft. I hope it is perfect :-) , but if not, or if I missed some of your comments, please tell me! I would like to ask everyone especially Wes to check the security considerations part. http://www.ietf.org/internet-drafts/draft-ietf-netconf-partial-lock-02.txt If I receive comments, I will possibly make another update before Dublin. Balazs -------- Original Message -------- Subject: New Version Notification for draft-ietf-netconf-partial-lock-02 Date: Fri, 13 Jun 2008 01:24:40 -0700 (PDT) From: IETF I-D Submission Tool To: balazs.lengyel@ericsson.com CC: mbj@tail-f.com A new version of I-D, draft-ietf-netconf-partial-lock-02.txt has been successfuly submitted by Balazs Lengyel and posted to the IETF repository. Filename: draft-ietf-netconf-partial-lock Revision: 02 Title: Partial Lock RPC for NETCONF Creation_date: 2008-06-13 WG ID: netconf Number_of_pages: 19 Abstract: The NETCONF protocol defines the lock and unlock RPCs that lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. The IETF Secretariat. -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jun 13 01:37:18 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117163A690E; Fri, 13 Jun 2008 01:37:18 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4D583A690E for ; Fri, 13 Jun 2008 01:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNKRWxY9bE9q for ; Fri, 13 Jun 2008 01:37:13 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id BC1A03A68F2 for ; Fri, 13 Jun 2008 01:37:13 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AF71C204EF for ; Fri, 13 Jun 2008 10:37:43 +0200 (CEST) X-AuditID: c1b4fb3e-b019cbb000004ec0-e0-485231d7113c Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9BFBA20104 for ; Fri, 13 Jun 2008 10:37:43 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 10:37:05 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 10:36:48 +0200 Message-ID: <48523197.5010008@ericsson.com> Date: Fri, 13 Jun 2008 10:36:39 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf@ietf.org X-OriginalArrivalTime: 13 Jun 2008 08:36:48.0548 (UTC) FILETIME=[9EBEAE40:01C8CD30] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] New Version for draft-ietf-netconf-partial-lock-02 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello All, I updated the partial lock draft. I hope it is perfect :-) , but if not, or if I missed some of your comments, please tell me! I would like to ask everyone especially Wes to check the security considerations part. http://www.ietf.org/internet-drafts/draft-ietf-netconf-partial-lock-02.txt If I receive comments, I will possibly make another update before Dublin. Balazs -------- Original Message -------- Subject: New Version Notification for draft-ietf-netconf-partial-lock-02 Date: Fri, 13 Jun 2008 01:24:40 -0700 (PDT) From: IETF I-D Submission Tool To: balazs.lengyel@ericsson.com CC: mbj@tail-f.com A new version of I-D, draft-ietf-netconf-partial-lock-02.txt has been successfuly submitted by Balazs Lengyel and posted to the IETF repository. Filename: draft-ietf-netconf-partial-lock Revision: 02 Title: Partial Lock RPC for NETCONF Creation_date: 2008-06-13 WG ID: netconf Number_of_pages: 19 Abstract: The NETCONF protocol defines the lock and unlock RPCs that lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. The IETF Secretariat. -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jun 13 12:15:04 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45293A6956; Fri, 13 Jun 2008 12:15:04 -0700 (PDT) X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2497E3A6890; Fri, 13 Jun 2008 12:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080613191502.2497E3A6890@core3.amsl.com> Date: Fri, 13 Jun 2008 12:15:02 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-notification-14.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --NextPart 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 Event Notifications Author(s) : S. Chisholm, H. Trevino Filename : draft-ietf-netconf-notification-14.txt Pages : 49 Date : 2008-06-13 This document defines mechanisms that provide an asynchronous message notification delivery service for the NETCONF protocol. This is an optional capability built on top of the base NETCONF definition. This document defines the capabilities and operations necessary to support this service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-notification-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-13120108.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --NextPart-- From netconf-bounces@ietf.org Fri Jun 13 12:15:04 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45293A6956; Fri, 13 Jun 2008 12:15:04 -0700 (PDT) X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2497E3A6890; Fri, 13 Jun 2008 12:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080613191502.2497E3A6890@core3.amsl.com> Date: Fri, 13 Jun 2008 12:15:02 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-notification-14.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --NextPart 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 Event Notifications Author(s) : S. Chisholm, H. Trevino Filename : draft-ietf-netconf-notification-14.txt Pages : 49 Date : 2008-06-13 This document defines mechanisms that provide an asynchronous message notification delivery service for the NETCONF protocol. This is an optional capability built on top of the base NETCONF definition. This document defines the capabilities and operations necessary to support this service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-notification-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-13120108.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --NextPart-- From netconf-bounces@ietf.org Sun Jun 15 14:26:00 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 593433A683E; Sun, 15 Jun 2008 14:26:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7ACE3A683E for ; Sun, 15 Jun 2008 14:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oORdBd+0VAzE for ; Sun, 15 Jun 2008 14:25:59 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id DE0263A6837 for ; Sun, 15 Jun 2008 14:25:58 -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 m5FLQZOa006859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jun 2008 23:26:35 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5FLQY33015348; Sun, 15 Jun 2008 23:26:35 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 15 Jun 2008 23:26:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 15 Jun 2008 23:26:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NETCONF - Requested session has been scheduled for IETF 72 Thread-Index: AcjM1Bp8RWzJXRQeT7C0+3j6QNwlyQCWiMMw From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 15 Jun 2008 21:26:34.0838 (UTC) FILETIME=[7CBEBF60:01C8CF2E] Subject: [Netconf] FW: NETCONF - Requested session has been scheduled for IETF 72 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi All, NETCONF WG session at IETF #72 has been scheduled as shown below. Mehmet -----Original Message----- From: ext IETF Secretariat [mailto:agenda@ietf.org] Sent: Thursday, June 12, 2008 11:34 PM To: Ersue, Mehmet (NSN - DE/Muenich) Cc: bertietf@bwijnen.net; dromasca@avaya.com; rbonica@juniper.net; session-request@ietf.org Subject: NETCONF - Requested session has been scheduled for IETF 72 Dear Mehmet Ersue, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the information of sessions that you have requested. NETCONF Session 1 (1 hour) Tuesday, Afternoon Session IV 1850-1950 Room Name: Conservatory ---------------------------------------------- _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Jun 15 14:26:00 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 593433A683E; Sun, 15 Jun 2008 14:26:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7ACE3A683E for ; Sun, 15 Jun 2008 14:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oORdBd+0VAzE for ; Sun, 15 Jun 2008 14:25:59 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id DE0263A6837 for ; Sun, 15 Jun 2008 14:25:58 -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 m5FLQZOa006859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jun 2008 23:26:35 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5FLQY33015348; Sun, 15 Jun 2008 23:26:35 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 15 Jun 2008 23:26:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 15 Jun 2008 23:26:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NETCONF - Requested session has been scheduled for IETF 72 Thread-Index: AcjM1Bp8RWzJXRQeT7C0+3j6QNwlyQCWiMMw From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 15 Jun 2008 21:26:34.0838 (UTC) FILETIME=[7CBEBF60:01C8CF2E] Subject: [Netconf] FW: NETCONF - Requested session has been scheduled for IETF 72 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi All, NETCONF WG session at IETF #72 has been scheduled as shown below. Mehmet -----Original Message----- From: ext IETF Secretariat [mailto:agenda@ietf.org] Sent: Thursday, June 12, 2008 11:34 PM To: Ersue, Mehmet (NSN - DE/Muenich) Cc: bertietf@bwijnen.net; dromasca@avaya.com; rbonica@juniper.net; session-request@ietf.org Subject: NETCONF - Requested session has been scheduled for IETF 72 Dear Mehmet Ersue, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the information of sessions that you have requested. NETCONF Session 1 (1 hour) Tuesday, Afternoon Session IV 1850-1950 Room Name: Conservatory ---------------------------------------------- _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jun 16 04:52:20 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45C8B3A69D5; Mon, 16 Jun 2008 04:52:20 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75E153A69C9 for ; Mon, 16 Jun 2008 04:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.43 X-Spam-Level: X-Spam-Status: No, score=-6.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3G+F6qRRaQK for ; Mon, 16 Jun 2008 04:52:15 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 679C73A690A for ; Mon, 16 Jun 2008 04:52:15 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m5GBpQP07093 for ; Mon, 16 Jun 2008 11:51:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 07:52:51 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Netconf Notification: One last bit of Discuss: Session Accumulation Thread-Index: AcjPp4FlL4SZ1AM4QZ+Sp96euSjbTg== From: "Sharon Chisholm" To: Subject: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi I originally thought this would not require an update to the document, but here it is. I propose the following text to resolve: If a malicious or buggy NETCONF client sends a number of requests without ever terminating any of them, they will accumulate subscriptions and begin to use up system resources. They do so while accumulating NETCONF sessions and when the underlying NETCONF session is terminated, so is the Notification subscription. The operation should be used to terminate any suspect NETCONF sessions. >There is only one remaining issue. I identified tha following issue from Blake Ramsdell's >secdir review as blocking: >> >> >>> * Is there a risk of sessions accumulating? That is, too many >>> create-subscription requests without termination? >>> >> > > From the authors explanation, it is the netconf server's responsibility to kill sessions if needed to address a DoS attack. > >> The subscription terminates when the underlying NETCONF session goes >> way. In order to accumulate subscriptions, you need to accumulate >> NETCONF sessions. These may well be a finite resource, but the base >> protocol provides a command to kill a particular >> session from another session if there is an issue. >> > >The explanation is fine, but I think a sentence or two in the security considerations is needed to alert implementers. I believe this can be easily resolved with an RFC Editor Note. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jun 16 04:52:20 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45C8B3A69D5; Mon, 16 Jun 2008 04:52:20 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75E153A69C9 for ; Mon, 16 Jun 2008 04:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.43 X-Spam-Level: X-Spam-Status: No, score=-6.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3G+F6qRRaQK for ; Mon, 16 Jun 2008 04:52:15 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 679C73A690A for ; Mon, 16 Jun 2008 04:52:15 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m5GBpQP07093 for ; Mon, 16 Jun 2008 11:51:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 07:52:51 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Netconf Notification: One last bit of Discuss: Session Accumulation Thread-Index: AcjPp4FlL4SZ1AM4QZ+Sp96euSjbTg== From: "Sharon Chisholm" To: Subject: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi I originally thought this would not require an update to the document, but here it is. I propose the following text to resolve: If a malicious or buggy NETCONF client sends a number of requests without ever terminating any of them, they will accumulate subscriptions and begin to use up system resources. They do so while accumulating NETCONF sessions and when the underlying NETCONF session is terminated, so is the Notification subscription. The operation should be used to terminate any suspect NETCONF sessions. >There is only one remaining issue. I identified tha following issue from Blake Ramsdell's >secdir review as blocking: >> >> >>> * Is there a risk of sessions accumulating? That is, too many >>> create-subscription requests without termination? >>> >> > > From the authors explanation, it is the netconf server's responsibility to kill sessions if needed to address a DoS attack. > >> The subscription terminates when the underlying NETCONF session goes >> way. In order to accumulate subscriptions, you need to accumulate >> NETCONF sessions. These may well be a finite resource, but the base >> protocol provides a command to kill a particular >> session from another session if there is an issue. >> > >The explanation is fine, but I think a sentence or two in the security considerations is needed to alert implementers. I believe this can be easily resolved with an RFC Editor Note. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jun 16 08:16:00 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EBAF3A68CF; Mon, 16 Jun 2008 08:16:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720753A68CF for ; Mon, 16 Jun 2008 08:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yA+9h0fR8L6 for ; Mon, 16 Jun 2008 08:15:58 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id A1EF43A683F for ; Mon, 16 Jun 2008 08:15:58 -0700 (PDT) Received: (qmail 18429 invoked from network); 16 Jun 2008 15:16:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.84.44 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 16 Jun 2008 15:16:38 -0000 X-YMail-OSG: oTQHmdcVM1mAMeEn1IGrVaoonqKVdTeeI9fxH6ZCF8LOKPok4shACI3.BL5u51F2UJdDoMr7pdmK.zlzxVcItkO0xlMNDujmEfziBXPOt44muG2VS7CFVDRF.vpmkgaCi8rTi2B.eJcYLFrkrAJ1LS64 X-Yahoo-Newman-Property: ymail-3 Message-ID: <485683D4.5050006@netconfcentral.com> Date: Mon, 16 Jun 2008 08:16:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > I originally thought this would not require an update to the document, > but here it is. I propose the following text to resolve: > > If a malicious or buggy NETCONF client sends a number of > requests without ever terminating any of them, > they will accumulate subscriptions and begin to use up system resources. > They do so while accumulating NETCONF sessions and when the underlying > NETCONF session is terminated, so is the Notification subscription. The > operation should be used to terminate any suspect NETCONF > sessions. I don't see why a new doc-rev is needed. Isn't this incredibly obvious? Isn't this the same for any session-based protocol? IMO, there is no need to mention that the agent should clean up underlying resources when a session is terminated. This is either an implementation detail, or it is already covered in RFC 4741. Andy > >> There is only one remaining issue. I identified tha following issue > from Blake Ramsdell's >secdir review as blocking: >>> >>>> * Is there a risk of sessions accumulating? That is, too many >>>> create-subscription requests without termination? >>>> >> From the authors explanation, it isFrom netconf-bounces@ietf.org Mon Jun 16 08:16:00 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EBAF3A68CF; Mon, 16 Jun 2008 08:16:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720753A68CF for ; Mon, 16 Jun 2008 08:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yA+9h0fR8L6 for ; Mon, 16 Jun 2008 08:15:58 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id A1EF43A683F for ; Mon, 16 Jun 2008 08:15:58 -0700 (PDT) Received: (qmail 18429 invoked from network); 16 Jun 2008 15:16:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.84.44 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 16 Jun 2008 15:16:38 -0000 X-YMail-OSG: oTQHmdcVM1mAMeEn1IGrVaoonqKVdTeeI9fxH6ZCF8LOKPok4shACI3.BL5u51F2UJdDoMr7pdmK.zlzxVcItkO0xlMNDujmEfziBXPOt44muG2VS7CFVDRF.vpmkgaCi8rTi2B.eJcYLFrkrAJ1LS64 X-Yahoo-Newman-Property: ymail-3 Message-ID: <485683D4.5050006@netconfcentral.com> Date: Mon, 16 Jun 2008 08:16:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > I originally thought this would not require an update to the document, > but here it is. I propose the following text to resolve: > > If a malicious or buggy NETCONF client sends a number of > requests without ever terminating any of them, > they will accumulate subscriptions and begin to use up system resources. > They do so while accumulating NETCONF sessions and when the underlying > NETCONF session is terminated, so is the Notification subscription. The > operation should be used to terminate any suspect NETCONF > sessions. I don't see why a new doc-rev is needed. Isn't this incredibly obvious? Isn't this the same for any session-based protocol? IMO, there is no need to mention that the agent should clean up underlying resources when a session is terminated. This is either an implementation detail, or it is already covered in RFC 4741. Andy > >> There is only one remaining issue. I identified tha following issue > from Blake Ramsdell's >secdir review as blocking: >>> >>>> * Is there a risk of sessions accumulating? That is, too many >>>> create-subscription requests without termination? >>>> >> From the authors explanation, it is the n the netconf server's > responsibility to kill sessions if needed to address a DoS attack. >>> The subscription terminates when the underlying NETCONF session goes >>> way. In order to accumulate subscriptions, you need to accumulate >>> NETCONF sessions. These may well be a finite resource, but the base >>> protocol provides a command to kill a particular >>> session from another session if there is an issue. >>> >> The explanation is fine, but I think a sentence or two in the security > considerations is needed to alert implementers. I believe this can be > easily resolved with an RFC Editor Note. > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > 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 etconf server's > responsibility to kill sessions if needed to address a DoS attack. >>> The subscription terminates when the underlying NETCONF session goes >>> way. In order to accumulate subscriptions, you need to accumulate >>> NETCONF sessions. These may well be a finite resource, but the base >>> protocol provides a command to kill a particular >>> session from another session if there is an issue. >>> >> The explanation is fine, but I think a sentence or two in the security > considerations is needed to alert implementers. I believe this can be > easily resolved with an RFC Editor Note. > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > 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 netconf-bounces@ietf.org Mon Jun 16 09:27:15 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D173A67DF; Mon, 16 Jun 2008 09:27:15 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7943A67DF for ; Mon, 16 Jun 2008 09:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiK1A+E8e5i8 for ; Mon, 16 Jun 2008 09:27:13 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 14C3C3A676A for ; Mon, 16 Jun 2008 09:27:12 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m5GGQOP13483; Mon, 16 Jun 2008 16:26:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 12:27:49 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4150B4FCE@zcarhxm2.corp.nortel.com> In-Reply-To: <485683D4.5050006@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation Thread-Index: AcjPxAIR4weHu7KcRuG+VZYWFwjfBwACc3tw References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> <485683D4.5050006@netconfcentral.com> From: "Sharon Chisholm" To: "Andy Bierman" Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Why I don't disagree, this change can be made with an RFC editor's note, so I don't see the harm. Sharon -----Original Message----- From: Andy Bierman [mailto:andy@netconfcentral.com] Sent: Monday, June 16, 2008 11:17 AM To: Chisholm, Sharon (CAR:ZZ00) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation Sharon Chisholm wrote: > Hi > > I originally thought this would not require an update to the document, > but here it is. I propose the following text to resolve: > > If a malicious or buggy NETCONF client sends a number of > requests without ever terminating any of them, > they will accumulate subscriptions and begin to use up system resources. > They do so while accumulating NETCONF sessions and when the underlying > NETCONF session is terminated, so is the Notification subscription. > The operation should be used to terminate any suspect > NETCONF sessions. I don't see why a new doc-rev is needed. Isn't this incredibly obvious? Isn't this the same for any session-based protocol? IMO, there is no need to mention that the agent should clean up underlying resources when a session is terminated. ThFrom netconf-bounces@ietf.org Mon Jun 16 09:27:15 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D173A67DF; Mon, 16 Jun 2008 09:27:15 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7943A67DF for ; Mon, 16 Jun 2008 09:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiK1A+E8e5i8 for ; Mon, 16 Jun 2008 09:27:13 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 14C3C3A676A for ; Mon, 16 Jun 2008 09:27:12 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m5GGQOP13483; Mon, 16 Jun 2008 16:26:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 12:27:49 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4150B4FCE@zcarhxm2.corp.nortel.com> In-Reply-To: <485683D4.5050006@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation Thread-Index: AcjPxAIR4weHu7KcRuG+VZYWFwjfBwACc3tw References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> <485683D4.5050006@netconfcentral.com> From: "Sharon Chisholm" To: "Andy Bierman" Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Why I don't disagree, this change can be made with an RFC editor's note, so I don't see the harm. Sharon -----Original Message----- From: Andy Bierman [mailto:andy@netconfcentral.com] Sent: Monday, June 16, 2008 11:17 AM To: Chisholm, Sharon (CAR:ZZ00) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation Sharon Chisholm wrote: > Hi > > I originally thought this would not require an update to the document, > but here it is. I propose the following text to resolve: > > If a malicious or buggy NETCONF client sends a number of > requests without ever terminating any of them, > they will accumulate subscriptions and begin to use up system resources. > They do so while accumulating NETCONF sessions and when the underlying > NETCONF session is terminated, so is the Notification subscription. > The operation should be used to terminate any suspect > NETCONF sessions. I don't see why a new doc-rev is needed. Isn't this incredibly obvious? Isn't this the same for any session-based protocol? IMO, there is no need to mention that the agent should clean up underlying resources when a session is terminated. This is is is either an implementation detail, or it is already covered in RFC 4741. Andy > >> There is only one remaining issue. I identified tha following issue > from Blake Ramsdell's >secdir review as blocking: >>> >>>> * Is there a risk of sessions accumulating? That is, too many >>>> create-subscription requests without termination? >>>> >> From the authors explanation, it is the netconf server's > responsibility to kill sessions if needed to address a DoS attack. >>> The subscription terminates when the underlying NETCONF session goes >>> way. In order to accumulate subscriptions, you need to accumulate >>> NETCONF sessions. These may well be a finite resource, but the base >>> protocol provides a command to kill a particular >>> session from another session if there is an issue. >>> >> The explanation is fine, but I think a sentence or two in the >> security > considerations is needed to alert implementers. I believe this can be > easily resolved with an RFC Editor Note. > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > 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 either an implementation detail, or it is already covered in RFC 4741. Andy > >> There is only one remaining issue. I identified tha following issue > from Blake Ramsdell's >secdir review as blocking: >>> >>>> * Is there a risk of sessions accumulating? That is, too many >>>> create-subscription requests without termination? >>>> >> From the authors explanation, it is the netconf server's > responsibility to kill sessions if needed to address a DoS attack. >>> The subscription terminates when the underlying NETCONF session goes >>> way. In order to accumulate subscriptions, you need to accumulate >>> NETCONF sessions. These may well be a finite resource, but the base >>> protocol provides a command to kill a particular >>> session from another session if there is an issue. >>> >> The explanation is fine, but I think a sentence or two in the >> security > considerations is needed to alert implementers. I believe this can be > easily resolved with an RFC Editor Note. > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > 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 netconf-bounces@ietf.org Mon Jun 16 09:35:14 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623F93A676A; Mon, 16 Jun 2008 09:35:14 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452A33A65A5 for ; Mon, 16 Jun 2008 09:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bp08zGX9LD+b for ; Mon, 16 Jun 2008 09:35:13 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id DC4383A676A for ; Mon, 16 Jun 2008 09:35:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,653,1204520400"; d="scan'208";a="111423127" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 16 Jun 2008 12:35:52 -0400 X-IronPort-AV: E=Sophos;i="4.27,653,1204520400"; d="scan'208";a="212472271" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 16 Jun 2008 12:35:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 18:34:50 +0200 Message-ID: In-Reply-To: <485683D4.5050006@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation Thread-Index: AcjPw/1FwF8xBAX5RkOl5vAGrIxl2QACqdPA References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> <485683D4.5050006@netconfcentral.com> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , "Sharon Chisholm" Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This was not so obvious for the Security AD Tim Polk who entered the DISCUSS. If the clarification proposed by Sharon is accepted by Tim and can be added by an RFC Editor note, we can resolve the DISCUSS. Dan > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Monday, June 16, 2008 6:17 PM > To: Sharon Chisholm > Cc: netconf@ietf.org > Subject: Re: [Netconf] Netconf Notification: One last bit of > Discuss: Session Accumulation > > Sharon Chisholm wrote: > > Hi > > > > I originally thought this would not require an update to > the document, > > but here it is. I propose the following text to resolve: > > > > If a malicious or buggy NETCONF client sends a number of > > requests without ever terminating > any of them, > > they will accumulate subscriptions and begin to use up > systFrom netconf-bounces@ietf.org Mon Jun 16 09:35:14 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623F93A676A; Mon, 16 Jun 2008 09:35:14 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452A33A65A5 for ; Mon, 16 Jun 2008 09:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bp08zGX9LD+b for ; Mon, 16 Jun 2008 09:35:13 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id DC4383A676A for ; Mon, 16 Jun 2008 09:35:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,653,1204520400"; d="scan'208";a="111423127" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 16 Jun 2008 12:35:52 -0400 X-IronPort-AV: E=Sophos;i="4.27,653,1204520400"; d="scan'208";a="212472271" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 16 Jun 2008 12:35:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 18:34:50 +0200 Message-ID: In-Reply-To: <485683D4.5050006@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation Thread-Index: AcjPw/1FwF8xBAX5RkOl5vAGrIxl2QACqdPA References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> <485683D4.5050006@netconfcentral.com> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , "Sharon Chisholm" Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This was not so obvious for the Security AD Tim Polk who entered the DISCUSS. If the clarification proposed by Sharon is accepted by Tim and can be added by an RFC Editor note, we can resolve the DISCUSS. Dan > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Monday, June 16, 2008 6:17 PM > To: Sharon Chisholm > Cc: netconf@ietf.org > Subject: Re: [Netconf] Netconf Notification: One last bit of > Discuss: Session Accumulation > > Sharon Chisholm wrote: > > Hi > > > > I originally thought this would not require an update to > the document, > > but here it is. I propose the following text to resolve: > > > > If a malicious or buggy NETCONF client sends a number of > > requests without ever terminating > any of them, > > they will accumulate subscriptions and begin to use up > system resources. > > They do so while accumulating NETCONF sessions and when the > underlying > > NETCONF session is terminated, so is the Notification subscription. > > The operation should be used to terminate > any suspect > > NETCONF sessions. > > I don't see why a new doc-rev is needed. > Isn't this incredibly obvious? > Isn't this the same for any session-based protocol? > > IMO, there is no need to mention that the agent should clean > up underlying resources when a session is terminated. > This is either an implementation detail, or it is already > covered in RFC 4741. > > > > Andy > > > > > > >> There is only one remaining issue. I identified tha > following issue > > from Blake Ramsdell's >secdir review as blocking: > >>> > >>>> * Is there a risk of sessions accumulating? That is, too many > >>>> create-subscription requests without termination? > >>>> > >> From the authors explanation, it is the netconf server's > > responsibility to kill sessions if needed to address a DoS attack. > >>> The subscription terminates when the underlying NETCONF > session goes > >>> way. In order to accumulate subscriptions, you need to accumulate > >>> NETCONF sessions. These may well be a finite resource, > but the base > >>> protocol provides a command to kill a particular > >>> session from another session if there is an issue. > >>> > >> The explanation is fine, but I think a sentence or two in the > >> security > > considerations is needed to alert implementers. I believe > this can be > > easily resolved with an RFC Editor Note. > > > > Sharon Chisholm > > Nortel > > Ottawa, Ontario > > Canada > > _______________________________________________ > > 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 em resources. > > They do so while accumulating NETCONF sessions and when the > underlying > > NETCONF session is terminated, so is the Notification subscription. > > The operation should be used to terminate > any suspect > > NETCONF sessions. > > I don't see why a new doc-rev is needed. > Isn't this incredibly obvious? > Isn't this the same for any session-based protocol? > > IMO, there is no need to mention that the agent should clean > up underlying resources when a session is terminated. > This is either an implementation detail, or it is already > covered in RFC 4741. > > > > Andy > > > > > > >> There is only one remaining issue. I identified tha > following issue > > from Blake Ramsdell's >secdir review as blocking: > >>> > >>>> * Is there a risk of sessions accumulating? That is, too many > >>>> create-subscription requests without termination? > >>>> > >> From the authors explanation, it is the netconf server's > > responsibility to kill sessions if needed to address a DoS attack. > >>> The subscription terminates when the underlying NETCONF > session goes > >>> way. In order to accumulate subscriptions, you need to accumulate > >>> NETCONF sessions. These may well be a finite resource, > but the base > >>> protocol provides a command to kill a particular > >>> session from another session if there is an issue. > >>> > >> The explanation is fine, but I think a sentence or two in the > >> security > > considerations is needed to alert implementers. I believe > this can be > > easily resolved with an RFC Editor Note. > > > > Sharon Chisholm > > Nortel > > Ottawa, Ontario > > Canada > > _______________________________________________ > > 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 netconf-bounces@ietf.org Mon Jun 16 09:43:30 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 382083A69BA; Mon, 16 Jun 2008 09:43:30 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 411FE3A69BA for ; Mon, 16 Jun 2008 09:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCb0oGpxOiWg for ; Mon, 16 Jun 2008 09:43:28 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 8383B3A6999 for ; Mon, 16 Jun 2008 09:43:28 -0700 (PDT) Received: (qmail 81200 invoked from network); 16 Jun 2008 16:44:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.84.44 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 16 Jun 2008 16:44:08 -0000 X-YMail-OSG: ibJVh9gVM1l9nhEPyBpyRsup7iGIlFzLPfgUOAYHV_78AGvc.6IFCjGR5YWCprJx12I.6CjjZZP39Kdf6AUUGX10Bm1glarwOzT0VGEn0aZ939rbWuDrTOGbcw85u9TonEY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48569856.7080600@netconfcentral.com> Date: Mon, 16 Jun 2008 09:44:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> <485683D4.5050006@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B4150B4FCE@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4150B4FCE@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > Why I don't disagree, this change can be made with an RFC editor's note, > so I don't see the harm. > IMO, standards should be precise, and normative text should be as small as possible. Tell me how to implement the specification in an inter-operable manner, and nothing else. (Obviously a minority opinion in the IETF.) The text is ambiguous. Does it mean N sessions? N requests on 1 session? Is this normative text in the attachment? > Sharon Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jun 16 09:43:30 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 382083A69BA; Mon, 16 Jun 2008 09:43:30 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 411FE3A69BA for ; Mon, 16 Jun 2008 09:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCb0oGpxOiWg for ; Mon, 16 Jun 2008 09:43:28 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 8383B3A6999 for ; Mon, 16 Jun 2008 09:43:28 -0700 (PDT) Received: (qmail 81200 invoked from network); 16 Jun 2008 16:44:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.84.44 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 16 Jun 2008 16:44:08 -0000 X-YMail-OSG: ibJVh9gVM1l9nhEPyBpyRsup7iGIlFzLPfgUOAYHV_78AGvc.6IFCjGR5YWCprJx12I.6CjjZZP39Kdf6AUUGX10Bm1glarwOzT0VGEn0aZ939rbWuDrTOGbcw85u9TonEY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48569856.7080600@netconfcentral.com> Date: Mon, 16 Jun 2008 09:44:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> <485683D4.5050006@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B4150B4FCE@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4150B4FCE@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > Why I don't disagree, this change can be made with an RFC editor's note, > so I don't see the harm. > IMO, standards should be precise, and normative text should be as small as possible. Tell me how to implement the specification in an inter-operable manner, and nothing else. (Obviously a minority opinion in the IETF.) The text is ambiguous. Does it mean N sessions? N requests on 1 session? Is this normative text in the attachment? > Sharon Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jun 16 09:55:49 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1F463A69D0; Mon, 16 Jun 2008 09:55:49 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 967313A69D0 for ; Mon, 16 Jun 2008 09:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAJB0pNCPNBv for ; Mon, 16 Jun 2008 09:55:47 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 92B503A6920 for ; Mon, 16 Jun 2008 09:55:47 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5GGuOl06415; Mon, 16 Jun 2008 16:56:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 12:56:15 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4150B5050@zcarhxm2.corp.nortel.com> In-Reply-To: <48569856.7080600@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation Thread-Index: AcjP0DTczws4spyLTB2i4Vhv+QvdLAAAY84g References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> <485683D4.5050006@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B4150B4FCE@zcarhxm2.corp.nortel.com> <48569856.7080600@netconfcentral.com> From: "Sharon Chisholm" To: "Andy Bierman" Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi It is going in the security considerations section. The text is more instructions to the operator then the implementer. Do you have any suggested improvements? Sharon -----Original Message----- From: Andy Bierman [mailto:andy@netconfcentral.com] Sent: Monday, June 16, 2008 12:44 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation Sharon Chisholm wrote: > Hi > > Why I don't disagree, this change can be made with an RFC editor's > note, so I don't see the harm. > IMO, standards should be precise, and normative text should be as small as possible. Tell me how to implement the specification in an inter-operable manner, and nothing else. (Obviously a minority opinion in the IETF.) The text is ambiguous. Does it mean N sessions? N requests on 1 session? Is this normative text in the attachment? > Sharon Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jun 16 09:55:49 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1F463A69D0; Mon, 16 Jun 2008 09:55:49 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 967313A69D0 for ; Mon, 16 Jun 2008 09:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAJB0pNCPNBv for ; Mon, 16 Jun 2008 09:55:47 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 92B503A6920 for ; Mon, 16 Jun 2008 09:55:47 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5GGuOl06415; Mon, 16 Jun 2008 16:56:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 12:56:15 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4150B5050@zcarhxm2.corp.nortel.com> In-Reply-To: <48569856.7080600@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation Thread-Index: AcjP0DTczws4spyLTB2i4Vhv+QvdLAAAY84g References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> <485683D4.5050006@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B4150B4FCE@zcarhxm2.corp.nortel.com> <48569856.7080600@netconfcentral.com> From: "Sharon Chisholm" To: "Andy Bierman" Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi It is going in the security considerations section. The text is more instructions to the operator then the implementer. Do you have any suggested improvements? Sharon -----Original Message----- From: Andy Bierman [mailto:andy@netconfcentral.com] Sent: Monday, June 16, 2008 12:44 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation Sharon Chisholm wrote: > Hi > > Why I don't disagree, this change can be made with an RFC editor's > note, so I don't see the harm. > IMO, standards should be precise, and normative text should be as small as possible. Tell me how to implement the specification in an inter-operable manner, and nothing else. (Obviously a minority opinion in the IETF.) The text is ambiguous. Does it mean N sessions? N requests on 1 session? Is this normative text in the attachment? > Sharon Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jun 16 10:09:38 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 809FB3A6977; Mon, 16 Jun 2008 10:09:38 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F9A83A69AF for ; Mon, 16 Jun 2008 10:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVZNspp++pPY for ; Mon, 16 Jun 2008 10:09:31 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 914963A6859 for ; Mon, 16 Jun 2008 10:09:31 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 19BDCC0040; Mon, 16 Jun 2008 19:10:13 +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 GqG-eX-z22rY; Mon, 16 Jun 2008 19:10:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5660CC0036; Mon, 16 Jun 2008 19:10:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 37FBE5D3565; Mon, 16 Jun 2008 19:10:06 +0200 (CEST) Date: Mon, 16 Jun 2008 19:10:06 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm Message-ID: <20080616171006.GA5003@elstar.local> Mail-Followup-To: Sharon Chisholm , netconf@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Mon, Jun 16, 2008 at 07:52:51AM -0400, Sharon Chisholm wrote: > If a malicious or buggy NETCONF client sends a number of > requests without ever terminating any of them, > they will accumulate subscriptions and begin to use up system resources. > They do so while accumulating NETCONF sessions and when the underlying > NETCONF session is terminated, so is the Notification subscription. The > operation should be used to terminate any suspect NETCONF > sessions. I do not understand the second sentence. And who is "they" in the first sentence? What about this wording: If a malicious or buggy NETCONF client sends a number of requests, then these subscriptions accumulate and may use up system resources. In such a situation, subscriptions can be terminated by terminating the suspect underlying NETCONF sessions using the operation. /js -- 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 netconf-bounces@ietf.org Mon Jun 16 10:09:38 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 809FB3A6977; Mon, 16 Jun 2008 10:09:38 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F9A83A69AF for ; Mon, 16 Jun 2008 10:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVZNspp++pPY for ; Mon, 16 Jun 2008 10:09:31 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 914963A6859 for ; Mon, 16 Jun 2008 10:09:31 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 19BDCC0040; Mon, 16 Jun 2008 19:10:13 +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 GqG-eX-z22rY; Mon, 16 Jun 2008 19:10:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5660CC0036; Mon, 16 Jun 2008 19:10:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 37FBE5D3565; Mon, 16 Jun 2008 19:10:06 +0200 (CEST) Date: Mon, 16 Jun 2008 19:10:06 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm Message-ID: <20080616171006.GA5003@elstar.local> Mail-Followup-To: Sharon Chisholm , netconf@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Mon, Jun 16, 2008 at 07:52:51AM -0400, Sharon Chisholm wrote: > If a malicious or buggy NETCONF client sends a number of > requests without ever terminating any of them, > they will accumulate subscriptions and begin to use up system resources. > They do so while accumulating NETCONF sessions and when the underlying > NETCONF session is terminated, so is the Notification subscription. The > operation should be used to terminate any suspect NETCONF > sessions. I do not understand the second sentence. And who is "they" in the first sentence? What about this wording: If a malicious or buggy NETCONF client sends a number of requests, then these subscriptions accumulate and may use up system resources. In such a situation, subscriptions can be terminated by terminating the suspect underlying NETCONF sessions using the operation. /js -- 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 netconf-bounces@ietf.org Mon Jun 16 10:43:25 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06B2A3A6944; Mon, 16 Jun 2008 10:43:25 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5AEC3A6944 for ; Mon, 16 Jun 2008 10:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iquHDwAl276F for ; Mon, 16 Jun 2008 10:43:23 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id CE24D3A67DA for ; Mon, 16 Jun 2008 10:43:22 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5GHi0l14693; Mon, 16 Jun 2008 17:44:01 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 13:43:59 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4150B517C@zcarhxm2.corp.nortel.com> In-Reply-To: <20080616171006.GA5003@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation Thread-Index: AcjP09pThYBwizEeQL+GUxmVjuyZUAABKmzQ References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> <20080616171006.GA5003@elstar.local> From: "Sharon Chisholm" To: Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi That version works for me. Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Monday, June 16, 2008 1:10 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation On Mon, Jun 16, 2008 at 07:52:51AM -0400, Sharon Chisholm wrote: > If a malicious or buggy NETCONF client sends a number of > requests without ever terminating any of them, > they will accumulate subscriptions and begin to use up system resources. > They do so while accumulating NETCONF sessions and when the underlying > NETCONF session is terminated, so is the Notification subscription. > The operation should be used to terminate any suspect > NETCONF sessions. I do not understand the second sentence. And who is "they" in the first sentence? What about this wording: If a malicious or buggy NETCONF client sends a number of requests, then these subscriptions accumulate and may use up system resources. In such a situation, subscriptions can be terminated by terminating the suspect underlying NETCONF sessions using the operation. /js -- 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 netconf-bounces@ietf.org Mon Jun 16 10:43:25 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06B2A3A6944; Mon, 16 Jun 2008 10:43:25 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5AEC3A6944 for ; Mon, 16 Jun 2008 10:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iquHDwAl276F for ; Mon, 16 Jun 2008 10:43:23 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id CE24D3A67DA for ; Mon, 16 Jun 2008 10:43:22 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5GHi0l14693; Mon, 16 Jun 2008 17:44:01 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 13:43:59 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4150B517C@zcarhxm2.corp.nortel.com> In-Reply-To: <20080616171006.GA5003@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation Thread-Index: AcjP09pThYBwizEeQL+GUxmVjuyZUAABKmzQ References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> <20080616171006.GA5003@elstar.local> From: "Sharon Chisholm" To: Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi That version works for me. Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Monday, June 16, 2008 1:10 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation On Mon, Jun 16, 2008 at 07:52:51AM -0400, Sharon Chisholm wrote: > If a malicious or buggy NETCONF client sends a number of > requests without ever terminating any of them, > they will accumulate subscriptions and begin to use up system resources. > They do so while accumulating NETCONF sessions and when the underlying > NETCONF session is terminated, so is the Notification subscription. > The operation should be used to terminate any suspect > NETCONF sessions. I do not understand the second sentence. And who is "they" in the first sentence? What about this wording: If a malicious or buggy NETCONF client sends a number of requests, then these subscriptions accumulate and may use up system resources. In such a situation, subscriptions can be terminated by terminating the suspect underlying NETCONF sessions using the operation. /js -- 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 netconf-bounces@ietf.org Mon Jun 16 10:56:37 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993663A68AF; Mon, 16 Jun 2008 10:56:37 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D1AC3A68AF for ; Mon, 16 Jun 2008 10:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apTSGMs9mJ39 for ; Mon, 16 Jun 2008 10:56:35 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id 6365D3A6816 for ; Mon, 16 Jun 2008 10:56:33 -0700 (PDT) Received: (qmail 45917 invoked from network); 16 Jun 2008 17:57:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.84.44 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 16 Jun 2008 17:57:13 -0000 X-YMail-OSG: RDHG8p4VM1mprWMu7IlCW5UKykM9zz_dnMTWT3ZZ3nHIzlW.zb08zAcKL6YssmaLTWiAxadT1FyCT3MPTbfv_zL1bbhaFV8TswPaYVZAZg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4856A976.3060609@netconfcentral.com> Date: Mon, 16 Jun 2008 10:57:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> <20080616171006.GA5003@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B4150B517C@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4150B517C@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > That version works for me. > My concern is that is seems to imply that an agent is going to support multiple, concurrent notification subscriptions on the same session. The WG never agreed to this feature. Does this text refer to 1 subscription on each session, or N subscriptions on 1 session, or both? (A: yes ;-) In my (even recent experience), when the standard is silent on a subject, it is harder to interpret the specification incorrectly. However, when a standard is *almost* silent (i.e., partially specified) then it is very easy for people to interpret the standard incorrectly, in N different ways. It should be clear that the standard does not define what happens when a is received on a session while in notification mode already. Some vendors want to utilize this feature, and I think they should be able to experiment. Vendors who reject requests while in notification mode are also compliant to the standard. > Sharon Andy > > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, June 16, 2008 1:10 PM > To: ChisholmFrom netconf-bounces@ietf.org Mon Jun 16 10:56:37 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993663A68AF; Mon, 16 Jun 2008 10:56:37 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D1AC3A68AF for ; Mon, 16 Jun 2008 10:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apTSGMs9mJ39 for ; Mon, 16 Jun 2008 10:56:35 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id 6365D3A6816 for ; Mon, 16 Jun 2008 10:56:33 -0700 (PDT) Received: (qmail 45917 invoked from network); 16 Jun 2008 17:57:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.84.44 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 16 Jun 2008 17:57:13 -0000 X-YMail-OSG: RDHG8p4VM1mprWMu7IlCW5UKykM9zz_dnMTWT3ZZ3nHIzlW.zb08zAcKL6YssmaLTWiAxadT1FyCT3MPTbfv_zL1bbhaFV8TswPaYVZAZg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4856A976.3060609@netconfcentral.com> Date: Mon, 16 Jun 2008 10:57:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> <20080616171006.GA5003@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B4150B517C@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4150B517C@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > That version works for me. > My concern is that is seems to imply that an agent is going to support multiple, concurrent notification subscriptions on the same session. The WG never agreed to this feature. Does this text refer to 1 subscription on each session, or N subscriptions on 1 session, or both? (A: yes ;-) In my (even recent experience), when the standard is silent on a subject, it is harder to interpret the specification incorrectly. However, when a standard is *almost* silent (i.e., partially specified) then it is very easy for people to interpret the standard incorrectly, in N different ways. It should be clear that the standard does not define what happens when a is received on a session while in notification mode already. Some vendors want to utilize this feature, and I think they should be able to experiment. Vendors who reject requests while in notification mode are also compliant to the standard. > Sharon Andy > > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, June 16, 2008 1:10 PM > To: Chisholm, Shar, Sharon (CAR:ZZ00) > Cc: netconf@ietf.org > Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: > Session Accumulation > > On Mon, Jun 16, 2008 at 07:52:51AM -0400, Sharon Chisholm wrote: > >> If a malicious or buggy NETCONF client sends a number of >> requests without ever terminating any of them, >> they will accumulate subscriptions and begin to use up system > resources. >> They do so while accumulating NETCONF sessions and when the underlying > >> NETCONF session is terminated, so is the Notification subscription. >> The operation should be used to terminate any suspect >> NETCONF sessions. > > I do not understand the second sentence. And who is "they" in the first > sentence? What about this wording: > > If a malicious or buggy NETCONF client sends a number of > requests, then these subscriptions accumulate > and may use up system resources. In such a situation, subscriptions > can be terminated by terminating the suspect underlying NETCONF > sessions using the operation. > > /js > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf on (CAR:ZZ00) > Cc: netconf@ietf.org > Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: > Session Accumulation > > On Mon, Jun 16, 2008 at 07:52:51AM -0400, Sharon Chisholm wrote: > >> If a malicious or buggy NETCONF client sends a number of >> requests without ever terminating any of them, >> they will accumulate subscriptions and begin to use up system > resources. >> They do so while accumulating NETCONF sessions and when the underlying > >> NETCONF session is terminated, so is the Notification subscription. >> The operation should be used to terminate any suspect >> NETCONF sessions. > > I do not understand the second sentence. And who is "they" in the first > sentence? What about this wording: > > If a malicious or buggy NETCONF client sends a number of > requests, then these subscriptions accumulate > and may use up system resources. In such a situation, subscriptions > can be terminated by terminating the suspect underlying NETCONF > sessions using the operation. > > /js > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jun 16 11:04:15 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C01633A681A; Mon, 16 Jun 2008 11:04:15 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51D993A6765 for ; Mon, 16 Jun 2008 11:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1n7SYrUDi5sA for ; Mon, 16 Jun 2008 11:04:13 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 7C5323A6840 for ; Mon, 16 Jun 2008 11:04:09 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5GI4jl19241; Mon, 16 Jun 2008 18:04:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 14:04:45 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4150B5202@zcarhxm2.corp.nortel.com> In-Reply-To: <4856A976.3060609@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation Thread-Index: AcjP2msY2Q3qhl//SJ+AOzKXm0qYzAAADx9g References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> <20080616171006.GA5003@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B4150B517C@zcarhxm2.corp.nortel.com> <4856A976.3060609@netconfcentral.com> From: "Sharon Chisholm" To: "Andy Bierman" Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi I most certainly don't want to preclude multiple subscriptions per session and the intention of the text was to not preclude this but also not assume it either. Let me use Juergen's text as the starting point to try and be a bit more clear. If a malicious or buggy NETCONF client sends a number of requests, then these subscriptions accumulate and may use up system resources. This is true both if the system is running each subscription in a separate session or is supporting multiple subscriptions on the same session. In such a situation, subscriptions can be terminated by terminating the suspect underlying NETCONF sessions using the operation. Sharon -----Original Message----- From: Andy Bierman [mailto:andy@netconfcentral.com] Sent: Monday, June 16, 2008 1:57 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: j.schoenwaelder@jacobs-university.de; netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation Sharon Chisholm wrote: > Hi > > That version works for me. > My concern is that is seems to imply From netconf-bounces@ietf.org Mon Jun 16 11:04:15 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C01633A681A; Mon, 16 Jun 2008 11:04:15 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51D993A6765 for ; Mon, 16 Jun 2008 11:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1n7SYrUDi5sA for ; Mon, 16 Jun 2008 11:04:13 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 7C5323A6840 for ; Mon, 16 Jun 2008 11:04:09 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5GI4jl19241; Mon, 16 Jun 2008 18:04:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 14:04:45 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4150B5202@zcarhxm2.corp.nortel.com> In-Reply-To: <4856A976.3060609@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation Thread-Index: AcjP2msY2Q3qhl//SJ+AOzKXm0qYzAAADx9g References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> <20080616171006.GA5003@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B4150B517C@zcarhxm2.corp.nortel.com> <4856A976.3060609@netconfcentral.com> From: "Sharon Chisholm" To: "Andy Bierman" Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi I most certainly don't want to preclude multiple subscriptions per session and the intention of the text was to not preclude this but also not assume it either. Let me use Juergen's text as the starting point to try and be a bit more clear. If a malicious or buggy NETCONF client sends a number of requests, then these subscriptions accumulate and may use up system resources. This is true both if the system is running each subscription in a separate session or is supporting multiple subscriptions on the same session. In such a situation, subscriptions can be terminated by terminating the suspect underlying NETCONF sessions using the operation. Sharon -----Original Message----- From: Andy Bierman [mailto:andy@netconfcentral.com] Sent: Monday, June 16, 2008 1:57 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: j.schoenwaelder@jacobs-university.de; netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation Sharon Chisholm wrote: > Hi > > That version works for me. > My concern is that is seems to that an agent is going to support multiple, concurrent notification subscriptions on the same session. The WG never agreed to this feature. Does this text refer to 1 subscription on each session, or N subscriptions on 1 session, or both? (A: yes ;-) In my (even recent experience), when the standard is silent on a subject, it is harder to interpret the specification incorrectly. However, when a standard is *almost* silent (i.e., partially specified) then it is very easy for people to interpret the standard incorrectly, in N different ways. It should be clear that the standard does not define what happens when a is received on a session while in notification mode already. Some vendors want to utilize this feature, and I think they should be able to experiment. Vendors who reject requests while in notification mode are also compliant to the standard. > Sharon Andy > > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, June 16, 2008 1:10 PM > To: Chisholm, Sharon (CAR:ZZ00) > Cc: netconf@ietf.org > Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: > Session Accumulation > > On Mon, Jun 16, 2008 at 07:52:51AM -0400, Sharon Chisholm wrote: > >> If a malicious or buggy NETCONF client sends a number of >> requests without ever terminating any of them, >> they will accumulate subscriptions and begin to use up system > resources. >> They do so while accumulating NETCONF sessions and when the >> underlying > >> NETCONF session is terminated, so is the Notification subscription. >> The operation should be used to terminate any suspect >> NETCONF sessions. > > I do not understand the second sentence. And who is "they" in the > first sentence? What about this wording: > > If a malicious or buggy NETCONF client sends a number of > requests, then these subscriptions accumulate > and may use up system resources. In such a situation, subscriptions > can be terminated by terminating the suspect underlying NETCONF > sessions using the operation. > > /js > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf imply that an agent is going to support multiple, concurrent notification subscriptions on the same session. The WG never agreed to this feature. Does this text refer to 1 subscription on each session, or N subscriptions on 1 session, or both? (A: yes ;-) In my (even recent experience), when the standard is silent on a subject, it is harder to interpret the specification incorrectly. However, when a standard is *almost* silent (i.e., partially specified) then it is very easy for people to interpret the standard incorrectly, in N different ways. It should be clear that the standard does not define what happens when a is received on a session while in notification mode already. Some vendors want to utilize this feature, and I think they should be able to experiment. Vendors who reject requests while in notification mode are also compliant to the standard. > Sharon Andy > > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, June 16, 2008 1:10 PM > To: Chisholm, Sharon (CAR:ZZ00) > Cc: netconf@ietf.org > Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: > Session Accumulation > > On Mon, Jun 16, 2008 at 07:52:51AM -0400, Sharon Chisholm wrote: > >> If a malicious or buggy NETCONF client sends a number of >> requests without ever terminating any of them, >> they will accumulate subscriptions and begin to use up system > resources. >> They do so while accumulating NETCONF sessions and when the >> underlying > >> NETCONF session is terminated, so is the Notification subscription. >> The operation should be used to terminate any suspect >> NETCONF sessions. > > I do not understand the second sentence. And who is "they" in the > first sentence? What about this wording: > > If a malicious or buggy NETCONF client sends a number of > requests, then these subscriptions accumulate > and may use up system resources. In such a situation, subscriptions > can be terminated by terminating the suspect underlying NETCONF > sessions using the operation. > > /js > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jun 16 11:22:13 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A211D3A6A3A; Mon, 16 Jun 2008 11:22:12 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318E128C0CF for ; Mon, 16 Jun 2008 11:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqWMD3TpXZKo for ; Mon, 16 Jun 2008 11:22:05 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 24AD73A69D3 for ; Mon, 16 Jun 2008 11:22:04 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 2CA571B80C5; Mon, 16 Jun 2008 20:22:46 +0200 (CEST) Date: Mon, 16 Jun 2008 20:22:48 +0200 (CEST) Message-Id: <20080616.202248.118888605.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4856A976.3060609@netconfcentral.com> References: <20080616171006.GA5003@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B4150B517C@zcarhxm2.corp.nortel.com> <4856A976.3060609@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > Sharon Chisholm wrote: > > Hi > > > > That version works for me. > > > > My concern is that is seems to imply that > an agent is going to support multiple, concurrent > notification subscriptions on the same session. > The WG never agreed to this feature. We agreed to NOT support multiple subscriptions per session, even if :interleave is supported. Section 6.5 says: When a is sent while another subscription is active on that session, the following error will be returned: /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jun 16 11:22:13 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A211D3A6A3A; Mon, 16 Jun 2008 11:22:12 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318E128C0CF for ; Mon, 16 Jun 2008 11:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqWMD3TpXZKo for ; Mon, 16 Jun 2008 11:22:05 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 24AD73A69D3 for ; Mon, 16 Jun 2008 11:22:04 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 2CA571B80C5; Mon, 16 Jun 2008 20:22:46 +0200 (CEST) Date: Mon, 16 Jun 2008 20:22:48 +0200 (CEST) Message-Id: <20080616.202248.118888605.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4856A976.3060609@netconfcentral.com> References: <20080616171006.GA5003@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B4150B517C@zcarhxm2.corp.nortel.com> <4856A976.3060609@netconfcentral.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > Sharon Chisholm wrote: > > Hi > > > > That version works for me. > > > > My concern is that is seems to imply that > an agent is going to support multiple, concurrent > notification subscriptions on the same session. > The WG never agreed to this feature. We agreed to NOT support multiple subscriptions per session, even if :interleave is supported. Section 6.5 says: When a is sent while another subscription is active on that session, the following error will be returned: /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jun 16 11:37:39 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8403A6816; Mon, 16 Jun 2008 11:37:39 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0E003A6816 for ; Mon, 16 Jun 2008 11:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPMNN96gairR for ; Mon, 16 Jun 2008 11:37:38 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 0A3413A67DF for ; Mon, 16 Jun 2008 11:37:37 -0700 (PDT) Received: (qmail 61306 invoked from network); 16 Jun 2008 18:38:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.84.44 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 16 Jun 2008 18:38:14 -0000 X-YMail-OSG: .DWYN1QVM1mu.pDa8Z7MLlwb78Ho1gb0mcrMhsy_9Ghq7GqqLp_I6LBJfRfaPoaBcrkssDmWaeESyaQG3pFx5n2Q9wIJcgKsrNbElV3AoreXFgxTrbtt8ewWfui7c4J_bgM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4856B314.80203@netconfcentral.com> Date: Mon, 16 Jun 2008 11:38:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <20080616171006.GA5003@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B4150B517C@zcarhxm2.corp.nortel.com> <4856A976.3060609@netconfcentral.com> <20080616.202248.118888605.mbj@tail-f.com> In-Reply-To: <20080616.202248.118888605.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Sharon Chisholm wrote: >>> Hi >>> >>> That version works for me. >>> >> My concern is that is seems to imply that >> an agent is going to support multiple, concurrent >> notification subscriptions on the same session. >> The WG never agreed to this feature. > > We agreed to NOT support multiple subscriptions per session, even if > :interleave is supported. Section 6.5 says: > > When a is sent while another subscription is > active on that session, the following error will be returned: > After I sent my mail, I remembered that you really objected to multiple s. I think there was discussion wrt/ adding back the subscription-id and this was rejected, so there was no way to tell multiple subscriptions on the same session apart. So the text you cited was added to the draft. However, a vendor could (and should) use their own RPC method with explicit semantics, rather than hack the RPC in non-standard ways. The new text in question should clearly refer to new sessions, since N subscriptions per session iFrom netconf-bounces@ietf.org Mon Jun 16 11:37:39 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8403A6816; Mon, 16 Jun 2008 11:37:39 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0E003A6816 for ; Mon, 16 Jun 2008 11:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPMNN96gairR for ; Mon, 16 Jun 2008 11:37:38 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 0A3413A67DF for ; Mon, 16 Jun 2008 11:37:37 -0700 (PDT) Received: (qmail 61306 invoked from network); 16 Jun 2008 18:38:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.84.44 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 16 Jun 2008 18:38:14 -0000 X-YMail-OSG: .DWYN1QVM1mu.pDa8Z7MLlwb78Ho1gb0mcrMhsy_9Ghq7GqqLp_I6LBJfRfaPoaBcrkssDmWaeESyaQG3pFx5n2Q9wIJcgKsrNbElV3AoreXFgxTrbtt8ewWfui7c4J_bgM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4856B314.80203@netconfcentral.com> Date: Mon, 16 Jun 2008 11:38:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Martin Bjorklund References: <20080616171006.GA5003@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B4150B517C@zcarhxm2.corp.nortel.com> <4856A976.3060609@netconfcentral.com> <20080616.202248.118888605.mbj@tail-f.com> In-Reply-To: <20080616.202248.118888605.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Sharon Chisholm wrote: >>> Hi >>> >>> That version works for me. >>> >> My concern is that is seems to imply that >> an agent is going to support multiple, concurrent >> notification subscriptions on the same session. >> The WG never agreed to this feature. > > We agreed to NOT support multiple subscriptions per session, even if > :interleave is supported. Section 6.5 says: > > When a is sent while another subscription is > active on that session, the following error will be returned: > After I sent my mail, I remembered that you really objected to multiple s. I think there was discussion wrt/ adding back the subscription-id and this was rejected, so there was no way to tell multiple subscriptions on the same session apart. So the text you cited was added to the draft. However, a vendor could (and should) use their own RPC method with explicit semantics, rather than hack the RPC in non-standard ways. The new text in question should clearly refer to new sessions, since N subscriptions per session is not s not supported via the standard operation. > > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf supported via the standard operation. > > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jun 16 17:00:19 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F2EA28C158; Mon, 16 Jun 2008 17:00:19 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DBFC28C14F for ; Mon, 16 Jun 2008 17:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHJ6yr7628ZW for ; Mon, 16 Jun 2008 17:00:17 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 050F428C107 for ; Mon, 16 Jun 2008 17:00:16 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id ejK81Z03d0FhH24AA0B100; Tue, 17 Jun 2008 00:00:58 +0000 Received: from Harrington73653 ([222.128.247.45]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id eo0i1Z0060zWLri8Uo0mcm; Tue, 17 Jun 2008 00:00:56 +0000 X-Authority-Analysis: v=1.0 c=1 a=lbo_UvzQrZUA:10 a=DOMOX0ymGwQA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=om3CfMMxNhsH57ldcZEA:9 a=J7aFCoZBYrDytPJn608A:7 a=u-sYejYS-RPGMrPl1Of-BZSdyJ4A:4 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=lZB815dzVvQA:10 a=gi0PWCVxevcA:10 From: "David B Harrington" To: , "'Sharon Chisholm'" References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> <20080616171006.GA5003@elstar.local> Date: Tue, 17 Jun 2008 08:00:41 +0800 Message-ID: <00fd01c8d00d$36de4df0$0cf780de@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjP0982cvMla6CeS4a4d98G9rTBdQAOUVFQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: <20080616171006.GA5003@elstar.local> Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit ofDiscuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I like this proposed text much better. dbh > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, June 17, 2008 1:10 AM > To: Sharon Chisholm > Cc: netconf@ietf.org > Subject: Re: [Netconf] Netconf Notification: One last bit > ofDiscuss: Session Accumulation > > On Mon, Jun 16, 2008 at 07:52:51AM -0400, Sharon Chisholm wrote: > > > If a malicious or buggy NETCONF client sends a number of > > requests without ever terminating > any of them, > > they will accumulate subscriptions and begin to use up > system resources. > > They do so while accumulating NETCONF sessions and when the > underlying > > NETCONF session is terminated, so is the Notification > subscription. The > > operation should be used to terminate any > suspect NETCONF > > sessions. > > I do nFrom netconf-bounces@ietf.org Mon Jun 16 17:00:19 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F2EA28C158; Mon, 16 Jun 2008 17:00:19 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DBFC28C14F for ; Mon, 16 Jun 2008 17:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHJ6yr7628ZW for ; Mon, 16 Jun 2008 17:00:17 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 050F428C107 for ; Mon, 16 Jun 2008 17:00:16 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id ejK81Z03d0FhH24AA0B100; Tue, 17 Jun 2008 00:00:58 +0000 Received: from Harrington73653 ([222.128.247.45]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id eo0i1Z0060zWLri8Uo0mcm; Tue, 17 Jun 2008 00:00:56 +0000 X-Authority-Analysis: v=1.0 c=1 a=lbo_UvzQrZUA:10 a=DOMOX0ymGwQA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=om3CfMMxNhsH57ldcZEA:9 a=J7aFCoZBYrDytPJn608A:7 a=u-sYejYS-RPGMrPl1Of-BZSdyJ4A:4 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=lZB815dzVvQA:10 a=gi0PWCVxevcA:10 From: "David B Harrington" To: , "'Sharon Chisholm'" References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com> <20080616171006.GA5003@elstar.local> Date: Tue, 17 Jun 2008 08:00:41 +0800 Message-ID: <00fd01c8d00d$36de4df0$0cf780de@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjP0982cvMla6CeS4a4d98G9rTBdQAOUVFQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: <20080616171006.GA5003@elstar.local> Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit ofDiscuss: Session Accumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I like this proposed text much better. dbh > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, June 17, 2008 1:10 AM > To: Sharon Chisholm > Cc: netconf@ietf.org > Subject: Re: [Netconf] Netconf Notification: One last bit > ofDiscuss: Session Accumulation > > On Mon, Jun 16, 2008 at 07:52:51AM -0400, Sharon Chisholm wrote: > > > If a malicious or buggy NETCONF client sends a number of > > requests without ever terminating > any of them, > > they will accumulate subscriptions and begin to use up > system resources. > > They do so while accumulating NETCONF sessions and when the > underlying > > NETCONF session is terminated, so is the Notification > subscription. The > > operation should be used to terminate any > suspect NETCONF > > sessions. > > I do not undot understand the second sentence. And who is "they" in the > first sentence? What about this wording: > > If a malicious or buggy NETCONF client sends a number of > requests, then these subscriptions accumulate > and may use up system resources. In such a situation, subscriptions > can be terminated by terminating the suspect underlying NETCONF > sessions using the operation. > > /js > > -- > 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 > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf erstand the second sentence. And who is "they" in the > first sentence? What about this wording: > > If a malicious or buggy NETCONF client sends a number of > requests, then these subscriptions accumulate > and may use up system resources. In such a situation, subscriptions > can be terminated by terminating the suspect underlying NETCONF > sessions using the operation. > > /js > > -- > 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 > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jun 16 23:36:42 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 934393A69EE; Mon, 16 Jun 2008 23:36:42 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F48828C122 for ; Mon, 16 Jun 2008 23:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.742 X-Spam-Level: X-Spam-Status: No, score=-3.742 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCNoaulFKORK for ; Mon, 16 Jun 2008 23:36:39 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 4A86C3A6853 for ; Mon, 16 Jun 2008 23:36:39 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m5H6b5kn013760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jun 2008 08:37:05 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5H6awh1010077; Tue, 17 Jun 2008 08:36:58 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Jun 2008 08:36:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 17 Jun 2008 08:36:52 +0200 Message-ID: In-Reply-To: <00fd01c8d00d$36de4df0$0cf780de@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Netconf Notification: One last bit ofDiscuss: SessionAccumulation Thread-Index: AcjP0982cvMla6CeS4a4d98G9rTBdQAOUVFQAA28ubA= References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com><20080616171006.GA5003@elstar.local> <00fd01c8d00d$36de4df0$0cf780de@china.huawei.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext David B Harrington" , , "Sharon Chisholm" X-OriginalArrivalTime: 17 Jun 2008 06:36:53.0023 (UTC) FILETIME=[8787B2F0:01C8D044] Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit ofDiscuss: SessionAccumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I like the proposed text too. This looks like a consensus. If anybody disagrees to use it please propose a concrete text. Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext David B Harrington > Sent: Tuesday, June 17, 2008 2:01 AM > To: j.schoenwaelder@jacobs-university.de; 'Sharon Chisholm' > Cc: netconf@ietf.org > Subject: Re: [Netconf] Netconf Notification: One last bit > ofDiscuss: SessionAccumulation > > I like this proposed text much better. > > dbh > > > -----Original MFrom netconf-bounces@ietf.org Mon Jun 16 23:36:42 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 934393A69EE; Mon, 16 Jun 2008 23:36:42 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F48828C122 for ; Mon, 16 Jun 2008 23:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.742 X-Spam-Level: X-Spam-Status: No, score=-3.742 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCNoaulFKORK for ; Mon, 16 Jun 2008 23:36:39 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 4A86C3A6853 for ; Mon, 16 Jun 2008 23:36:39 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m5H6b5kn013760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jun 2008 08:37:05 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5H6awh1010077; Tue, 17 Jun 2008 08:36:58 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Jun 2008 08:36:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 17 Jun 2008 08:36:52 +0200 Message-ID: In-Reply-To: <00fd01c8d00d$36de4df0$0cf780de@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Netconf Notification: One last bit ofDiscuss: SessionAccumulation Thread-Index: AcjP0982cvMla6CeS4a4d98G9rTBdQAOUVFQAA28ubA= References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com><20080616171006.GA5003@elstar.local> <00fd01c8d00d$36de4df0$0cf780de@china.huawei.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext David B Harrington" , , "Sharon Chisholm" X-OriginalArrivalTime: 17 Jun 2008 06:36:53.0023 (UTC) FILETIME=[8787B2F0:01C8D044] Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit ofDiscuss: SessionAccumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I like the proposed text too. This looks like a consensus. If anybody disagrees to use it please propose a concrete text. Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext David B Harrington > Sent: Tuesday, June 17, 2008 2:01 AM > To: j.schoenwaelder@jacobs-university.de; 'Sharon Chisholm' > Cc: netconf@ietf.org > Subject: Re: [Netconf] Netconf Notification: One last bit > ofDiscuss: SessionAccumulation > > I like this proposed text much better. > > dbh > > > -----Origessage----- > > From: netconf-bounces@ietf.org > > [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > > Sent: Tuesday, June 17, 2008 1:10 AM > > To: Sharon Chisholm > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] Netconf Notification: One last bit > > ofDiscuss: Session Accumulation > > > > On Mon, Jun 16, 2008 at 07:52:51AM -0400, Sharon Chisholm wrote: > > > > > If a malicious or buggy NETCONF client sends a number of > > > requests without ever terminating > > any of them, > > > they will accumulate subscriptions and begin to use up > > system resources. > > > They do so while accumulating NETCONF sessions and when the > > underlying > > > NETCONF session is terminated, so is the Notification > > subscription. The > > > operation should be used to terminate any > > suspect NETCONF > > > sessions. > > > > I do not understand the second sentence. And who is "they" in the > > first sentence? What about this wording: > > > > If a malicious or buggy NETCONF client sends a number of > > requests, then these subscriptions > accumulate > > and may use up system resources. In such a situation, > subscriptions > > can be terminated by terminating the suspect underlying NETCONF > > sessions using the operation. > > > > /js > > > > -- > > 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 > > > > _______________________________________________ > 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 inal Message----- > > From: netconf-bounces@ietf.org > > [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > > Sent: Tuesday, June 17, 2008 1:10 AM > > To: Sharon Chisholm > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] Netconf Notification: One last bit > > ofDiscuss: Session Accumulation > > > > On Mon, Jun 16, 2008 at 07:52:51AM -0400, Sharon Chisholm wrote: > > > > > If a malicious or buggy NETCONF client sends a number of > > > requests without ever terminating > > any of them, > > > they will accumulate subscriptions and begin to use up > > system resources. > > > They do so while accumulating NETCONF sessions and when the > > underlying > > > NETCONF session is terminated, so is the Notification > > subscription. The > > > operation should be used to terminate any > > suspect NETCONF > > > sessions. > > > > I do not understand the second sentence. And who is "they" in the > > first sentence? What about this wording: > > > > If a malicious or buggy NETCONF client sends a number of > > requests, then these subscriptions > accumulate > > and may use up system resources. In such a situation, > subscriptions > > can be terminated by terminating the suspect underlying NETCONF > > sessions using the operation. > > > > /js > > > > -- > > 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 > > > > _______________________________________________ > 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 netconf-bounces@ietf.org Tue Jun 17 10:01:47 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D478E3A6A79; Tue, 17 Jun 2008 10:01:47 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFDB63A69B2 for ; Tue, 17 Jun 2008 10:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8hTeSxXjO+T for ; Tue, 17 Jun 2008 10:01:44 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 8E3643A6989 for ; Tue, 17 Jun 2008 10:01:44 -0700 (PDT) Received: (qmail 50616 invoked from network); 17 Jun 2008 17:02:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.84.44 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 17 Jun 2008 17:02:28 -0000 X-YMail-OSG: Cjdda8gVM1kMjINiSsNbhUA_49FmWjzteDjfOT_qIgxvVt2K5voxvjgPLMO65tQm5EiRd.rnqG1agM26Tfxlb0pbM5h_f5WhPJ4el1o6rTwCw8ndhJVu84o_HBB404gcS4oGA9y1VBb7MYf7FHZolp7t X-Yahoo-Newman-Property: ymail-3 Message-ID: <4857EE21.9050406@netconfcentral.com> Date: Tue, 17 Jun 2008 10:02:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Muenich)" References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com><20080616171006.GA5003@elstar.local> <00fd01c8d00d$36de4df0$0cf780de@china.huawei.com> In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit ofDiscuss: SessionAccumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Ersue, Mehmet (NSN - DE/Muenich) wrote: > I like the proposed text too. > > This looks like a consensus. If anybody disagrees to > use it please propose a concrete text. > The new text from Juergen is fine, now that Martin pointed out that the text cannot possibly be interpreted to mean multiple subscriptions on 1 session. I think the new text suggests the opposite, but the text in 6.5 clearly says otherwise (in case it comes up in the future that the standard is ambiguous wrt/ multiple subscriptions per session). > Mehmet Andy > > >> -----Original Message----- >> From: netconf-bounces@ietf.org >> [mailto:netconf-bounces@ietf.org] On Behalf Of ext David B Harrington >> Sent: Tuesday, June 17, 2008 2:01 AM >> To: j.schoenwaelder@jacobs-university.de; 'Sharon Chisholm' >> Cc: netconf@ietf.org >> Subject: Re: [Netconf] Netconf Notification: One last bit >> ofDiscuss: SessionAccumulation >> >> I like this proposed text much better. >> >> dbh >> >>> -----Original Message----- >>> From: netconf-bounces@ietf.org >>> [mailto:netconf-bounces@ietfFrom netconf-bounces@ietf.org Tue Jun 17 10:01:47 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D478E3A6A79; Tue, 17 Jun 2008 10:01:47 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFDB63A69B2 for ; Tue, 17 Jun 2008 10:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8hTeSxXjO+T for ; Tue, 17 Jun 2008 10:01:44 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 8E3643A6989 for ; Tue, 17 Jun 2008 10:01:44 -0700 (PDT) Received: (qmail 50616 invoked from network); 17 Jun 2008 17:02:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.84.44 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 17 Jun 2008 17:02:28 -0000 X-YMail-OSG: Cjdda8gVM1kMjINiSsNbhUA_49FmWjzteDjfOT_qIgxvVt2K5voxvjgPLMO65tQm5EiRd.rnqG1agM26Tfxlb0pbM5h_f5WhPJ4el1o6rTwCw8ndhJVu84o_HBB404gcS4oGA9y1VBb7MYf7FHZolp7t X-Yahoo-Newman-Property: ymail-3 Message-ID: <4857EE21.9050406@netconfcentral.com> Date: Tue, 17 Jun 2008 10:02:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Muenich)" References: <713043CE8B8E1348AF3C546DBE02C1B4150B48B3@zcarhxm2.corp.nortel.com><20080616171006.GA5003@elstar.local> <00fd01c8d00d$36de4df0$0cf780de@china.huawei.com> In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: One last bit ofDiscuss: SessionAccumulation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Ersue, Mehmet (NSN - DE/Muenich) wrote: > I like the proposed text too. > > This looks like a consensus. If anybody disagrees to > use it please propose a concrete text. > The new text from Juergen is fine, now that Martin pointed out that the text cannot possibly be interpreted to mean multiple subscriptions on 1 session. I think the new text suggests the opposite, but the text in 6.5 clearly says otherwise (in case it comes up in the future that the standard is ambiguous wrt/ multiple subscriptions per session). > Mehmet Andy > > >> -----Original Message----- >> From: netconf-bounces@ietf.org >> [mailto:netconf-bounces@ietf.org] On Behalf Of ext David B Harrington >> Sent: Tuesday, June 17, 2008 2:01 AM >> To: j.schoenwaelder@jacobs-university.de; 'Sharon Chisholm' >> Cc: netconf@ietf.org >> Subject: Re: [Netconf] Netconf Notification: One last bit >> ofDiscuss: SessionAccumulation >> >> I like this proposed text much better. >> >> dbh >> >>> -----Original Message----- >>> From: netconf-bounces@ietf.org >>> [mailto:netconf-bounce.org] On Behalf Of Juergen Schoenwaelder >>> Sent: Tuesday, June 17, 2008 1:10 AM >>> To: Sharon Chisholm >>> Cc: netconf@ietf.org >>> Subject: Re: [Netconf] Netconf Notification: One last bit >>> ofDiscuss: Session Accumulation >>> >>> On Mon, Jun 16, 2008 at 07:52:51AM -0400, Sharon Chisholm wrote: >>> >>>> If a malicious or buggy NETCONF client sends a number of >>>> requests without ever terminating >>> any of them, >>>> they will accumulate subscriptions and begin to use up >>> system resources. >>>> They do so while accumulating NETCONF sessions and when the >>> underlying >>>> NETCONF session is terminated, so is the Notification >>> subscription. The >>>> operation should be used to terminate any >>> suspect NETCONF >>>> sessions. >>> I do not understand the second sentence. And who is "they" in the >>> first sentence? What about this wording: >>> >>> If a malicious or buggy NETCONF client sends a number of >>> requests, then these subscriptions >> accumulate >>> and may use up system resources. In such a situation, >> subscriptions >>> can be terminated by terminating the suspect underlying NETCONF >>> sessions using the operation. >>> >>> /js >>> >>> -- >>> 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 >>> >> _______________________________________________ >> 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 s@ietf.org] On Behalf Of Juergen Schoenwaelder >>> Sent: Tuesday, June 17, 2008 1:10 AM >>> To: Sharon Chisholm >>> Cc: netconf@ietf.org >>> Subject: Re: [Netconf] Netconf Notification: One last bit >>> ofDiscuss: Session Accumulation >>> >>> On Mon, Jun 16, 2008 at 07:52:51AM -0400, Sharon Chisholm wrote: >>> >>>> If a malicious or buggy NETCONF client sends a number of >>>> requests without ever terminating >>> any of them, >>>> they will accumulate subscriptions and begin to use up >>> system resources. >>>> They do so while accumulating NETCONF sessions and when the >>> underlying >>>> NETCONF session is terminated, so is the Notification >>> subscription. The >>>> operation should be used to terminate any >>> suspect NETCONF >>>> sessions. >>> I do not understand the second sentence. And who is "they" in the >>> first sentence? What about this wording: >>> >>> If a malicious or buggy NETCONF client sends a number of >>> requests, then these subscriptions >> accumulate >>> and may use up system resources. In such a situation, >> subscriptions >>> can be terminated by terminating the suspect underlying NETCONF >>> sessions using the operation. >>> >>> /js >>> >>> -- >>> 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 >>> >> _______________________________________________ >> 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 netconf-bounces@ietf.org Thu Jun 19 08:17:38 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A3C73A6AEE; Thu, 19 Jun 2008 08:17:38 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC83A3A6A6C for ; Thu, 19 Jun 2008 08:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DDo8oVtMRdI for ; Thu, 19 Jun 2008 08:17:36 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 0B6923A68DC for ; Thu, 19 Jun 2008 08:17:36 -0700 (PDT) Received: (qmail 9901 invoked from network); 19 Jun 2008 15:18:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.84.44 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 19 Jun 2008 15:18:19 -0000 X-YMail-OSG: 3yzXrogVM1kNe_Le06XzirGlDkNRg4gtcX.mwJV6ikufE6d0Q2PKSSsWdTHy7EnBsQt_AsLMQYs9mzT0baudN1aqSYQusB4I2.BFeVNvMdIa6UFMebeyHuCm_fHQigOe20o- X-Yahoo-Newman-Property: ymail-3 Message-ID: <485A78B9.9090702@netconfcentral.com> Date: Thu, 19 Jun 2008 08:18:17 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: RFC Editor Cc: NETCONF Subject: [Netconf] new RFC 4741 errata X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Please add an errata attachment to RFC 4741 for the following bug (the parameters are in the wrong order): page 61, para 3: OLD: NEW: (I don't know why none of us caught this bug before. A wrong example is worse than no example at all ;-) The XSD and the example on page 40 are correct. thanks, Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 19 08:17:38 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A3C73A6AEE; Thu, 19 Jun 2008 08:17:38 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC83A3A6A6C for ; Thu, 19 Jun 2008 08:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DDo8oVtMRdI for ; Thu, 19 Jun 2008 08:17:36 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 0B6923A68DC for ; Thu, 19 Jun 2008 08:17:36 -0700 (PDT) Received: (qmail 9901 invoked from network); 19 Jun 2008 15:18:21 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.84.44 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 19 Jun 2008 15:18:19 -0000 X-YMail-OSG: 3yzXrogVM1kNe_Le06XzirGlDkNRg4gtcX.mwJV6ikufE6d0Q2PKSSsWdTHy7EnBsQt_AsLMQYs9mzT0baudN1aqSYQusB4I2.BFeVNvMdIa6UFMebeyHuCm_fHQigOe20o- X-Yahoo-Newman-Property: ymail-3 Message-ID: <485A78B9.9090702@netconfcentral.com> Date: Thu, 19 Jun 2008 08:18:17 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: RFC Editor Cc: NETCONF Subject: [Netconf] new RFC 4741 errata X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Please add an errata attachment to RFC 4741 for the following bug (the parameters are in the wrong order): page 61, para 3: OLD: NEW: (I don't know why none of us caught this bug before. A wrong example is worse than no example at all ;-) The XSD and the example on page 40 are correct. thanks, Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 19 09:41:54 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D9A3A6881; Thu, 19 Jun 2008 09:41:54 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB20C3A6881 for ; Thu, 19 Jun 2008 09:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEnFj50tjjKj for ; Thu, 19 Jun 2008 09:41:51 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id CB3273A682A for ; Thu, 19 Jun 2008 09:41:51 -0700 (PDT) Received: (qmail 86820 invoked from network); 19 Jun 2008 16:42:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.84.44 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 19 Jun 2008 16:42:38 -0000 X-YMail-OSG: zvU07rMVM1lBG7K0b4_gLkZptHPBPM9iRcfaC9D_2jFTC9H8XafGmYTZqeTFryNKr2Mant9xBaEljtnaojmZ0wZN8LkkAw0AsYMpSQ8_7ey7qbKj11Q_ZLZFDbzEszQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <485A8C7B.6030100@netconfcentral.com> Date: Thu, 19 Jun 2008 09:42:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Alice Hagens References: <485A78B9.9090702@netconfcentral.com> <2374ABD7-BB19-4A06-94E5-F7DAD0318EEA@isi.edu> In-Reply-To: <2374ABD7-BB19-4A06-94E5-F7DAD0318EEA@isi.edu> Cc: NETCONF , RFC Editor Subject: Re: [Netconf] new RFC 4741 errata X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Alice Hagens wrote: > Andy, > > Please post this using the errata page (under "Report New Errata"): > http://www.rfc-editor.org/errata.php > > Thank you. > done. sorry I didn't know about the new WEB form to report errata. very nice. > RFC Editor/ah Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 19 09:41:54 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D9A3A6881; Thu, 19 Jun 2008 09:41:54 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB20C3A6881 for ; Thu, 19 Jun 2008 09:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEnFj50tjjKj for ; Thu, 19 Jun 2008 09:41:51 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id CB3273A682A for ; Thu, 19 Jun 2008 09:41:51 -0700 (PDT) Received: (qmail 86820 invoked from network); 19 Jun 2008 16:42:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.84.44 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 19 Jun 2008 16:42:38 -0000 X-YMail-OSG: zvU07rMVM1lBG7K0b4_gLkZptHPBPM9iRcfaC9D_2jFTC9H8XafGmYTZqeTFryNKr2Mant9xBaEljtnaojmZ0wZN8LkkAw0AsYMpSQ8_7ey7qbKj11Q_ZLZFDbzEszQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <485A8C7B.6030100@netconfcentral.com> Date: Thu, 19 Jun 2008 09:42:35 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Alice Hagens References: <485A78B9.9090702@netconfcentral.com> <2374ABD7-BB19-4A06-94E5-F7DAD0318EEA@isi.edu> In-Reply-To: <2374ABD7-BB19-4A06-94E5-F7DAD0318EEA@isi.edu> Cc: NETCONF , RFC Editor Subject: Re: [Netconf] new RFC 4741 errata X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Alice Hagens wrote: > Andy, > > Please post this using the errata page (under "Report New Errata"): > http://www.rfc-editor.org/errata.php > > Thank you. > done. sorry I didn't know about the new WEB form to report errata. very nice. > RFC Editor/ah Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 19 11:59:28 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 277D63A692F; Thu, 19 Jun 2008 11:59:28 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDCAE3A685C for ; Thu, 19 Jun 2008 09:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDtpTL1IzygV for ; Thu, 19 Jun 2008 09:11:21 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id F268F3A66B4 for ; Thu, 19 Jun 2008 09:11:20 -0700 (PDT) Received: from [128.9.168.202] (rfc2.isi.edu [128.9.168.202]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m5JGBtbF018531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Jun 2008 09:11:57 -0700 (PDT) In-Reply-To: <485A78B9.9090702@netconfcentral.com> References: <485A78B9.9090702@netconfcentral.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <2374ABD7-BB19-4A06-94E5-F7DAD0318EEA@isi.edu> From: Alice Hagens Date: Thu, 19 Jun 2008 09:11:55 -0700 To: Andy Bierman X-Mailer: Apple Mail (2.753.1) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: hagens@isi.edu X-Mailman-Approved-At: Thu, 19 Jun 2008 11:59:26 -0700 Cc: NETCONF , RFC Editor Subject: Re: [Netconf] new RFC 4741 errata X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy, Please post this using the errata page (under "Report New Errata"): http://www.rfc-editor.org/errata.php Thank you. RFC Editor/ah On Jun 19, 2008, at 8:18 AM, Andy Bierman wrote: > Hi, > > Please add an errata attachment to RFC 4741 for the > following bug (the parameters are in the wrong order): > > page 61, para 3: > > OLD: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > > > NEW: > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > > > (I don't know why none of us caught this bug before. > A wrong example is worse than no example at all ;-) > The XSD and the example on page 40 are correct. > > > thanks, > Andy > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 19 11:59:28 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 277D63A692F; Thu, 19 Jun 2008 11:59:28 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDCAE3A685C for ; Thu, 19 Jun 2008 09:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDtpTL1IzygV for ; Thu, 19 Jun 2008 09:11:21 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id F268F3A66B4 for ; Thu, 19 Jun 2008 09:11:20 -0700 (PDT) Received: from [128.9.168.202] (rfc2.isi.edu [128.9.168.202]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m5JGBtbF018531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Jun 2008 09:11:57 -0700 (PDT) In-Reply-To: <485A78B9.9090702@netconfcentral.com> References: <485A78B9.9090702@netconfcentral.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <2374ABD7-BB19-4A06-94E5-F7DAD0318EEA@isi.edu> From: Alice Hagens Date: Thu, 19 Jun 2008 09:11:55 -0700 To: Andy Bierman X-Mailer: Apple Mail (2.753.1) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: hagens@isi.edu X-Mailman-Approved-At: Thu, 19 Jun 2008 11:59:26 -0700 Cc: NETCONF , RFC Editor Subject: Re: [Netconf] new RFC 4741 errata X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy, Please post this using the errata page (under "Report New Errata"): http://www.rfc-editor.org/errata.php Thank you. RFC Editor/ah On Jun 19, 2008, at 8:18 AM, Andy Bierman wrote: > Hi, > > Please add an errata attachment to RFC 4741 for the > following bug (the parameters are in the wrong order): > > page 61, para 3: > > OLD: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > > > NEW: > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > > > (I don't know why none of us caught this bug before. > A wrong example is worse than no example at all ;-) > The XSD and the example on page 40 are correct. > > > thanks, > Andy > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jun 20 07:02:57 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0FA3A69F9; Fri, 20 Jun 2008 07:02:57 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 757F428C146 for ; Fri, 20 Jun 2008 07:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvR+XERxpemr for ; Fri, 20 Jun 2008 07:02:54 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 2E0A43A6A6B for ; Fri, 20 Jun 2008 07:02:54 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5KE2q708002 for ; Fri, 20 Jun 2008 14:02:52 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Jun 2008 10:02:42 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4151EF4C9@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IANA netconf.xsd not right version Thread-Index: AcjS3k77RuWceTl+QHabXpRU1+ULPg== From: "Sharon Chisholm" To: Subject: [Netconf] IANA netconf.xsd not right version X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi The version of the netconf.xsd file at http://www.iana.org/assignments/xml-registry/schema/netconf.xsd contains the old definition of filterInlineType that uses a restriction instead of an extension. What's the best way to get that updated? Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jun 20 07:02:57 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0FA3A69F9; Fri, 20 Jun 2008 07:02:57 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 757F428C146 for ; Fri, 20 Jun 2008 07:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvR+XERxpemr for ; Fri, 20 Jun 2008 07:02:54 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 2E0A43A6A6B for ; Fri, 20 Jun 2008 07:02:54 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5KE2q708002 for ; Fri, 20 Jun 2008 14:02:52 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Jun 2008 10:02:42 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4151EF4C9@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IANA netconf.xsd not right version Thread-Index: AcjS3k77RuWceTl+QHabXpRU1+ULPg== From: "Sharon Chisholm" To: Subject: [Netconf] IANA netconf.xsd not right version X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi The version of the netconf.xsd file at http://www.iana.org/assignments/xml-registry/schema/netconf.xsd contains the old definition of filterInlineType that uses a restriction instead of an extension. What's the best way to get that updated? Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Jun 22 10:02:24 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B12B13A692C; Sun, 22 Jun 2008 10:02:24 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4C83A69BD for ; Sun, 22 Jun 2008 10:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FSFvJXRLYzO for ; Sun, 22 Jun 2008 10:02:22 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id D524B3A692C for ; Sun, 22 Jun 2008 10:02:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,685,1204520400"; d="scan'208";a="124384241" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 22 Jun 2008 13:02:27 -0400 X-IronPort-AV: E=Sophos;i="4.27,685,1204520400"; d="scan'208";a="222176633" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Jun 2008 13:02:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 22 Jun 2008 19:02:24 +0200 Message-ID: In-Reply-To: <20080618194152.70E183A67FB@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Protocol Action: 'NETCONF Event Notifications' to Proposed Standard Thread-Index: AcjRe6HE+QNL26Z0S9a8xO7VTImPKgDDfkaA References: <20080618194152.70E183A67FB@core3.amsl.com> From: "Romascanu, Dan (Dan)" Cc: "netconf mailing list" Subject: Re: [Netconf] Protocol Action: 'NETCONF Event Notifications' to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Congratulations to the editors, chairs (current and past) and to the whole WG for completing this milestone. Dan > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG > Sent: Wednesday, June 18, 2008 10:42 PM > To: IETF-Announce > Cc: Internet Architecture Board; netconf mailing list; > netconf chair; RFC Editor > Subject: Protocol Action: 'NETCONF Event Notifications' to > Proposed Standard > > The IESG has approved the following document: > > - 'NETCONF Event Notifications ' > as a Proposed Standard > > This document is the product of the Network Configuration > Working Group. > > The IESG contact persons are Dan Romascanu and Ron Bonica. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-notific > ation-14.txt > > Technical Summary > > This document defines mechanisms that provide an > asynchronous message > notificatioFrom netconf-bounces@ietf.org Sun Jun 22 10:02:24 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B12B13A692C; Sun, 22 Jun 2008 10:02:24 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4C83A69BD for ; Sun, 22 Jun 2008 10:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FSFvJXRLYzO for ; Sun, 22 Jun 2008 10:02:22 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id D524B3A692C for ; Sun, 22 Jun 2008 10:02:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,685,1204520400"; d="scan'208";a="124384241" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 22 Jun 2008 13:02:27 -0400 X-IronPort-AV: E=Sophos;i="4.27,685,1204520400"; d="scan'208";a="222176633" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Jun 2008 13:02:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 22 Jun 2008 19:02:24 +0200 Message-ID: In-Reply-To: <20080618194152.70E183A67FB@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Protocol Action: 'NETCONF Event Notifications' to Proposed Standard Thread-Index: AcjRe6HE+QNL26Z0S9a8xO7VTImPKgDDfkaA References: <20080618194152.70E183A67FB@core3.amsl.com> From: "Romascanu, Dan (Dan)" Cc: "netconf mailing list" Subject: Re: [Netconf] Protocol Action: 'NETCONF Event Notifications' to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Congratulations to the editors, chairs (current and past) and to the whole WG for completing this milestone. Dan > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG > Sent: Wednesday, June 18, 2008 10:42 PM > To: IETF-Announce > Cc: Internet Architecture Board; netconf mailing list; > netconf chair; RFC Editor > Subject: Protocol Action: 'NETCONF Event Notifications' to > Proposed Standard > > The IESG has approved the following document: > > - 'NETCONF Event Notifications ' > as a Proposed Standard > > This document is the product of the Network Configuration > Working Group. > > The IESG contact persons are Dan Romascanu and Ron Bonica. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-notific > ation-14.txt > > Technical Summary > > This document defines mechanisms that provide an > asynchronous message > notifn delivery service for the NETCONF protocol. This is an > optional capability built on top of the base NETCONF definition. > This document defines the capabilities and operations necessary to > support this service. > > Working Group Summary > > This document completes the initial charter of the NETCONF > WG. It was > > longly debated and discussed in the Working Group, > including two Last > Calls. The current version reflects the consensus of the Working > Group. > > Document Quality > > There are several implementations of NETCONF which > implement or plan > > to implement the notifications option. Suresh Krishnan > reviewed the > document for the Gen-ART team. > > Personnel > > Bert Wijnen is the document shepherd and Dan Romascanu is the > responsible Area Director. > > RFC Editor Note > > Please add at the end of Section 7 - Security Considerations the > following: > > If a malicious or buggy NETCONF client sends a number of > requests, then these subscriptions accumulate > and may use up system resources. In such a situation, subscriptions > can be terminated by terminating the suspect underlying NETCONF > sessions using the operation. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ication delivery service for the NETCONF protocol. This is an > optional capability built on top of the base NETCONF definition. > This document defines the capabilities and operations necessary to > support this service. > > Working Group Summary > > This document completes the initial charter of the NETCONF > WG. It was > > longly debated and discussed in the Working Group, > including two Last > Calls. The current version reflects the consensus of the Working > Group. > > Document Quality > > There are several implementations of NETCONF which > implement or plan > > to implement the notifications option. Suresh Krishnan > reviewed the > document for the Gen-ART team. > > Personnel > > Bert Wijnen is the document shepherd and Dan Romascanu is the > responsible Area Director. > > RFC Editor Note > > Please add at the end of Section 7 - Security Considerations the > following: > > If a malicious or buggy NETCONF client sends a number of > requests, then these subscriptions accumulate > and may use up system resources. In such a situation, subscriptions > can be terminated by terminating the suspect underlying NETCONF > sessions using the operation. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jun 25 08:32:59 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5521F3A68C2; Wed, 25 Jun 2008 08:32:59 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DFBB3A69F5 for ; Wed, 25 Jun 2008 08:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=2.900, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsH5XsgIQYW3 for ; Wed, 25 Jun 2008 08:32:57 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id E6F003A68B7 for ; Wed, 25 Jun 2008 08:32:52 -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 m5PFWoiP032315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jun 2008 17:32:50 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5PFWoO0013010; Wed, 25 Jun 2008 17:32:50 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 17:32:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 17:32:49 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Protocol Action: 'NETCONF Event Notifications' toProposed Standard Thread-Index: AcjRe6HE+QNL26Z0S9a8xO7VTImPKgDDfkaAAJOl6oA= References: <20080618194152.70E183A67FB@core3.amsl.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "netconf mailing list" X-OriginalArrivalTime: 25 Jun 2008 15:32:50.0386 (UTC) FILETIME=[BA1DE320:01C8D6D8] Subject: Re: [Netconf] Protocol Action: 'NETCONF Event Notifications' toProposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I think special thanks go to the editors and the former WG chairs, who did a tremendous work. BTW: Not to forget the document shepherd joining his vacation currently. Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Romascanu, > Dan (Dan) > Sent: Sunday, June 22, 2008 7:02 PM > Cc: netconf mailing list > Subject: Re: [Netconf] Protocol Action: 'NETCONF Event > Notifications' toProposed Standard > > Congratulations to the editors, chairs (current and past) and to the > whole WG for completing this milestone. > > Dan > > > > -----Original Message----- > > From: ietf-annouFrom netconf-bounces@ietf.org Wed Jun 25 08:32:59 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5521F3A68C2; Wed, 25 Jun 2008 08:32:59 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DFBB3A69F5 for ; Wed, 25 Jun 2008 08:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=2.900, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsH5XsgIQYW3 for ; Wed, 25 Jun 2008 08:32:57 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id E6F003A68B7 for ; Wed, 25 Jun 2008 08:32:52 -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 m5PFWoiP032315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jun 2008 17:32:50 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5PFWoO0013010; Wed, 25 Jun 2008 17:32:50 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 17:32:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 17:32:49 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Protocol Action: 'NETCONF Event Notifications' toProposed Standard Thread-Index: AcjRe6HE+QNL26Z0S9a8xO7VTImPKgDDfkaAAJOl6oA= References: <20080618194152.70E183A67FB@core3.amsl.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "netconf mailing list" X-OriginalArrivalTime: 25 Jun 2008 15:32:50.0386 (UTC) FILETIME=[BA1DE320:01C8D6D8] Subject: Re: [Netconf] Protocol Action: 'NETCONF Event Notifications' toProposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I think special thanks go to the editors and the former WG chairs, who did a tremendous work. BTW: Not to forget the document shepherd joining his vacation currently. Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Romascanu, > Dan (Dan) > Sent: Sunday, June 22, 2008 7:02 PM > Cc: netconf mailing list > Subject: Re: [Netconf] Protocol Action: 'NETCONF Event > Notifications' toProposed Standard > > Congratulations to the editors, chairs (current and past) and to the > whole WG for completing this milestone. > > Dan > > > > -----Original Message----- > > From: ietfnce-bounces@ietf.org > > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG > > Sent: Wednesday, June 18, 2008 10:42 PM > > To: IETF-Announce > > Cc: Internet Architecture Board; netconf mailing list; > > netconf chair; RFC Editor > > Subject: Protocol Action: 'NETCONF Event Notifications' to > > Proposed Standard > > > > The IESG has approved the following document: > > > > - 'NETCONF Event Notifications ' > > as a Proposed Standard > > > > This document is the product of the Network Configuration > > Working Group. > > > > The IESG contact persons are Dan Romascanu and Ron Bonica. > > > > A URL of this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-netconf-notific > > ation-14.txt > > > > Technical Summary > > > > This document defines mechanisms that provide an > > asynchronous message > > notification delivery service for the NETCONF protocol. > This is an > > optional capability built on top of the base NETCONF definition. > > This document defines the capabilities and operations > necessary to > > support this service. > > > > Working Group Summary > > > > This document completes the initial charter of the NETCONF > > WG. It was > > > > longly debated and discussed in the Working Group, > > including two Last > > Calls. The current version reflects the consensus of the Working > > Group. > > > > Document Quality > > > > There are several implementations of NETCONF which > > implement or plan > > > > to implement the notifications option. Suresh Krishnan > > reviewed the > > document for the Gen-ART team. > > > > Personnel > > > > Bert Wijnen is the document shepherd and Dan Romascanu is the > > responsible Area Director. > > > > RFC Editor Note > > > > Please add at the end of Section 7 - Security Considerations the > > following: > > > > If a malicious or buggy NETCONF client sends a number of > > requests, then these subscriptions > accumulate > > and may use up system resources. In such a situation, > subscriptions > > can be terminated by terminating the suspect underlying NETCONF > > sessions using the operation. > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce > > > _______________________________________________ > 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 -announce-bounces@ietf.org > > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG > > Sent: Wednesday, June 18, 2008 10:42 PM > > To: IETF-Announce > > Cc: Internet Architecture Board; netconf mailing list; > > netconf chair; RFC Editor > > Subject: Protocol Action: 'NETCONF Event Notifications' to > > Proposed Standard > > > > The IESG has approved the following document: > > > > - 'NETCONF Event Notifications ' > > as a Proposed Standard > > > > This document is the product of the Network Configuration > > Working Group. > > > > The IESG contact persons are Dan Romascanu and Ron Bonica. > > > > A URL of this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-netconf-notific > > ation-14.txt > > > > Technical Summary > > > > This document defines mechanisms that provide an > > asynchronous message > > notification delivery service for the NETCONF protocol. > This is an > > optional capability built on top of the base NETCONF definition. > > This document defines the capabilities and operations > necessary to > > support this service. > > > > Working Group Summary > > > > This document completes the initial charter of the NETCONF > > WG. It was > > > > longly debated and discussed in the Working Group, > > including two Last > > Calls. The current version reflects the consensus of the Working > > Group. > > > > Document Quality > > > > There are several implementations of NETCONF which > > implement or plan > > > > to implement the notifications option. Suresh Krishnan > > reviewed the > > document for the Gen-ART team. > > > > Personnel > > > > Bert Wijnen is the document shepherd and Dan Romascanu is the > > responsible Area Director. > > > > RFC Editor Note > > > > Please add at the end of Section 7 - Security Considerations the > > following: > > > > If a malicious or buggy NETCONF client sends a number of > > requests, then these subscriptions > accumulate > > and may use up system resources. In such a situation, > subscriptions > > can be terminated by terminating the suspect underlying NETCONF > > sessions using the operation. > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce > > > _______________________________________________ > 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 netconf-bounces@ietf.org Wed Jun 25 12:00:05 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27A3728C12E; Wed, 25 Jun 2008 12:00:05 -0700 (PDT) X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 932F13A69F9; Wed, 25 Jun 2008 12:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080625190001.932F13A69F9@core3.amsl.com> Date: Wed, 25 Jun 2008 12:00:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --NextPart 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 Monitoring Schema Author(s) : M. Scott, et al. Filename : draft-ietf-netconf-monitoring-02.txt Pages : 42 Date : 2008-06-25 This document defines NETCONF content via XML Schema to be used to monitor the NETCONF protocol. It includes information about NETCONF sessions, locks, and subscriptions and is intended to facilitate management of a NETCONF server. In addition this memo defines a mechanism to discover all possible data models (schema list retrieval) and a mechanism to retrieve schema via NETCONF (get schema). Both can be performed dynamically throughout a session, unlike capabilities exchange which is performed during session setup only. Both support multiple schema versions, formats and locations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-monitoring-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-25115811.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --NextPart-- From netconf-bounces@ietf.org Wed Jun 25 12:00:05 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27A3728C12E; Wed, 25 Jun 2008 12:00:05 -0700 (PDT) X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 932F13A69F9; Wed, 25 Jun 2008 12:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080625190001.932F13A69F9@core3.amsl.com> Date: Wed, 25 Jun 2008 12:00:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --NextPart 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 Monitoring Schema Author(s) : M. Scott, et al. Filename : draft-ietf-netconf-monitoring-02.txt Pages : 42 Date : 2008-06-25 This document defines NETCONF content via XML Schema to be used to monitor the NETCONF protocol. It includes information about NETCONF sessions, locks, and subscriptions and is intended to facilitate management of a NETCONF server. In addition this memo defines a mechanism to discover all possible data models (schema list retrieval) and a mechanism to retrieve schema via NETCONF (get schema). Both can be performed dynamically throughout a session, unlike capabilities exchange which is performed during session setup only. Both support multiple schema versions, formats and locations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-monitoring-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-25115811.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --NextPart-- From netconf-bounces@ietf.org Wed Jun 25 12:07:08 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6637A3A6A9A; Wed, 25 Jun 2008 12:07:08 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52383A6A6A for ; Wed, 25 Jun 2008 12:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT7pj21nuzSp for ; Wed, 25 Jun 2008 12:07:03 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id D10693A6A69 for ; Wed, 25 Jun 2008 12:07:02 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5PJ72S10524 for ; Wed, 25 Jun 2008 19:07:02 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 15:06:29 -0400 Message-ID: <183DD1B052A11A40B76125E42F1CBAAB12BBD5E1@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] New Version for draft-ietf-netconf-monitoring-02 Thread-Index: AcjW9W0Xn4IFswiKR3umvL6L+58j8wAAAlkQ From: "Mark Scott" To: Subject: [Netconf] New Version for draft-ietf-netconf-monitoring-02 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, We have updated the NETCONF Monitoring Schema draft. Updates include the new RPC (), partial lock support, more descriptive text and appendix containing a YANG module. If I have overlooked any comments previously made please let me know. I will try to address them before Dublin. cheers, Mark -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Wednesday, June 25, 2008 2:58 PM To: Scott, Mark (CAR:2Y01) Cc: Chisholm, Sharon (CAR:ZZ00); mbj@tail-f.com Subject: New Version Notification for draft-ietf-netconf-monitoring-02 A new version of I-D, draft-ietf-netconf-monitoring-02.txt has been successfuly submitted by Mark Scott and posted to the IETF repository. Filename: draft-ietf-netconf-monitoring Revision: 02 Title: NETCONF Monitoring Schema Creation_date: 2008-06-25 WG ID: netconf Number_of_pages: 42 Abstract: This document defines NETCONF content via XML Schema to be used to monitor the NETCONF protocol. It includes information about NETCONF sessions, locks, and subscriptions and is intended to facilitate management of a NETCONF server. In addition this memo defines a mechanism to discover all possible data models (schema list retrieval) and a mechanism to retrieve schema via NETCONF (get schema). Both can be performed dynamically throughout a session, unlike capabilities exchange which is performed during session setup only. Both support multiple schema versions, formats and locations. The IETF Secretariat. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jun 25 12:07:08 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6637A3A6A9A; Wed, 25 Jun 2008 12:07:08 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52383A6A6A for ; Wed, 25 Jun 2008 12:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT7pj21nuzSp for ; Wed, 25 Jun 2008 12:07:03 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id D10693A6A69 for ; Wed, 25 Jun 2008 12:07:02 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5PJ72S10524 for ; Wed, 25 Jun 2008 19:07:02 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 15:06:29 -0400 Message-ID: <183DD1B052A11A40B76125E42F1CBAAB12BBD5E1@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] New Version for draft-ietf-netconf-monitoring-02 Thread-Index: AcjW9W0Xn4IFswiKR3umvL6L+58j8wAAAlkQ From: "Mark Scott" To: Subject: [Netconf] New Version for draft-ietf-netconf-monitoring-02 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, We have updated the NETCONF Monitoring Schema draft. Updates include the new RPC (), partial lock support, more descriptive text and appendix containing a YANG module. If I have overlooked any comments previously made please let me know. I will try to address them before Dublin. cheers, Mark -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Wednesday, June 25, 2008 2:58 PM To: Scott, Mark (CAR:2Y01) Cc: Chisholm, Sharon (CAR:ZZ00); mbj@tail-f.com Subject: New Version Notification for draft-ietf-netconf-monitoring-02 A new version of I-D, draft-ietf-netconf-monitoring-02.txt has been successfuly submitted by Mark Scott and posted to the IETF repository. Filename: draft-ietf-netconf-monitoring Revision: 02 Title: NETCONF Monitoring Schema Creation_date: 2008-06-25 WG ID: netconf Number_of_pages: 42 Abstract: This document defines NETCONF content via XML Schema to be used to monitor the NETCONF protocol. It includes information about NETCONF sessions, locks, and subscriptions and is intended to facilitate management of a NETCONF server. In addition this memo defines a mechanism to discover all possible data models (schema list retrieval) and a mechanism to retrieve schema via NETCONF (get schema). Both can be performed dynamically throughout a session, unlike capabilities exchange which is performed during session setup only. Both support multiple schema versions, formats and locations. The IETF Secretariat. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 26 11:41:19 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1A663A69D3; Thu, 26 Jun 2008 11:41:19 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2802A3A69D8 for ; Thu, 26 Jun 2008 11:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39kmtuAcHKg3 for ; Thu, 26 Jun 2008 11:41:17 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 27CBE3A69D3 for ; Thu, 26 Jun 2008 11:41:17 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5QIfH824531 for ; Thu, 26 Jun 2008 18:41:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 14:41:12 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4153961FC@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Monitoring Draft Thread-Index: AcjXvDUnAlzSayBCSNWKgcgVm0Zo1g== From: "Sharon Chisholm" To: Subject: [Netconf] Comments on Monitoring Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi 1. If the statistics are limited to NETCONF traffic, this should be clarified in the description clauses. Since we discuss CLI sessions in another part of the data model, this is not completely obvious. 2. For consistency with other NETCONF specifications, the protocol operation definition should be broken out separately from the content definition. 3. Should any of the parameters to the verb be optional? Currently they are all mandatory. If my device only has XSDs, do I really have to specify this parameter every single time? Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jun 26 11:41:19 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1A663A69D3; Thu, 26 Jun 2008 11:41:19 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2802A3A69D8 for ; Thu, 26 Jun 2008 11:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39kmtuAcHKg3 for ; Thu, 26 Jun 2008 11:41:17 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 27CBE3A69D3 for ; Thu, 26 Jun 2008 11:41:17 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5QIfH824531 for ; Thu, 26 Jun 2008 18:41:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 14:41:12 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4153961FC@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Monitoring Draft Thread-Index: AcjXvDUnAlzSayBCSNWKgcgVm0Zo1g== From: "Sharon Chisholm" To: Subject: [Netconf] Comments on Monitoring Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi 1. If the statistics are limited to NETCONF traffic, this should be clarified in the description clauses. Since we discuss CLI sessions in another part of the data model, this is not completely obvious. 2. For consistency with other NETCONF specifications, the protocol operation definition should be broken out separately from the content definition. 3. Should any of the parameters to the verb be optional? Currently they are all mandatory. If my device only has XSDs, do I really have to specify this parameter every single time? Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf