From netconf-bounces@ietf.org Wed Oct 1 03:49: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 342673A6C2D; Wed, 1 Oct 2008 03:49: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 2B5A23A6C2D for ; Wed, 1 Oct 2008 03:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, 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 wT+Xb6he+qb9 for ; Wed, 1 Oct 2008 03:49:37 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 276E93A69FE for ; Wed, 1 Oct 2008 03:49:37 -0700 (PDT) X-Trace: 32824587/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.60.166 X-SBRS: None X-RemoteIP: 213.116.60.166 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8FAC7z4kjVdDym/2dsb2JhbACDRziDV4UBqhKHBgNsew X-IronPort-AV: E=Sophos;i="4.33,342,1220223600"; d="scan'208";a="32824587" X-IP-Direction: IN Received: from 1cust166.tnt106.lnd4.gbr.da.uu.net (HELO allison) ([213.116.60.166]) by smtp.pipex.tiscali.co.uk with SMTP; 01 Oct 2008 11:49:56 +0100 Message-ID: <000c01c923aa$054cc6e0$0601a8c0@allison> From: "tom.petch" To: References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr><00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> Date: Wed, 1 Oct 2008 11:40:33 +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] =?utf-8?q?WGLC=C2=A0for=C2=A0draft-ietf-netconf-tls-04?= =?utf-8?q?=2Etxt?= 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 ----- Original Message ----- From: To: "tom.petch" Cc: ; "David Harrington" ; Sent: Tuesday, September 30, 2008 6:22 PM Subject: RE: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt > >> 4. Cipher Suite Requirements > >> > >> Implementation of the protocol specified in this document MAY > >> implement any TLS cipher suite that provides mutual authentication. > >> > >> Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to > >> support the mandatory to implement cipher suite, which is > >> TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to > >> future versions of TLS, in which case the mandatory to implement > >> cipher suite for the implemented From netconf-bounces@ietf.org Wed Oct 1 03:49: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 342673A6C2D; Wed, 1 Oct 2008 03:49: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 2B5A23A6C2D for ; Wed, 1 Oct 2008 03:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, 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 wT+Xb6he+qb9 for ; Wed, 1 Oct 2008 03:49:37 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 276E93A69FE for ; Wed, 1 Oct 2008 03:49:37 -0700 (PDT) X-Trace: 32824587/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.60.166 X-SBRS: None X-RemoteIP: 213.116.60.166 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8FAC7z4kjVdDym/2dsb2JhbACDRziDV4UBqhKHBgNsew X-IronPort-AV: E=Sophos;i="4.33,342,1220223600"; d="scan'208";a="32824587" X-IP-Direction: IN Received: from 1cust166.tnt106.lnd4.gbr.da.uu.net (HELO allison) ([213.116.60.166]) by smtp.pipex.tiscali.co.uk with SMTP; 01 Oct 2008 11:49:56 +0100 Message-ID: <000c01c923aa$054cc6e0$0601a8c0@allison> From: "tom.petch" To: References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr><00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> Date: Wed, 1 Oct 2008 11:40:33 +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] =?utf-8?q?WGLC=C2=A0for=C2=A0draft-ietf-netconf-tls-04?= =?utf-8?q?=2Etxt?= 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 ----- Original Message ----- From: To: "tom.petch" Cc: ; "David Harrington" ; Sent: Tuesday, September 30, 2008 6:22 PM Subject: RE: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt > >> 4. Cipher Suite Requirements > >> > >> Implementation of the protocol specified in this document MAY > >> implement any TLS cipher suite that provides mutual authentication. > >> > >> Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to > >> support the mandatory to implement cipher suite, which is > >> TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to > >> future versions of TLS, in which case the mandatory to implement > >> cipher suite for the implemented versioversion MUST be supported. > >> > >> In the case of the pre-shared key authentication (described in > >> Section 3.3), implementations are REQUIRED to support the cipher > >> suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA RFC4279]. > >> > >> Comments? > >> Best regards, > >> Badra > >> > > > > I think that you need more than this, somewhere in the document, giving > > the > > applicability of the two very different suites, when is one appropriate, > > when the other. > > I think the "applicability" or the benefits of using pre-shared key based > authentication have been explained in the Introduction of [RFC4279]. To > recall of them, would be sufficient to insert the following text at the > end of the first paragraph of Section 3? (The use of PSK is a MAY, not a > SHOULD) > > "The benefits of pre-shared symmetric-key vs. public-/private-key pair > based authentication for the key exchange in TLS have been explained in > the Introduction of [RFC4279]". > Weeeellllll I sort of see what you mean. Section 1.1 says "1.1. Applicability Statement The ciphersuites defined in this document are intended for a rather limited set of applications, usually involving only a very small number of clients and servers. Even in such environments, other alternatives may be more appropriate. If the main goal is to avoid Public-Key Infrastructures (PKIs), another possibility worth considering is using self-signed certificates with public key fingerprints. Instead of manually configuring a shared secret in, for instance, some configuration file, a fingerprint (hash) of the other party's public key (or certificate) could be placed there instead. It is also possible to use the SRP (Secure Remote Password) ciphersuites for shared secret authentication [SRP]. SRP was designed to be used with passwords, and it incorporates protection against dictionary attacks. However, it is computationally more expensive than the PSK ciphersuites in Section 2." which is all quite negative, not exactly benefits or applicability; and syslog went down the fingerprint route so what makes netconf different, why is it one of those 'limited set of applications'? Tom Petch > Best regards > Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf n MUST be supported. > >> > >> In the case of the pre-shared key authentication (described in > >> Section 3.3), implementations are REQUIRED to support the cipher > >> suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA RFC4279]. > >> > >> Comments? > >> Best regards, > >> Badra > >> > > > > I think that you need more than this, somewhere in the document, giving > > the > > applicability of the two very different suites, when is one appropriate, > > when the other. > > I think the "applicability" or the benefits of using pre-shared key based > authentication have been explained in the Introduction of [RFC4279]. To > recall of them, would be sufficient to insert the following text at the > end of the first paragraph of Section 3? (The use of PSK is a MAY, not a > SHOULD) > > "The benefits of pre-shared symmetric-key vs. public-/private-key pair > based authentication for the key exchange in TLS have been explained in > the Introduction of [RFC4279]". > Weeeellllll I sort of see what you mean. Section 1.1 says "1.1. Applicability Statement The ciphersuites defined in this document are intended for a rather limited set of applications, usually involving only a very small number of clients and servers. Even in such environments, other alternatives may be more appropriate. If the main goal is to avoid Public-Key Infrastructures (PKIs), another possibility worth considering is using self-signed certificates with public key fingerprints. Instead of manually configuring a shared secret in, for instance, some configuration file, a fingerprint (hash) of the other party's public key (or certificate) could be placed there instead. It is also possible to use the SRP (Secure Remote Password) ciphersuites for shared secret authentication [SRP]. SRP was designed to be used with passwords, and it incorporates protection against dictionary attacks. However, it is computationally more expensive than the PSK ciphersuites in Section 2." which is all quite negative, not exactly benefits or applicability; and syslog went down the fingerprint route so what makes netconf different, why is it one of those 'limited set of applications'? Tom Petch > Best regards > Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Oct 1 05:57:26 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 416B03A6BF1; Wed, 1 Oct 2008 05:57:26 -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 C5CF83A6BF1 for ; Wed, 1 Oct 2008 05:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.426 X-Spam-Level: X-Spam-Status: No, score=-1.426 tagged_above=-999 required=5 tests=[AWL=0.371, 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 XclUweD61+0g for ; Wed, 1 Oct 2008 05:57:24 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 44DDD3A6BA8 for ; Wed, 1 Oct 2008 05:57:24 -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 m91DvhFP594070; Wed, 1 Oct 2008 14:57:43 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Wed, 1 Oct 2008 14:56:32 +0200 (CEST) Message-ID: <55201.88.164.98.77.1222865792.squirrel@www.isima.fr> In-Reply-To: <000c01c923aa$054cc6e0$0601a8c0@allison> References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr><00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <000c01c923aa$054cc6e0$0601a8c0@allison> Date: Wed, 1 Oct 2008 14:56:32 +0200 (CEST) From: badra@isima.fr To: "=?utf-8?Q?tom.petch=C2?=" 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]); Wed, 01 Oct 2008 14:57:43 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: Re: [Netconf] =?utf-8?q?WGLC=C2=A0for=C2=A0draft-ietf-netconf-tls-04?= =?utf-8?q?=2Etxt?= 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 >> "The benefits of pre-shared symmetric-key vs. public-/private-key pair >> based authentication for the key exchange in TLS have been explained in >> the Introduction of [RFC4279]". >> > > Weeeellllll I sort of see what you mean. Section 1.1 says > > "1.1. Applicability Statement > > The ciphersuites defined in this document are intended for a rather > limited set of applications, usually involving only a very small > number of clients and servers. Even in such environments, other > alternatives may be more appropriate. > > If the main goal is to avoid Public-Key Infrastructures (PKIs), > another possibility worth considering is using self-signed > certificates with public key fingerprints. Instead of manually > configuring a shared secret in, for instance, some configuration > file, a fingerprint (hash) of the other party's public key (or > certificate) could be placed there instead. > > It is also possible to use the SRP (Secure From netconf-bounces@ietf.org Wed Oct 1 05:57:26 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 416B03A6BF1; Wed, 1 Oct 2008 05:57:26 -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 C5CF83A6BF1 for ; Wed, 1 Oct 2008 05:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.426 X-Spam-Level: X-Spam-Status: No, score=-1.426 tagged_above=-999 required=5 tests=[AWL=0.371, 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 XclUweD61+0g for ; Wed, 1 Oct 2008 05:57:24 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 44DDD3A6BA8 for ; Wed, 1 Oct 2008 05:57:24 -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 m91DvhFP594070; Wed, 1 Oct 2008 14:57:43 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Wed, 1 Oct 2008 14:56:32 +0200 (CEST) Message-ID: <55201.88.164.98.77.1222865792.squirrel@www.isima.fr> In-Reply-To: <000c01c923aa$054cc6e0$0601a8c0@allison> References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr><00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <000c01c923aa$054cc6e0$0601a8c0@allison> Date: Wed, 1 Oct 2008 14:56:32 +0200 (CEST) From: badra@isima.fr To: "=?utf-8?Q?tom.petch=C2?=" 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]); Wed, 01 Oct 2008 14:57:43 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: Re: [Netconf] =?utf-8?q?WGLC=C2=A0for=C2=A0draft-ietf-netconf-tls-04?= =?utf-8?q?=2Etxt?= 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 >> "The benefits of pre-shared symmetric-key vs. public-/private-key pair >> based authentication for the key exchange in TLS have been explained in >> the Introduction of [RFC4279]". >> > > Weeeellllll I sort of see what you mean. Section 1.1 says > > "1.1. Applicability Statement > > The ciphersuites defined in this document are intended for a rather > limited set of applications, usually involving only a very small > number of clients and servers. Even in such environments, other > alternatives may be more appropriate. > > If the main goal is to avoid Public-Key Infrastructures (PKIs), > another possibility worth considering is using self-signed > certificates with public key fingerprints. Instead of manually > configuring a shared secret in, for instance, some configuration > file, a fingerprint (hash) of the other party's public key (or > certificate) could be placed there instead. > > It is also possible to use the SRP (SRemote Password) > ciphersuites for shared secret authentication [SRP]. SRP was > designed to be used with passwords, and it incorporates protection > against dictionary attacks. However, it is computationally more > expensive than the PSK ciphersuites in Section 2." > > which is all quite negative, not exactly benefits or applicability; and > syslog > went down the fingerprint route so what makes netconf different, why is it > one > of those 'limited set of applications'? > Maybe I don't understand well your point here; using PSK is optional with the document and the only mandatory mode to implement is certificate base authentication. The Jurgen proposal works for you? (inserting the following sentence at the end of paragraph 1 of Section 3: "For details concerning pre-shared key based authentication see [RFC4279]".) And what is the reason to add fingerprint to Netconf? Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ecure Remote Password) > ciphersuites for shared secret authentication [SRP]. SRP was > designed to be used with passwords, and it incorporates protection > against dictionary attacks. However, it is computationally more > expensive than the PSK ciphersuites in Section 2." > > which is all quite negative, not exactly benefits or applicability; and > syslog > went down the fingerprint route so what makes netconf different, why is it > one > of those 'limited set of applications'? > Maybe I don't understand well your point here; using PSK is optional with the document and the only mandatory mode to implement is certificate base authentication. The Jurgen proposal works for you? (inserting the following sentence at the end of paragraph 1 of Section 3: "For details concerning pre-shared key based authentication see [RFC4279]".) And what is the reason to add fingerprint to Netconf? Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Oct 1 10:57: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 965173A6859; Wed, 1 Oct 2008 10:57: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 F08CD3A681F for ; Wed, 1 Oct 2008 10:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=1.149, BAYES_00=-2.599, 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 eDi4POImp1as for ; Wed, 1 Oct 2008 10:57:56 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id AC8B93A6405 for ; Wed, 1 Oct 2008 10:57:55 -0700 (PDT) X-Trace: 176470134/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.143.234 X-SBRS: None X-RemoteIP: 62.188.143.234 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAAdX40g+vI/q/2dsb2JhbACDRziIXapvhnwDbHs X-IronPort-AV: E=Sophos;i="4.33,344,1220223600"; d="scan'208";a="176470134" X-IP-Direction: IN Received: from 1cust234.tnt14.lnd4.gbr.da.uu.net (HELO allison) ([62.188.143.234]) by smtp.pipex.tiscali.co.uk with SMTP; 01 Oct 2008 18:56:27 +0100 Message-ID: <001901c923e5$9b2d73e0$0601a8c0@allison> From: "tom.petch" To: References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr><00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <000c01c923aa$054cc6e0$0601a8c0@allison> <55201.88.164.98.77.1222865792.squirrel@www.isima.fr> Date: Wed, 1 Oct 2008 18:48:01 +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] =?utf-8?q?WGLC=C2=A0for=C2=A0draft-ietf-netconf-tls-04?= =?utf-8?q?=2Etxt?= 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 ----- Original Message ----- From: To: "tom.petch" Cc: ; "David Harrington" Sent: Wednesday, October 01, 2008 2:56 PM Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt > >> "The benefits of pre-shared symmetric-key vs. public-/private-key pair > >> based authentication for the key exchange in TLS have been explained in > >> the Introduction of [RFC4279]". > >> > > Weeeellllll I sort of see what you mean. Section 1.1 says > > > > "1.1. Applicability Statement > > > > The ciphersuites defined in this document are intended for a rather > > limited set of applications, usually involving only a very small > > number of clFrom netconf-bounces@ietf.org Wed Oct 1 10:57: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 965173A6859; Wed, 1 Oct 2008 10:57: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 F08CD3A681F for ; Wed, 1 Oct 2008 10:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=1.149, BAYES_00=-2.599, 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 eDi4POImp1as for ; Wed, 1 Oct 2008 10:57:56 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id AC8B93A6405 for ; Wed, 1 Oct 2008 10:57:55 -0700 (PDT) X-Trace: 176470134/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.143.234 X-SBRS: None X-RemoteIP: 62.188.143.234 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAAdX40g+vI/q/2dsb2JhbACDRziIXapvhnwDbHs X-IronPort-AV: E=Sophos;i="4.33,344,1220223600"; d="scan'208";a="176470134" X-IP-Direction: IN Received: from 1cust234.tnt14.lnd4.gbr.da.uu.net (HELO allison) ([62.188.143.234]) by smtp.pipex.tiscali.co.uk with SMTP; 01 Oct 2008 18:56:27 +0100 Message-ID: <001901c923e5$9b2d73e0$0601a8c0@allison> From: "tom.petch" To: References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr><00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <000c01c923aa$054cc6e0$0601a8c0@allison> <55201.88.164.98.77.1222865792.squirrel@www.isima.fr> Date: Wed, 1 Oct 2008 18:48:01 +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] =?utf-8?q?WGLC=C2=A0for=C2=A0draft-ietf-netconf-tls-04?= =?utf-8?q?=2Etxt?= 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 ----- Original Message ----- From: To: "tom.petch" Cc: ; "David Harrington" Sent: Wednesday, October 01, 2008 2:56 PM Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt > >> "The benefits of pre-shared symmetric-key vs. public-/private-key pair > >> based authentication for the key exchange in TLS have been explained in > >> the Introduction of [RFC4279]". > >> > > Weeeellllll I sort of see what you mean. Section 1.1 says > > > > "1.1. Applicability Statement > > > > The ciphersuites defined in this document are intended for a rather > > limited set of applications, usually involving only a very small > > number of clients ients and servers. Even in such environments, other > > alternatives may be more appropriate. > > > > If the main goal is to avoid Public-Key Infrastructures (PKIs), > > another possibility worth considering is using self-signed > > certificates with public key fingerprints. Instead of manually > > configuring a shared secret in, for instance, some configuration > > file, a fingerprint (hash) of the other party's public key (or > > certificate) could be placed there instead. > > > > It is also possible to use the SRP (Secure Remote Password) > > ciphersuites for shared secret authentication [SRP]. SRP was > > designed to be used with passwords, and it incorporates protection > > against dictionary attacks. However, it is computationally more > > expensive than the PSK ciphersuites in Section 2." > > > > which is all quite negative, not exactly benefits or applicability; and > > syslog > > went down the fingerprint route so what makes netconf different, why is it > > one of those 'limited set of applications'? > > > > Maybe I don't understand well your point here; using PSK is optional with > the document and the only mandatory mode to implement is certificate base > authentication. > > The Jurgen proposal works for you? (inserting the following sentence at > the end of paragraph 1 of Section 3: "For details concerning pre-shared > key based authentication see [RFC4279]".) > The problem I have is why specify two cipher suites out of the legion that are available. One strong one must be present (BCP0061), why specify another, unless there is a use case, an applicability, where it is likely to be widespread or a markedly better choice. My take has always been that TLS, PKI etc works well when the server is large, powerful, central etc, capable of doing anything that the IETF might suggest; and clients are workstations equipped with a human operator, able to decide what to do about certificate error messages ('name does not match' 'date is in the future' etc). HTTP fits that well (what a surprise:-), syslog does not (and is a simplex protocol to boot). So fingerprints and syslog seem like good bedfellows. So with netconf, why mention PSK at all? Fingerprints I would understand from parallels to syslog, PSK I do not. And I suspect that the user who goes to RFC4279 for enlightenment will be disappointed; fine RFC but an explanation of applicability is not there, IMHO. Tom Petch > And what is the reason to add fingerprint to Netconf? > > Best regards, > Badra > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf and servers. Even in such environments, other > > alternatives may be more appropriate. > > > > If the main goal is to avoid Public-Key Infrastructures (PKIs), > > another possibility worth considering is using self-signed > > certificates with public key fingerprints. Instead of manually > > configuring a shared secret in, for instance, some configuration > > file, a fingerprint (hash) of the other party's public key (or > > certificate) could be placed there instead. > > > > It is also possible to use the SRP (Secure Remote Password) > > ciphersuites for shared secret authentication [SRP]. SRP was > > designed to be used with passwords, and it incorporates protection > > against dictionary attacks. However, it is computationally more > > expensive than the PSK ciphersuites in Section 2." > > > > which is all quite negative, not exactly benefits or applicability; and > > syslog > > went down the fingerprint route so what makes netconf different, why is it > > one of those 'limited set of applications'? > > > > Maybe I don't understand well your point here; using PSK is optional with > the document and the only mandatory mode to implement is certificate base > authentication. > > The Jurgen proposal works for you? (inserting the following sentence at > the end of paragraph 1 of Section 3: "For details concerning pre-shared > key based authentication see [RFC4279]".) > The problem I have is why specify two cipher suites out of the legion that are available. One strong one must be present (BCP0061), why specify another, unless there is a use case, an applicability, where it is likely to be widespread or a markedly better choice. My take has always been that TLS, PKI etc works well when the server is large, powerful, central etc, capable of doing anything that the IETF might suggest; and clients are workstations equipped with a human operator, able to decide what to do about certificate error messages ('name does not match' 'date is in the future' etc). HTTP fits that well (what a surprise:-), syslog does not (and is a simplex protocol to boot). So fingerprints and syslog seem like good bedfellows. So with netconf, why mention PSK at all? Fingerprints I would understand from parallels to syslog, PSK I do not. And I suspect that the user who goes to RFC4279 for enlightenment will be disappointed; fine RFC but an explanation of applicability is not there, IMHO. Tom Petch > And what is the reason to add fingerprint to Netconf? > > Best regards, > Badra > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Oct 1 11:28: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 3D7CE3A6811; Wed, 1 Oct 2008 11:28: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 88D973A6811 for ; Wed, 1 Oct 2008 11:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[AWL=-0.822, BAYES_40=-0.185, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] 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 JLZyb88RjcPG for ; Wed, 1 Oct 2008 11:28:05 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id E00043A67A7 for ; Wed, 1 Oct 2008 11:28:04 -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 m91JQgwD921742; Wed, 1 Oct 2008 20:26:42 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Wed, 1 Oct 2008 20:25:30 +0200 (CEST) Message-ID: <56653.88.164.98.77.1222885530.squirrel@www.isima.fr> In-Reply-To: <001901c923e5$9b2d73e0$0601a8c0@allison> References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr><00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <000c01c923aa$054cc6e0$0601a8c0@allison> <55201.88.164.98.77.1222865792.squirrel@www.isima.fr> <001901c923e5$9b2d73e0$0601a8c0@allison> Date: Wed, 1 Oct 2008 20:25:30 +0200 (CEST) From: badra@isima.fr To: "=?utf-8?Q?tom.petch=C2?=" 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]); Wed, 01 Oct 2008 20:26:42 +0100 (WEST) Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > So with netconf, why mention PSK at all? Fingerprints I would understand > from > parallels to syslog, PSK I do not. And I suspect that the user who goes > to > RFC4279 for enlightenment will be disappointed; fine RFC but an > explanation of > applicability is not there, IMHO. > > Tom Petch OK, so better to remove the PSK based authentication, right? BTW, we received alike comment from Juergen, I will ask the WG members to decide whatever to keep ot to remove this authentication mode. Best regards Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Oct 1 11:28: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 3D7CE3A6811; Wed, 1 Oct 2008 11:28: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 88D973A6811 for ; Wed, 1 Oct 2008 11:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[AWL=-0.822, BAYES_40=-0.185, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] 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 JLZyb88RjcPG for ; Wed, 1 Oct 2008 11:28:05 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id E00043A67A7 for ; Wed, 1 Oct 2008 11:28:04 -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 m91JQgwD921742; Wed, 1 Oct 2008 20:26:42 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Wed, 1 Oct 2008 20:25:30 +0200 (CEST) Message-ID: <56653.88.164.98.77.1222885530.squirrel@www.isima.fr> In-Reply-To: <001901c923e5$9b2d73e0$0601a8c0@allison> References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr><00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <000c01c923aa$054cc6e0$0601a8c0@allison> <55201.88.164.98.77.1222865792.squirrel@www.isima.fr> <001901c923e5$9b2d73e0$0601a8c0@allison> Date: Wed, 1 Oct 2008 20:25:30 +0200 (CEST) From: badra@isima.fr To: "=?utf-8?Q?tom.petch=C2?=" 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]); Wed, 01 Oct 2008 20:26:42 +0100 (WEST) Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > So with netconf, why mention PSK at all? Fingerprints I would understand > from > parallels to syslog, PSK I do not. And I suspect that the user who goes > to > RFC4279 for enlightenment will be disappointed; fine RFC but an > explanation of > applicability is not there, IMHO. > > Tom Petch OK, so better to remove the PSK based authentication, right? BTW, we received alike comment from Juergen, I will ask the WG members to decide whatever to keep ot to remove this authentication mode. Best regards Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Oct 1 11:47: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 F03F53A6917; Wed, 1 Oct 2008 11:47: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 A13F63A68FC for ; Wed, 1 Oct 2008 11:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.476 X-Spam-Level: X-Spam-Status: No, score=-0.476 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_40=-0.185, 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 h6G6oVelGQKk for ; Wed, 1 Oct 2008 11:47:19 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id B63C13A69DF for ; Wed, 1 Oct 2008 11:47:18 -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 m91JlKL31085542 for ; Wed, 1 Oct 2008 20:47:20 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Wed, 1 Oct 2008 20:46:08 +0200 (CEST) Message-ID: <56872.88.164.98.77.1222886768.squirrel@www.isima.fr> Date: Wed, 1 Oct 2008 20:46:08 +0200 (CEST) From: badra@isima.fr To: netconf@ietf.org 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]); Wed, 01 Oct 2008 20:47:20 +0100 (WEST) Subject: [Netconf] Deprecate or Keep the text related to PSK-based authentication (was WGLC for draft-ietf-netconf-tls-04.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear all, During the discussion related to Netconf over TLS, I did get the impression that many WG members thought that PSK-based authentication is not suitable for Netconf, and the NETCONF over TLS specification doesn't need to mention it at all. I think there are two basic options: (A) Don't mention PSK-based authentication at all. (B) Keep the current text. The motivations for option (A) is detailed by Tom Petch (http://www.ietf.org/mail-archive/web/netconf/current/msg03854.html) and by Juergen Schoenwaelder (http://www.ietf.org/mail-archive/web/netconf/current/msg03817.html) Please express you preference on the list for one of these two options by the WGLC deadline. Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Oct 1 11:47: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 F03F53A6917; Wed, 1 Oct 2008 11:47: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 A13F63A68FC for ; Wed, 1 Oct 2008 11:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.476 X-Spam-Level: X-Spam-Status: No, score=-0.476 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_40=-0.185, 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 h6G6oVelGQKk for ; Wed, 1 Oct 2008 11:47:19 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id B63C13A69DF for ; Wed, 1 Oct 2008 11:47:18 -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 m91JlKL31085542 for ; Wed, 1 Oct 2008 20:47:20 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Wed, 1 Oct 2008 20:46:08 +0200 (CEST) Message-ID: <56872.88.164.98.77.1222886768.squirrel@www.isima.fr> Date: Wed, 1 Oct 2008 20:46:08 +0200 (CEST) From: badra@isima.fr To: netconf@ietf.org 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]); Wed, 01 Oct 2008 20:47:20 +0100 (WEST) Subject: [Netconf] Deprecate or Keep the text related to PSK-based authentication (was WGLC for draft-ietf-netconf-tls-04.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear all, During the discussion related to Netconf over TLS, I did get the impression that many WG members thought that PSK-based authentication is not suitable for Netconf, and the NETCONF over TLS specification doesn't need to mention it at all. I think there are two basic options: (A) Don't mention PSK-based authentication at all. (B) Keep the current text. The motivations for option (A) is detailed by Tom Petch (http://www.ietf.org/mail-archive/web/netconf/current/msg03854.html) and by Juergen Schoenwaelder (http://www.ietf.org/mail-archive/web/netconf/current/msg03817.html) Please express you preference on the list for one of these two options by the WGLC deadline. Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Oct 1 15:03: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 BD8073A68D3; Wed, 1 Oct 2008 15:03: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 0959D3A68D3 for ; Wed, 1 Oct 2008 15:03:32 -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 hDkzlz4i8TUO for ; Wed, 1 Oct 2008 15:03:31 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 1BD9D3A6846 for ; Wed, 1 Oct 2008 15:03:31 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA03.westchester.pa.mail.comcast.net with comcast id MS6X1a0040cZkys53a3vdQ; Wed, 01 Oct 2008 22:03:55 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA10.westchester.pa.mail.comcast.net with comcast id Ma3v1a0054HwxpC3Wa3v48; Wed, 01 Oct 2008 22:03:55 +0000 X-Authority-Analysis: v=1.0 c=1 a=ZMF4x87TjMsA:10 a=iO7KYi4ROgAA:10 a=48vgC7mUAAAA:8 a=XPfUjVNie98wR-IXQ5MA:9 a=xadlurcj0VPzbEQP9OcA0d6M9V4A:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: , References: <56872.88.164.98.77.1222886768.squirrel@www.isima.fr> Date: Wed, 1 Oct 2008 18:03:55 -0400 Message-ID: <013101c92411$98db1b70$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ackj9jJTfAp5vAqcTV+gkunNbo0r/gAGzCpQ In-Reply-To: <56872.88.164.98.77.1222886768.squirrel@www.isima.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Netconf] Deprecate or Keep the text related to PSK-based authentication (was WGLC for draft-ietf-netconf-tls-04.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I do not see the benefit of mentioning PSK, and support removing mention of it. dbh > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of badra@isima.fr > Sent: Wednesday, October 01, 2008 2:46 PM > To: netconf@ietf.org > Subject: [Netconf] Deprecate or Keep the text related to > PSK-based authentication (was WGLC for draft-ietf-netconf-tls-04.txt) > > Dear all, > > During the discussion related to Netconf over TLS, I did get the > impression that many WG members thought that PSK-based > authentication is > not suitable for Netconf, and the NETCONF over TLS > specification doesn't > need to mention it at all. > > I think there are two basic options: > > (A) Don't mention PSK-based authentication at all. > > (B) Keep the current text. > > The motivations for option (A) is detailed by Tom Petch > (http://www.ietf.org/mail-archive/web/netconf/current/msg03854 > .html) and > by Juergen Schoenwaelder > (http://www.ietf.org/mail-archive/web/netconf/current/msg03817.html) From netconf-bounces@ietf.org Wed Oct 1 15:03: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 BD8073A68D3; Wed, 1 Oct 2008 15:03: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 0959D3A68D3 for ; Wed, 1 Oct 2008 15:03:32 -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 hDkzlz4i8TUO for ; Wed, 1 Oct 2008 15:03:31 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 1BD9D3A6846 for ; Wed, 1 Oct 2008 15:03:31 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA03.westchester.pa.mail.comcast.net with comcast id MS6X1a0040cZkys53a3vdQ; Wed, 01 Oct 2008 22:03:55 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA10.westchester.pa.mail.comcast.net with comcast id Ma3v1a0054HwxpC3Wa3v48; Wed, 01 Oct 2008 22:03:55 +0000 X-Authority-Analysis: v=1.0 c=1 a=ZMF4x87TjMsA:10 a=iO7KYi4ROgAA:10 a=48vgC7mUAAAA:8 a=XPfUjVNie98wR-IXQ5MA:9 a=xadlurcj0VPzbEQP9OcA0d6M9V4A:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: , References: <56872.88.164.98.77.1222886768.squirrel@www.isima.fr> Date: Wed, 1 Oct 2008 18:03:55 -0400 Message-ID: <013101c92411$98db1b70$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ackj9jJTfAp5vAqcTV+gkunNbo0r/gAGzCpQ In-Reply-To: <56872.88.164.98.77.1222886768.squirrel@www.isima.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Netconf] Deprecate or Keep the text related to PSK-based authentication (was WGLC for draft-ietf-netconf-tls-04.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I do not see the benefit of mentioning PSK, and support removing mention of it. dbh > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of badra@isima.fr > Sent: Wednesday, October 01, 2008 2:46 PM > To: netconf@ietf.org > Subject: [Netconf] Deprecate or Keep the text related to > PSK-based authentication (was WGLC for draft-ietf-netconf-tls-04.txt) > > Dear all, > > During the discussion related to Netconf over TLS, I did get the > impression that many WG members thought that PSK-based > authentication is > not suitable for Netconf, and the NETCONF over TLS > specification doesn't > need to mention it at all. > > I think there are two basic options: > > (A) Don't mention PSK-based authentication at all. > > (B) Keep the current text. > > The motivations for option (A) is detailed by Tom Petch > (http://www.ietf.org/mail-archive/web/netconf/current/msg03854 > .html) and > by Juergen Schoenwaelder > (http://www.ietf.org/mail-archive/web/netconf/current/msg03817.> > Please express you preference on the list for one of these > two options by > the WGLC deadline. > > 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 html) > > Please express you preference on the list for one of these > two options by > the WGLC deadline. > > 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 Wed Oct 1 15:09: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 451BA3A68A8; Wed, 1 Oct 2008 15:09: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 E596B3A68A8 for ; Wed, 1 Oct 2008 15:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 pk3vSQ2qDPhA for ; Wed, 1 Oct 2008 15:09:12 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 13F273A6890 for ; Wed, 1 Oct 2008 15:09:11 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA07.westchester.pa.mail.comcast.net with comcast id MTLA1a0020vyq2s57a9SB6; Wed, 01 Oct 2008 22:09:26 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.westchester.pa.mail.comcast.net with comcast id Ma9S1a0094HwxpC3Ra9SkK; Wed, 01 Oct 2008 22:09:26 +0000 X-Authority-Analysis: v=1.0 c=1 a=5pgCxNeWxJYA:10 a=5zy-Xv_fXMAA:10 a=sHpBxYAg8yaWD5Bi0l0A:9 a=R1RNjVZJf_lT1tPl0uMA:7 a=Er99QbknYwuYl39wbVVvo3OBpB0A:4 a=gJcimI5xSWUA:10 From: "David B Harrington" To: "'tom.petch'" , References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr><00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <000c01c923aa$054cc6e0$0601a8c0@allison> <55201.88.164.98.77.1222865792.squirrel@www.isima.fr> <001901c923e5$9b2d73e0$0601a8c0@allison> Date: Wed, 1 Oct 2008 18:09:26 -0400 Message-ID: <013201c92412$5e3d59a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ackj7wtFPq+Jl5qpRMCQs5428fnbSQAIrLHQ In-Reply-To: <001901c923e5$9b2d73e0$0601a8c0@allison> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netconf@ietf.org Subject: Re: [Netconf] =?iso-8859-1?q?WGLC=A0for=A0draft-ietf-netconf-tls-04?= =?iso-8859-1?q?=2Etxt?= 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 > The problem I have is why specify two cipher suites out of > the legion that are > available. One strong one must be present (BCP0061), why > specify another, > unless there is a use case, an applicability, where it is likely to be > widespread or a markedly better choice. > > My take has always been that TLS, PKI etc works well when the > server is large, > powerful, central etc, capable of doing anything that the > IETF might suggest; > and clients are workstations equipped with a human operator, > able to decide what > to do about certificate error messages ('name does not match' > 'date is in the > future' etc). HTTP fits that well (what a surprise:-), > syslog does not (and is > a simplex protocol to boot). So fingerprints and syslog seem > like good > bedfellows. > > So with netconf, why mention PSK at all? Fingerprints I would > understand from > parallels to syslog, PSK I do not. And I suspect that the > user who goes to > RFC4279 for enlightenment will be disappointed; fine RFC but > an explanation of > applicability is not there, IMHO. FYI, Fingerprints were added to syslog because TLS has been declared the mandatory-to-implement transport, because UDP does not support congestion control. TLS is not the mandatory-to-implement transport for Netconf, so specific support of fingerprints is not needed for Netconf for the reasons it is with syslog. dbh _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Oct 1 15:09: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 451BA3A68A8; Wed, 1 Oct 2008 15:09: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 E596B3A68A8 for ; Wed, 1 Oct 2008 15:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 pk3vSQ2qDPhA for ; Wed, 1 Oct 2008 15:09:12 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 13F273A6890 for ; Wed, 1 Oct 2008 15:09:11 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA07.westchester.pa.mail.comcast.net with comcast id MTLA1a0020vyq2s57a9SB6; Wed, 01 Oct 2008 22:09:26 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.westchester.pa.mail.comcast.net with comcast id Ma9S1a0094HwxpC3Ra9SkK; Wed, 01 Oct 2008 22:09:26 +0000 X-Authority-Analysis: v=1.0 c=1 a=5pgCxNeWxJYA:10 a=5zy-Xv_fXMAA:10 a=sHpBxYAg8yaWD5Bi0l0A:9 a=R1RNjVZJf_lT1tPl0uMA:7 a=Er99QbknYwuYl39wbVVvo3OBpB0A:4 a=gJcimI5xSWUA:10 From: "David B Harrington" To: "'tom.petch'" , References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr><00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <000c01c923aa$054cc6e0$0601a8c0@allison> <55201.88.164.98.77.1222865792.squirrel@www.isima.fr> <001901c923e5$9b2d73e0$0601a8c0@allison> Date: Wed, 1 Oct 2008 18:09:26 -0400 Message-ID: <013201c92412$5e3d59a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ackj7wtFPq+Jl5qpRMCQs5428fnbSQAIrLHQ In-Reply-To: <001901c923e5$9b2d73e0$0601a8c0@allison> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netconf@ietf.org Subject: Re: [Netconf] =?iso-8859-1?q?WGLC=A0for=A0draft-ietf-netconf-tls-04?= =?iso-8859-1?q?=2Etxt?= 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 > The problem I have is why specify two cipher suites out of > the legion that are > available. One strong one must be present (BCP0061), why > specify another, > unless there is a use case, an applicability, where it is likely to be > widespread or a markedly better choice. > > My take has always been that TLS, PKI etc works well when the > server is large, > powerful, central etc, capable of doing anything that the > IETF might suggest; > and clients are workstations equipped with a human operator, > able to decide what > to do about certificate error messages ('name does not match' > 'date is in the > future' etc). HTTP fits that well (what a surprise:-), > syslog does not (and is > a simplex protocol to boot). So fingerprints and syslog seem > like good > bedfellows. > > So with netconf, why mention PSK at all? Fingerprints I would > understand from > parallels to syslog, PSK I do not. And I suspect that the > user who goes to > RFC4279 for enlightenment will be disappointed; fine RFC but > an explanation of > applicability is not there, IMHO. FYI, Fingerprints were added to syslog because TLS has been declared the mandatory-to-implement transport, because UDP does not support congestion control. TLS is not the mandatory-to-implement transport for Netconf, so specific support of fingerprints is not needed for Netconf for the reasons it is with syslog. dbh _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Oct 6 11:20:02 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 2EC7C28C1D9; Mon, 6 Oct 2008 11:20:02 -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 BCAA328C14D for ; Mon, 6 Oct 2008 11:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_20=-0.74, 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 9dJv6QNtwFbw for ; Mon, 6 Oct 2008 11:19:55 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 1DC4328C1A8 for ; Mon, 6 Oct 2008 11:19: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 m96JJvdd966810 for ; Mon, 6 Oct 2008 20:19:57 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Mon, 6 Oct 2008 20:18:28 +0200 (CEST) Message-ID: <62034.88.164.98.77.1223317108.squirrel@www.isima.fr> Date: Mon, 6 Oct 2008 20:18:28 +0200 (CEST) From: badra@isima.fr To: netconf@ietf.org 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]); Mon, 06 Oct 2008 20:19:57 +0100 (WEST) Subject: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt: Connection Closure 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, Below is a new tentative to agree on the text related to the Section 'Connection Closure'. The text is much closed to Section 4.4 of draft-ietf-syslog-transport-tls-14 with one exception; in Netconf, both the agent and the manager may send data. A TLS client (NETCONF manager) MUST close the associated TLS connection if the connection is not expected to deliver any rpc operation later. It MUST send a TLS close_notify alert before closing the connection. The TLS client MAY choose to not wait for the TLS server (NETCONF agent) close_notify alert and simply close the connection, thus generating an incomplete close on the TLS server side. Once the TLS server gets a close_notify from the TLS client, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the TLS client (e.g., the closure was indicated by TCP). When no data is received from a connection for a long time (where the application decides what "long" means), a NETCONF peer MAY close the connection. The NETCONF peer MUST attempt to initiate an exchange of close_notify alerts with the other NETCONF peer before closing the connection. The close_notify's sender that is unprepared to receive any more data MAY close the connection after sending the close_notify alert, thus generating an incomplete close on the close_notify's receiver side. Comments? Best regards, Badra _______From netconf-bounces@ietf.org Mon Oct 6 11:20:02 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 2EC7C28C1D9; Mon, 6 Oct 2008 11:20:02 -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 BCAA328C14D for ; Mon, 6 Oct 2008 11:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_20=-0.74, 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 9dJv6QNtwFbw for ; Mon, 6 Oct 2008 11:19:55 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 1DC4328C1A8 for ; Mon, 6 Oct 2008 11:19: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 m96JJvdd966810 for ; Mon, 6 Oct 2008 20:19:57 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Mon, 6 Oct 2008 20:18:28 +0200 (CEST) Message-ID: <62034.88.164.98.77.1223317108.squirrel@www.isima.fr> Date: Mon, 6 Oct 2008 20:18:28 +0200 (CEST) From: badra@isima.fr To: netconf@ietf.org 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]); Mon, 06 Oct 2008 20:19:57 +0100 (WEST) Subject: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt: Connection Closure 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, Below is a new tentative to agree on the text related to the Section 'Connection Closure'. The text is much closed to Section 4.4 of draft-ietf-syslog-transport-tls-14 with one exception; in Netconf, both the agent and the manager may send data. A TLS client (NETCONF manager) MUST close the associated TLS connection if the connection is not expected to deliver any rpc operation later. It MUST send a TLS close_notify alert before closing the connection. The TLS client MAY choose to not wait for the TLS server (NETCONF agent) close_notify alert and simply close the connection, thus generating an incomplete close on the TLS server side. Once the TLS server gets a close_notify from the TLS client, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the TLS client (e.g., the closure was indicated by TCP). When no data is received from a connection for a long time (where the application decides what "long" means), a NETCONF peer MAY close the connection. The NETCONF peer MUST attempt to initiate an exchange of close_notify alerts with the other NETCONF peer before closing the connection. The close_notify's sender that is unprepared to receive any more data MAY close the connection after sending the close_notify alert, thus generating an incomplete close on the close_notify's receiver side. Comments? 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 Mon Oct 6 11:40:16 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 878DD28C116; Mon, 6 Oct 2008 11:40:16 -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 26C4228C0F1 for ; Mon, 6 Oct 2008 11:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=1.142, 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 KP0xorE1-NTQ for ; Mon, 6 Oct 2008 11:40:15 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 7EB2A28C116 for ; Mon, 6 Oct 2008 11:40:12 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA05287; Mon, 6 Oct 2008 14:39:49 -0400 (EDT) Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id OAA11535; Mon, 6 Oct 2008 14:39:49 -0400 (EDT) Date: Mon, 6 Oct 2008 14:39:49 -0400 (EDT) From: Alan Luchuk Message-Id: <200810061839.OAA11535@adminfs.snmp.com> To: netconf@ietf.org Subject: [Netconf] Questions about draft-ietf-netconf-tls-04.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: , 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 Hello, Regarding NETCONF over TLS, I have two questions. If these questions have been answered already, would someone kindly point me to relevant information? RFC 4742 (NETCONF over SSH, Section 3.1) specifies a "framing sequence" to be inserted after each NETCONF message. Why is this framing sequence not needed or specified for NETCONF over TLS? It would seem that in either case, the transport layer (SSH or SSL) is simply a "data pipe", and that if a framing sequence is needed for SSH, it would also be needed for TLS. Making the framing sequence mandatory over SSH but not over TLS requires two slightly different software implementations. Second, when implementing a NETCONF server over TLS, how is a user identity derived for the purposes of data view access control? Although not specif- ically mentioned in RFC 4742, I believe such a user identity can be obtained from the process environment of the NETCONF server SSH subystem (on open systems, at least), based upon the username specified during the launch of the SSH client. Thanks in advance for any/all information! Regards, --Alan _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Oct 6 11:40:16 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 878DD28C116; Mon, 6 Oct 2008 11:40:16 -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 26C4228C0F1 for ; Mon, 6 Oct 2008 11:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=1.142, 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 KP0xorE1-NTQ for ; Mon, 6 Oct 2008 11:40:15 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 7EB2A28C116 for ; Mon, 6 Oct 2008 11:40:12 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA05287; Mon, 6 Oct 2008 14:39:49 -0400 (EDT) Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id OAA11535; Mon, 6 Oct 2008 14:39:49 -0400 (EDT) Date: Mon, 6 Oct 2008 14:39:49 -0400 (EDT) From: Alan Luchuk Message-Id: <200810061839.OAA11535@adminfs.snmp.com> To: netconf@ietf.org Subject: [Netconf] Questions about draft-ietf-netconf-tls-04.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: , 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 Hello, Regarding NETCONF over TLS, I have two questions. If these questions have been answered already, would someone kindly point me to relevant information? RFC 4742 (NETCONF over SSH, Section 3.1) specifies a "framing sequence" to be inserted after each NETCONF message. Why is this framing sequence not needed or specified for NETCONF over TLS? It would seem that in either case, the transport layer (SSH or SSL) is simply a "data pipe", and that if a framing sequence is needed for SSH, it would also be needed for TLS. Making the framing sequence mandatory over SSH but not over TLS requires two slightly different software implementations. Second, when implementing a NETCONF server over TLS, how is a user identity derived for the purposes of data view access control? Although not specif- ically mentioned in RFC 4742, I believe such a user identity can be obtained from the process environment of the NETCONF server SSH subystem (on open systems, at least), based upon the username specified during the launch of the SSH client. Thanks in advance for any/all information! Regards, --Alan _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Oct 6 12:40: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 636A028C18B; Mon, 6 Oct 2008 12:40: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 C2E583A6B15 for ; Mon, 6 Oct 2008 12:40:50 -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 6+oZJDxazkWB for ; Mon, 6 Oct 2008 12:40:46 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5BCBC28C135 for ; Mon, 6 Oct 2008 12:40:46 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 30620C0027; Mon, 6 Oct 2008 21:41:01 +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 iwoFn0OLWI4z; Mon, 6 Oct 2008 21:40:54 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D27D0C0021; Mon, 6 Oct 2008 21:40:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D3D2D7E8311; Mon, 6 Oct 2008 21:40:54 +0200 (CEST) Date: Mon, 6 Oct 2008 21:40:54 +0200 From: Juergen Schoenwaelder To: Alan Luchuk Message-ID: <20081006194054.GA1881@elstar.local> Mail-Followup-To: Alan Luchuk , netconf@ietf.org References: <200810061839.OAA11535@adminfs.snmp.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200810061839.OAA11535@adminfs.snmp.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Questions about draft-ietf-netconf-tls-04.txt 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, Oct 06, 2008 at 02:39:49PM -0400, Alan Luchuk wrote: > Hello, > > Regarding NETCONF over TLS, I have two questions. If these questions > have been answered already, would someone kindly point me to relevant > information? > > RFC 4742 (NETCONF over SSH, Section 3.1) specifies a "framing sequence" > to be inserted after each NETCONF message. Why is this framing sequence > not needed or specified for NETCONF over TLS? It would seem that in either > case, the transport layer (SSH or SSL) is simply a "data pipe", and that > if a framing sequence is needed for SSH, it would also be needed for TLS. > Making the framing sequence mandatory over SSH but not over TLS requires > two slightly different software implementations. See the last paragraph in section 2.1 for an answer. > Second, when implementing a NETCONF server over TLS, how is a user identity > derived for the purposes of data view access control? Although not specif- > ically mentioned in RFC 4742, I believe such a user identity can be obtained > from the process environment of the NETCONF server SSH subystem (on open > systems, at least), based upon the username specified during the launch of > the SSH client. NETCONF does not (yet?) have access control and hence the question can probably be postponed (I think all NETCONF transports are silent how a name for the authenticated client is derived for authorization purposes - although for some transports the answer might be pretty obvious). Using the local user identity does not make much sense to me; you want something that is linked to the authenticated identity of the NETCONF client, e.g. a name derived from a certificate. ISMS is facing similar questions, although SNMP over TLS/DTLS is not an ISMS work item so far (but there are IDs about these transports). /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 Oct 6 12:40: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 636A028C18B; Mon, 6 Oct 2008 12:40: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 C2E583A6B15 for ; Mon, 6 Oct 2008 12:40:50 -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 6+oZJDxazkWB for ; Mon, 6 Oct 2008 12:40:46 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5BCBC28C135 for ; Mon, 6 Oct 2008 12:40:46 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 30620C0027; Mon, 6 Oct 2008 21:41:01 +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 iwoFn0OLWI4z; Mon, 6 Oct 2008 21:40:54 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D27D0C0021; Mon, 6 Oct 2008 21:40:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D3D2D7E8311; Mon, 6 Oct 2008 21:40:54 +0200 (CEST) Date: Mon, 6 Oct 2008 21:40:54 +0200 From: Juergen Schoenwaelder To: Alan Luchuk Message-ID: <20081006194054.GA1881@elstar.local> Mail-Followup-To: Alan Luchuk , netconf@ietf.org References: <200810061839.OAA11535@adminfs.snmp.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200810061839.OAA11535@adminfs.snmp.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Questions about draft-ietf-netconf-tls-04.txt 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, Oct 06, 2008 at 02:39:49PM -0400, Alan Luchuk wrote: > Hello, > > Regarding NETCONF over TLS, I have two questions. If these questions > have been answered already, would someone kindly point me to relevant > information? > > RFC 4742 (NETCONF over SSH, Section 3.1) specifies a "framing sequence" > to be inserted after each NETCONF message. Why is this framing sequence > not needed or specified for NETCONF over TLS? It would seem that in either > case, the transport layer (SSH or SSL) is simply a "data pipe", and that > if a framing sequence is needed for SSH, it would also be needed for TLS. > Making the framing sequence mandatory over SSH but not over TLS requires > two slightly different software implementations. See the last paragraph in section 2.1 for an answer. > Second, when implementing a NETCONF server over TLS, how is a user identity > derived for the purposes of data view access control? Although not specif- > ically mentioned in RFC 4742, I believe such a user identity can be obtained > from the process environment of the NETCONF server SSH subystem (on open > systems, at least), based upon the username specified during the launch of > the SSH client. NETCONF does not (yet?) have access control and hence the question can probably be postponed (I think all NETCONF transports are silent how a name for the authenticated client is derived for authorization purposes - although for some transports the answer might be pretty obvious). Using the local user identity does not make much sense to me; you want something that is linked to the authenticated identity of the NETCONF client, e.g. a name derived from a certificate. ISMS is facing similar questions, although SNMP over TLS/DTLS is not an ISMS work item so far (but there are IDs about these transports). /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 Wed Oct 8 11:53: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 C32553A68C6; Wed, 8 Oct 2008 11:53: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 F3FE43A68C6 for ; Wed, 8 Oct 2008 11:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.943 X-Spam-Level: X-Spam-Status: No, score=-0.943 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_05=-1.11, 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 A7aOaxs35TKM for ; Wed, 8 Oct 2008 11:53:53 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id E78023A6801 for ; Wed, 8 Oct 2008 11:53:52 -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 m98JsDWh151766 for ; Wed, 8 Oct 2008 20:54:15 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Wed, 8 Oct 2008 20:52:39 +0200 (CEST) Message-ID: <62919.88.164.98.77.1223491959.squirrel@www.isima.fr> In-Reply-To: <56653.88.164.98.77.1222885530.squirrel@www.isima.fr> References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr><00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <000c01c923aa$054cc6e0$0601a8c0@allison> <55201.88.164.98.77.1222865792.squirrel@www.isima.fr> <001901c923e5$9b2d73e0$0601a8c0@allison> <56653.88.164.98.77.1222885530.squirrel@www.isima.fr> Date: Wed, 8 Oct 2008 20:52:39 +0200 (CEST) From: badra@isima.fr To: netconf@ietf.org 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]); Wed, 08 Oct 2008 20:54:15 +0100 (WEST) Subject: [Netconf] system or registered port for Netconf over TLS (was WGLC for draft-ietf-netconf-tls-04.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear all, During the syslog WGLC of syslog-tls, there was a discussion about the use of a registered or a system port for the initial version of syslog over TLS. The consensus was that a dedicated port should be requested. Regarding "Netconf over TLS" document: On the one hand, some Netconf WG members recommended reviewing the discussion in the syslog WG to see whether the compliance requirements for "Netconf over TLS" are consistent with the syslog-tls proposal, which uses a registered port. On the other hand, the Netconf WG already assigned system ports for NetConf over SSH, SOAP and BEEP and the question is why to don't use a system port for TLS? The question for the WG to reach a consensus is: do we need a system port or just a registered port for "Netconf over TLS"? Please express you preference on the list for one of these two options by the WGLC deadline. As a contributor and author, I'd vote for a registered port. Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Oct 8 11:53: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 C32553A68C6; Wed, 8 Oct 2008 11:53: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 F3FE43A68C6 for ; Wed, 8 Oct 2008 11:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.943 X-Spam-Level: X-Spam-Status: No, score=-0.943 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_05=-1.11, 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 A7aOaxs35TKM for ; Wed, 8 Oct 2008 11:53:53 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id E78023A6801 for ; Wed, 8 Oct 2008 11:53:52 -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 m98JsDWh151766 for ; Wed, 8 Oct 2008 20:54:15 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Wed, 8 Oct 2008 20:52:39 +0200 (CEST) Message-ID: <62919.88.164.98.77.1223491959.squirrel@www.isima.fr> In-Reply-To: <56653.88.164.98.77.1222885530.squirrel@www.isima.fr> References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr><00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <000c01c923aa$054cc6e0$0601a8c0@allison> <55201.88.164.98.77.1222865792.squirrel@www.isima.fr> <001901c923e5$9b2d73e0$0601a8c0@allison> <56653.88.164.98.77.1222885530.squirrel@www.isima.fr> Date: Wed, 8 Oct 2008 20:52:39 +0200 (CEST) From: badra@isima.fr To: netconf@ietf.org 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]); Wed, 08 Oct 2008 20:54:15 +0100 (WEST) Subject: [Netconf] system or registered port for Netconf over TLS (was WGLC for draft-ietf-netconf-tls-04.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear all, During the syslog WGLC of syslog-tls, there was a discussion about the use of a registered or a system port for the initial version of syslog over TLS. The consensus was that a dedicated port should be requested. Regarding "Netconf over TLS" document: On the one hand, some Netconf WG members recommended reviewing the discussion in the syslog WG to see whether the compliance requirements for "Netconf over TLS" are consistent with the syslog-tls proposal, which uses a registered port. On the other hand, the Netconf WG already assigned system ports for NetConf over SSH, SOAP and BEEP and the question is why to don't use a system port for TLS? The question for the WG to reach a consensus is: do we need a system port or just a registered port for "Netconf over TLS"? Please express you preference on the list for one of these two options by the WGLC deadline. As a contributor and author, I'd vote for a registered port. Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Oct 8 18:12:06 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 969D43A6C1C; Wed, 8 Oct 2008 18:12:06 -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 5F1253A6C1C for ; Wed, 8 Oct 2008 18:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] 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 FRQokYV98oEL for ; Wed, 8 Oct 2008 18:12:04 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 97D393A6896 for ; Wed, 8 Oct 2008 18:12:04 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8G002QL618FF@usaga01-in.huawei.com> for netconf@ietf.org; Wed, 08 Oct 2008 18:12:44 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8G00FOJ617TA@usaga01-in.huawei.com> for netconf@ietf.org; Wed, 08 Oct 2008 18:12:44 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Thu, 09 Oct 2008 09:12:25 +0800 Date: Thu, 09 Oct 2008 09:12:25 +0800 From: fanhuaxiang 90002624 In-reply-to: <62919.88.164.98.77.1223491959.squirrel@www.isima.fr> To: badra@isima.fr Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr> <00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <000c01c923aa$054cc6e0$0601a8c0@allison> <55201.88.164.98.77.1222865792.squirrel@www.isima.fr> <001901c923e5$9b2d73e0$0601a8c0@allison> <56653.88.164.98.77.1222885530.squirrel@www.isima.fr> <62919.88.164.98.77.1223491959.squirrel@www.isima.fr> Cc: netconf@ietf.org Subject: Re: [Netconf] system or registered port for Netconf over TLS (was WGLC for draft-ietf-netconf-tls-04.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, could anybody tell me what is the exact difference between system port and registered port.what is the qualification for applications to hire system port or registered port? If we figure it out, it is easy to conclude 'netconf over TLS' suiable to system port or registered port. washam ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whosFrom netconf-bounces@ietf.org Wed Oct 8 18:12:06 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 969D43A6C1C; Wed, 8 Oct 2008 18:12:06 -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 5F1253A6C1C for ; Wed, 8 Oct 2008 18:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] 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 FRQokYV98oEL for ; Wed, 8 Oct 2008 18:12:04 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 97D393A6896 for ; Wed, 8 Oct 2008 18:12:04 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8G002QL618FF@usaga01-in.huawei.com> for netconf@ietf.org; Wed, 08 Oct 2008 18:12:44 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8G00FOJ617TA@usaga01-in.huawei.com> for netconf@ietf.org; Wed, 08 Oct 2008 18:12:44 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Thu, 09 Oct 2008 09:12:25 +0800 Date: Thu, 09 Oct 2008 09:12:25 +0800 From: fanhuaxiang 90002624 In-reply-to: <62919.88.164.98.77.1223491959.squirrel@www.isima.fr> To: badra@isima.fr Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr> <00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <000c01c923aa$054cc6e0$0601a8c0@allison> <55201.88.164.98.77.1222865792.squirrel@www.isima.fr> <001901c923e5$9b2d73e0$0601a8c0@allison> <56653.88.164.98.77.1222885530.squirrel@www.isima.fr> <62919.88.164.98.77.1223491959.squirrel@www.isima.fr> Cc: netconf@ietf.org Subject: Re: [Netconf] system or registered port for Netconf over TLS (was WGLC for draft-ietf-netconf-tls-04.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, could anybody tell me what is the exact difference between system port and registered port.what is the qualification for applications to hire system port or registered port? If we figure it out, it is easy to conclude 'netconf over TLS' suiable to system port or registered port. washam ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** ----- Original Message ----- From: badra@isima.fr Date: Thursday, October 9, 2008 2:54 am Subject: [Netconf] system or registered port for Netconf over TLS (was WGLC for draft-ietf-netconf-tls-04.txt) To: netconf@ietf.org > Dear all, > > During the syslog WGLC of syslog-tls, there was a discussion about > the use > of a registered or a system port for the initial version of syslog > overTLS. The consensus was that a dedicated port should be requested. > > Regarding "Netconf over TLS" document: > > On the one hand, some Netconf WG members recommended reviewing the > discussion in the syslog WG to see whether the compliance > requirements for > "Netconf over TLS" are consistent with the syslog-tls proposal, > which uses > a registered port. > > On the other hand, the Netconf WG already assigned system ports for > NetConf over SSH, SOAP and BEEP and the question is why to don't > use a > system port for TLS? > > The question for the WG to reach a consensus is: do we need a > system port > or just a registered port for "Netconf over TLS"? > > Please express you preference on the list for one of these two > options by > the WGLC deadline. > > As a contributor and author, I'd vote for a registered port. > 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 e address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** ----- Original Message ----- From: badra@isima.fr Date: Thursday, October 9, 2008 2:54 am Subject: [Netconf] system or registered port for Netconf over TLS (was WGLC for draft-ietf-netconf-tls-04.txt) To: netconf@ietf.org > Dear all, > > During the syslog WGLC of syslog-tls, there was a discussion about > the use > of a registered or a system port for the initial version of syslog > overTLS. The consensus was that a dedicated port should be requested. > > Regarding "Netconf over TLS" document: > > On the one hand, some Netconf WG members recommended reviewing the > discussion in the syslog WG to see whether the compliance > requirements for > "Netconf over TLS" are consistent with the syslog-tls proposal, > which uses > a registered port. > > On the other hand, the Netconf WG already assigned system ports for > NetConf over SSH, SOAP and BEEP and the question is why to don't > use a > system port for TLS? > > The question for the WG to reach a consensus is: do we need a > system port > or just a registered port for "Netconf over TLS"? > > Please express you preference on the list for one of these two > options by > the WGLC deadline. > > As a contributor and author, I'd vote for a registered port. > 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 Thu Oct 9 01:41: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 6EF333A6C5D; Thu, 9 Oct 2008 01:41: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 112FF3A6C5D for ; Thu, 9 Oct 2008 01:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.381 X-Spam-Level: X-Spam-Status: No, score=-1.381 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_44=0.6] 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 N2NrHm-N5gxh for ; Thu, 9 Oct 2008 01:41:47 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 297F83A692B for ; Thu, 9 Oct 2008 01:41:47 -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 m999g4OT782562; Thu, 9 Oct 2008 10:42:05 +0100 Message-ID: <48EDC3A3.7090303@isima.fr> Date: Thu, 09 Oct 2008 10:41:07 +0200 From: Mohamad Badra User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: fanhuaxiang 90002624 References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr> <00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <000c01c923aa$054cc6e0$0601a8c0@allison> <55201.88.164.98.77.1222865792.squirrel@www.isima.fr> <001901c923e5$9b2d73e0$0601a8c0@allison> <56653.88.164.98.77.1222885530.squirrel@www.isima.fr> <62919.88.164.98.77.1223491959.squirrel@www.isima.fr> In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Thu, 09 Oct 2008 10:42:05 +0100 (WEST) Cc: netconf@ietf.org Subject: Re: [Netconf] system or registered port for Netconf over TLS (was WGLC for draft-ietf-netconf-tls-04.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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org fanhuaxiang 90002624 a =E9crit : > Hi, > could anybody tell me what is the exact difference between system port an= d registered port.what is the qualification for applications to hire system= port or registered port? > If we figure it out, it is easy to conclude 'netconf over TLS' suiable to= system port or registered port. See RFC4340 section 19.9 Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Oct 9 01:41: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 6EF333A6C5D; Thu, 9 Oct 2008 01:41: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 112FF3A6C5D for ; Thu, 9 Oct 2008 01:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.381 X-Spam-Level: X-Spam-Status: No, score=-1.381 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_44=0.6] 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 N2NrHm-N5gxh for ; Thu, 9 Oct 2008 01:41:47 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 297F83A692B for ; Thu, 9 Oct 2008 01:41:47 -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 m999g4OT782562; Thu, 9 Oct 2008 10:42:05 +0100 Message-ID: <48EDC3A3.7090303@isima.fr> Date: Thu, 09 Oct 2008 10:41:07 +0200 From: Mohamad Badra User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: fanhuaxiang 90002624 References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr> <00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <000c01c923aa$054cc6e0$0601a8c0@allison> <55201.88.164.98.77.1222865792.squirrel@www.isima.fr> <001901c923e5$9b2d73e0$0601a8c0@allison> <56653.88.164.98.77.1222885530.squirrel@www.isima.fr> <62919.88.164.98.77.1223491959.squirrel@www.isima.fr> In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Thu, 09 Oct 2008 10:42:05 +0100 (WEST) Cc: netconf@ietf.org Subject: Re: [Netconf] system or registered port for Netconf over TLS (was WGLC for draft-ietf-netconf-tls-04.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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org fanhuaxiang 90002624 a =E9crit : > Hi, > could anybody tell me what is the exact difference between system port an= d registered port.what is the qualification for applications to hire system= port or registered port? > If we figure it out, it is easy to conclude 'netconf over TLS' suiable to= system port or registered port. See RFC4340 section 19.9 Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Oct 9 03:48: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 E8A583A6A94; Thu, 9 Oct 2008 03:48:05 -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 A02023A6A94 for ; Thu, 9 Oct 2008 03:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 INzj6GpUiR84 for ; Thu, 9 Oct 2008 03:48:03 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id DC74A3A685F for ; Thu, 9 Oct 2008 03:48:03 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id Qa611a0070x6nqcA6aoRXA; Thu, 09 Oct 2008 10:48:25 +0000 Received: from Harrington73653 ([208.253.76.35]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id QaoA1a0080lhtQY8YaoEL5; Thu, 09 Oct 2008 10:48:22 +0000 X-Authority-Analysis: v=1.0 c=1 a=YQxm6uH_KtcA:10 a=_3YH8YR2ol0A:10 a=48vgC7mUAAAA:8 a=WTGME3_0_00p9C6mehsA:9 a=7Ogjk_sxRTgCHLufkjQA:7 a=j5pyDEzMNROwISSAxTgOX9yxF9oA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr><00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com><61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <000c01c923aa$054cc6e0$0601a8c0@allison> <55201.88.164.98.77.1222865792.squirrel@www.isima.fr> <001901c923e5$9b2d73e0$0601a8c0@allison><56653.88.164.98.77.1222885530.squirrel@www.isima.fr> <62919.88.164.98.77.1223491959.squirrel@www.isima.fr> Date: Thu, 9 Oct 2008 06:48:09 -0400 Message-ID: <001d01c929fc$8c03b380$efa911ac@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <62919.88.164.98.77.1223491959.squirrel@www.isima.fr> Thread-Index: Ackpd1H6atZLKp0ERs2qz76nQNaamAAhQ8Ug X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Netconf] system or registered port for Netconf over TLS (was WGLC for draft-ietf-netconf-tls-04.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, you really don't need a system port. A registered port should suffice. And using a system port is likely to cause a DISCUSS by the IESG. dbh > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of badra@isima.fr > Sent: Wednesday, October 08, 2008 2:53 PM > To: netconf@ietf.org > Subject: [Netconf] system or registered port for Netconf over > TLS (was WGLC for draft-ietf-netconf-tls-04.txt) > > Dear all, > > During the syslog WGLC of syslog-tls, there was a discussion > about the use > of a registered or a system port for the initial version of > syslog over > TLS. The consensus was that a dedicated port should be requested. > > Regarding "Netconf over TLS" document: > > On the one hand, some Netconf WG members recommended reviewing the > discussion in the syslog WG to see whether the compliance > requirements for > "Netconf over TLS" are consistent with the syslog-tls > proposal, which uses > a registered port. > > On the other hand, the Netconf WG already assigned system ports for > NetConf over SSH, SOAP and BEEP and the question is why to don't use a > system port for TLS? > > The question for the WG to reach a consensus is: do we need a > system port > or just a registered port for "Netconf over TLS"? > > Please express you preference on the list for one of these > two options by > the WGLC deadline. > > As a contributor and author, I'd vote for a registered port. > 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 Thu Oct 9 03:48: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 E8A583A6A94; Thu, 9 Oct 2008 03:48:05 -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 A02023A6A94 for ; Thu, 9 Oct 2008 03:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 INzj6GpUiR84 for ; Thu, 9 Oct 2008 03:48:03 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id DC74A3A685F for ; Thu, 9 Oct 2008 03:48:03 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id Qa611a0070x6nqcA6aoRXA; Thu, 09 Oct 2008 10:48:25 +0000 Received: from Harrington73653 ([208.253.76.35]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id QaoA1a0080lhtQY8YaoEL5; Thu, 09 Oct 2008 10:48:22 +0000 X-Authority-Analysis: v=1.0 c=1 a=YQxm6uH_KtcA:10 a=_3YH8YR2ol0A:10 a=48vgC7mUAAAA:8 a=WTGME3_0_00p9C6mehsA:9 a=7Ogjk_sxRTgCHLufkjQA:7 a=j5pyDEzMNROwISSAxTgOX9yxF9oA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr><00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com><61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <000c01c923aa$054cc6e0$0601a8c0@allison> <55201.88.164.98.77.1222865792.squirrel@www.isima.fr> <001901c923e5$9b2d73e0$0601a8c0@allison><56653.88.164.98.77.1222885530.squirrel@www.isima.fr> <62919.88.164.98.77.1223491959.squirrel@www.isima.fr> Date: Thu, 9 Oct 2008 06:48:09 -0400 Message-ID: <001d01c929fc$8c03b380$efa911ac@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <62919.88.164.98.77.1223491959.squirrel@www.isima.fr> Thread-Index: Ackpd1H6atZLKp0ERs2qz76nQNaamAAhQ8Ug X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Netconf] system or registered port for Netconf over TLS (was WGLC for draft-ietf-netconf-tls-04.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, you really don't need a system port. A registered port should suffice. And using a system port is likely to cause a DISCUSS by the IESG. dbh > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of badra@isima.fr > Sent: Wednesday, October 08, 2008 2:53 PM > To: netconf@ietf.org > Subject: [Netconf] system or registered port for Netconf over > TLS (was WGLC for draft-ietf-netconf-tls-04.txt) > > Dear all, > > During the syslog WGLC of syslog-tls, there was a discussion > about the use > of a registered or a system port for the initial version of > syslog over > TLS. The consensus was that a dedicated port should be requested. > > Regarding "Netconf over TLS" document: > > On the one hand, some Netconf WG members recommended reviewing the > discussion in the syslog WG to see whether the compliance > requirements for > "Netconf over TLS" are consistent with the syslog-tls > proposal, which uses > a registered port. > > On the other hand, the Netconf WG already assigned system ports for > NetConf over SSH, SOAP and BEEP and the question is why to don't use a > system port for TLS? > > The question for the WG to reach a consensus is: do we need a > system port > or just a registered port for "Netconf over TLS"? > > Please express you preference on the list for one of these > two options by > the WGLC deadline. > > As a contributor and author, I'd vote for a registered port. > 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 Thu Oct 9 08:08: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 33FDD3A69B9; Thu, 9 Oct 2008 08:08: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 F0D8C3A683D for ; Thu, 9 Oct 2008 08:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.966 X-Spam-Level: X-Spam-Status: No, score=-4.966 tagged_above=-999 required=5 tests=[AWL=1.033, BAYES_00=-2.599, J_CHICKENPOX_44=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 xBqEoNLeuKh9 for ; Thu, 9 Oct 2008 08:08:17 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id DDFCF3A69B9 for ; Thu, 9 Oct 2008 08:08:16 -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 m99F82wu009148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Oct 2008 17:08:02 +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 m99F825q008067; Thu, 9 Oct 2008 17:08:02 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Oct 2008 17:08:02 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 9 Oct 2008 17:07:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] system or registered port for Netconf over TLS (was WGLC for draft-ietf-netconf-tls-04.txt) Thread-Index: AckprCaJSAVXD6seReCSNeqBGfgnpQAYkKSAAASPmAA= From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 09 Oct 2008 15:08:02.0924 (UTC) FILETIME=[D34EB2C0:01C92A20] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081009170802-40306BB0-63895983/0-0/0-15 X-purgate-size: 3308/0 Cc: netconf@ietf.org Subject: [Netconf] FW: system or registered port for Netconf over TLS (was WGLC for draft-ietf-netconf-tls-04.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Washam, the answer to the question is on the IANA web site. Please check: http://www.iana.org/protocols/apply/ Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext > fanhuaxiang 90002624 > Sent: Thursday, October 09, 2008 3:12 AM > To: badra@isima.fr > Cc: netconf@ietf.org > Subject: Re: [Netconf] system or registered port for Netconf > over TLS (was WGLC for draft-ietf-netconf-tls-04.txt) > > Hi, > could anybody tell me what is the exact difference between > system port and registered port.what is the qualification for > applications to hire system port or registered port? > If we figure it out, it is easy to conclude 'netconf over > TLS' suiable to system port or registered port. > > washam > > ************************************************************** > **************************** > This email and its attachments contain confidential > information from HUAWEI, which is intended only for the > person or entity whose address is listed above. Any use of > the information contained here in any way (including, but not > limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this email in > error, please notify the sender by phone or email immediately > and delete it! > > ************************************************************** > *************************** > > ----- Original Message ----- > From: badra@isima.fr > Date: Thursday, October 9, 2008 2:54 am > Subject: [Netconf] system or registered port for Netconf over > TLS (was WGLC for draft-ietf-netconf-tls-04.txt) > To: netconf@ietf.org > > > Dear all, > > > > During the syslog WGLC of syslog-tls, there was a discussion about > > the use > > of a registered or a system port for the initial version of syslog > > overTLS. The consensus was that a dedicated port should be > requested. > > > > Regarding "Netconf over TLS" document: > > > > On the one hand, some Netconf WG members recommended reviewing the > > discussion in the syslog WG to see whether the compliance > > requirements for > > "Netconf over TLS" are consistent with the syslog-tls proposal, > > which uses > > a registered port. > > > > On the other hand, the Netconf WG already assigned system ports for > > NetConf over SSH, SOAP and BEEP and the question is why to don't > > use a > > system port for TLS? > > > > The question for the WG to reach a consensus is: do we need a > > system port > > or just a registered port for "Netconf over TLS"? > > > > Please express you preference on the list for one of these two > > options by > > the WGLC deadline. > > > > As a contributor and author, I'd vote for a registered port. > > 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 > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Oct 9 08:08: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 33FDD3A69B9; Thu, 9 Oct 2008 08:08: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 F0D8C3A683D for ; Thu, 9 Oct 2008 08:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.966 X-Spam-Level: X-Spam-Status: No, score=-4.966 tagged_above=-999 required=5 tests=[AWL=1.033, BAYES_00=-2.599, J_CHICKENPOX_44=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 xBqEoNLeuKh9 for ; Thu, 9 Oct 2008 08:08:17 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id DDFCF3A69B9 for ; Thu, 9 Oct 2008 08:08:16 -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 m99F82wu009148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Oct 2008 17:08:02 +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 m99F825q008067; Thu, 9 Oct 2008 17:08:02 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Oct 2008 17:08:02 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 9 Oct 2008 17:07:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] system or registered port for Netconf over TLS (was WGLC for draft-ietf-netconf-tls-04.txt) Thread-Index: AckprCaJSAVXD6seReCSNeqBGfgnpQAYkKSAAASPmAA= From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 09 Oct 2008 15:08:02.0924 (UTC) FILETIME=[D34EB2C0:01C92A20] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081009170802-40306BB0-63895983/0-0/0-15 X-purgate-size: 3308/0 Cc: netconf@ietf.org Subject: [Netconf] FW: system or registered port for Netconf over TLS (was WGLC for draft-ietf-netconf-tls-04.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Washam, the answer to the question is on the IANA web site. Please check: http://www.iana.org/protocols/apply/ Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext > fanhuaxiang 90002624 > Sent: Thursday, October 09, 2008 3:12 AM > To: badra@isima.fr > Cc: netconf@ietf.org > Subject: Re: [Netconf] system or registered port for Netconf > over TLS (was WGLC for draft-ietf-netconf-tls-04.txt) > > Hi, > could anybody tell me what is the exact difference between > system port and registered port.what is the qualification for > applications to hire system port or registered port? > If we figure it out, it is easy to conclude 'netconf over > TLS' suiable to system port or registered port. > > washam > > ************************************************************** > **************************** > This email and its attachments contain confidential > information from HUAWEI, which is intended only for the > person or entity whose address is listed above. Any use of > the information contained here in any way (including, but not > limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this email in > error, please notify the sender by phone or email immediately > and delete it! > > ************************************************************** > *************************** > > ----- Original Message ----- > From: badra@isima.fr > Date: Thursday, October 9, 2008 2:54 am > Subject: [Netconf] system or registered port for Netconf over > TLS (was WGLC for draft-ietf-netconf-tls-04.txt) > To: netconf@ietf.org > > > Dear all, > > > > During the syslog WGLC of syslog-tls, there was a discussion about > > the use > > of a registered or a system port for the initial version of syslog > > overTLS. The consensus was that a dedicated port should be > requested. > > > > Regarding "Netconf over TLS" document: > > > > On the one hand, some Netconf WG members recommended reviewing the > > discussion in the syslog WG to see whether the compliance > > requirements for > > "Netconf over TLS" are consistent with the syslog-tls proposal, > > which uses > > a registered port. > > > > On the other hand, the Netconf WG already assigned system ports for > > NetConf over SSH, SOAP and BEEP and the question is why to don't > > use a > > system port for TLS? > > > > The question for the WG to reach a consensus is: do we need a > > system port > > or just a registered port for "Netconf over TLS"? > > > > Please express you preference on the list for one of these two > > options by > > the WGLC deadline. > > > > As a contributor and author, I'd vote for a registered port. > > 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 > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Oct 13 21:49: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 549AD3A6B6C; Mon, 13 Oct 2008 21:49: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 025C23A6BCA for ; Mon, 13 Oct 2008 21:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 Ku6a66i4TVYP for ; Mon, 13 Oct 2008 21:49:54 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id BCC8E3A6BA4 for ; Mon, 13 Oct 2008 21:49:53 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8P00G7WPFSXI@usaga01-in.huawei.com> for netconf@ietf.org; Mon, 13 Oct 2008 21:50:16 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8P001TZPFRJI@usaga01-in.huawei.com> for netconf@ietf.org; Mon, 13 Oct 2008 21:50:16 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Tue, 14 Oct 2008 12:49:57 +0800 Date: Tue, 14 Oct 2008 12:49:57 +0800 From: fanhuaxiang 90002624 To: netconf@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal Subject: [Netconf] [monitoring] is it monitoring a capability? 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, is it monitoring a capability, I can not find capability identifier about it. Regards, Washam _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Oct 13 21:49: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 549AD3A6B6C; Mon, 13 Oct 2008 21:49: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 025C23A6BCA for ; Mon, 13 Oct 2008 21:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 Ku6a66i4TVYP for ; Mon, 13 Oct 2008 21:49:54 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id BCC8E3A6BA4 for ; Mon, 13 Oct 2008 21:49:53 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8P00G7WPFSXI@usaga01-in.huawei.com> for netconf@ietf.org; Mon, 13 Oct 2008 21:50:16 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8P001TZPFRJI@usaga01-in.huawei.com> for netconf@ietf.org; Mon, 13 Oct 2008 21:50:16 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Tue, 14 Oct 2008 12:49:57 +0800 Date: Tue, 14 Oct 2008 12:49:57 +0800 From: fanhuaxiang 90002624 To: netconf@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal Subject: [Netconf] [monitoring] is it monitoring a capability? 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, is it monitoring a capability, I can not find capability identifier about it. Regards, Washam _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Oct 13 21:52: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 DA6BA3A6BCB; Mon, 13 Oct 2008 21:52: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 0D4F03A6BA8 for ; Mon, 13 Oct 2008 21:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 a3Oduv9QkSv2 for ; Mon, 13 Oct 2008 21:52:11 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id DE92C3A6BC6 for ; Mon, 13 Oct 2008 21:52:10 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8P00GF8PJGXI@usaga01-in.huawei.com> for netconf@ietf.org; Mon, 13 Oct 2008 21:52:29 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8P001XSPJFJI@usaga01-in.huawei.com> for netconf@ietf.org; Mon, 13 Oct 2008 21:52:28 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Tue, 14 Oct 2008 12:52:10 +0800 Date: Tue, 14 Oct 2008 12:52:10 +0800 From: fanhuaxiang 90002624 To: netconf@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal Subject: [Netconf] [partial-lock] privilege of partial-lock 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, partial-lock only allow a user on a session to operate in the same time, how about the same user with many sessions? since the scope of patial-lock cover some nodes and their subnodes, how about I lock and delete one node, and another people add it. the spec allow this to happen, does it lead to inconsistency? Regards, Washam ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Oct 13 21:52: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 DA6BA3A6BCB; Mon, 13 Oct 2008 21:52: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 0D4F03A6BA8 for ; Mon, 13 Oct 2008 21:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 a3Oduv9QkSv2 for ; Mon, 13 Oct 2008 21:52:11 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id DE92C3A6BC6 for ; Mon, 13 Oct 2008 21:52:10 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8P00GF8PJGXI@usaga01-in.huawei.com> for netconf@ietf.org; Mon, 13 Oct 2008 21:52:29 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8P001XSPJFJI@usaga01-in.huawei.com> for netconf@ietf.org; Mon, 13 Oct 2008 21:52:28 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Tue, 14 Oct 2008 12:52:10 +0800 Date: Tue, 14 Oct 2008 12:52:10 +0800 From: fanhuaxiang 90002624 To: netconf@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal Subject: [Netconf] [partial-lock] privilege of partial-lock 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, partial-lock only allow a user on a session to operate in the same time, how about the same user with many sessions? since the scope of patial-lock cover some nodes and their subnodes, how about I lock and delete one node, and another people add it. the spec allow this to happen, does it lead to inconsistency? Regards, Washam ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Oct 15 08:15: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 D8AF628C257; Wed, 15 Oct 2008 08:15: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 3B14B28C252 for ; Wed, 15 Oct 2008 08:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.014, 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 N9LmTAPLW5MO for ; Wed, 15 Oct 2008 08:15:05 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4FCDB3A6C6E for ; Wed, 15 Oct 2008 08:15:05 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 326DF200F4; Wed, 15 Oct 2008 17:15:47 +0200 (CEST) X-AuditID: c1b4fb3e-aae89bb000007a96-7a-48f609230e0e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 125F4206B6; Wed, 15 Oct 2008 17:15:47 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Oct 2008 17:15:46 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Oct 2008 17:15:46 +0200 Message-ID: <48F60922.2080806@ericsson.com> Date: Wed, 15 Oct 2008 17:15:46 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: fanhuaxiang 90002624 References: In-Reply-To: X-OriginalArrivalTime: 15 Oct 2008 15:15:46.0463 (UTC) FILETIME=[E613A2F0:01C92ED8] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] [partial-lock] privilege of partial-lock 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 Hello Washam, I am not sure I understood your question correctly, but still see my reply below: regards Balazs fanhuaxiang 90002624 wrote: > Hi, > partial-lock only allow a user on a session to operate in the same time, how about the same user with many sessions? BALAZS: A user can have multiple sessions, but partial-locks are connected to one specific session, the same way as global (RFC4741) locks. We wanted to follow the design of the global locks. Also this ensures that a lock is always released when a session terminates. If we connected the lock to a user, it would be harder to ensure that the lock is always released correctly, that a lock doesn't stay hanging. > since the scope of patial-lock cover some nodes and their subnodes, how about I lock and delete one node, and another people add it. the spec allow this to happen, does it lead to inconsistency? BAFrom netconf-bounces@ietf.org Wed Oct 15 08:15: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 D8AF628C257; Wed, 15 Oct 2008 08:15: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 3B14B28C252 for ; Wed, 15 Oct 2008 08:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.014, 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 N9LmTAPLW5MO for ; Wed, 15 Oct 2008 08:15:05 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4FCDB3A6C6E for ; Wed, 15 Oct 2008 08:15:05 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 326DF200F4; Wed, 15 Oct 2008 17:15:47 +0200 (CEST) X-AuditID: c1b4fb3e-aae89bb000007a96-7a-48f609230e0e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 125F4206B6; Wed, 15 Oct 2008 17:15:47 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Oct 2008 17:15:46 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Oct 2008 17:15:46 +0200 Message-ID: <48F60922.2080806@ericsson.com> Date: Wed, 15 Oct 2008 17:15:46 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: fanhuaxiang 90002624 References: In-Reply-To: X-OriginalArrivalTime: 15 Oct 2008 15:15:46.0463 (UTC) FILETIME=[E613A2F0:01C92ED8] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] [partial-lock] privilege of partial-lock 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 Hello Washam, I am not sure I understood your question correctly, but still see my reply below: regards Balazs fanhuaxiang 90002624 wrote: > Hi, > partial-lock only allow a user on a session to operate in the same time, how about the same user with many sessions? BALAZS: A user can have multiple sessions, but partial-locks are connected to one specific session, the same way as global (RFC4741) locks. We wanted to follow the design of the global locks. Also this ensures that a lock is always released when a session terminates. If we connected the lock to a user, it would be harder to ensure that the lock is always released correctly, that a lock doesn't stay hanging. > since the scope of patial-lock cover some nodes and their subnodes, how about I lock and delete one node, and another people add it. the spec allow this to happen, does it lead to inconsistenLAZS: Yes this can happen, and no we don't consider this as inconsistent. As described in the draft the user should lock the parent node of the object he wants to delete/create to avoid the situation you mention. We could have allowed locking not existing nodes, however that is also a somewhat surprising behavior. > > Regards, > Washam > ****************************************************************************************** > This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! > ***************************************************************************************** > _______________________________________________ > 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 cy? BALAZS: Yes this can happen, and no we don't consider this as inconsistent. As described in the draft the user should lock the parent node of the object he wants to delete/create to avoid the situation you mention. We could have allowed locking not existing nodes, however that is also a somewhat surprising behavior. > > Regards, > Washam > ****************************************************************************************** > This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! > ***************************************************************************************** > _______________________________________________ > 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 Oct 16 10:48: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 CD7493A6A04; Thu, 16 Oct 2008 10:48: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 0CD483A63D3 for ; Thu, 16 Oct 2008 10:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, 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 XiiVNKlDwC1m for ; Thu, 16 Oct 2008 10:48:16 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 3D2ED3A6A04 for ; Thu, 16 Oct 2008 10:48:16 -0700 (PDT) Received: (qmail 46327 invoked from network); 16 Oct 2008 17:49:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 16 Oct 2008 17:49:16 -0000 X-YMail-OSG: DVf.brAVM1k148dghoZHCiBtyTq55mnCtgRsgTHIEdz6uZmp6zXXUWHWLU0BsZHMZbg_XBHpfiRuvmF3E9Ns62iMujjHv63ozYcsF4pSRWp.nMZ8TbFL7cVdhevPJeCJKWE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48F77E9B.90705@netconfcentral.com> Date: Thu, 16 Oct 2008 10:49:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETCONF Subject: [Netconf] candidate config details 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 Hi, I'm looking closely at the NETCONF specs wrt/ the candidate config. It is not obvious from the text that anybody can invoke discard-changes and/or commit if locks are not used. The original session which neglected to use the lock will continue to write to the until another session locks it, and probably try to commit it as well. So use locking! And lock the candidate and running, plus startup if :startup capability advertised. The candidate lock controls edit-config and discard-changes. The running lock controls 'commit'. The startup lock controls 'copy-config to '. *** Questions about partial locking draft: *** If partial locking is used, and some dirty nodes are locked, but other dirty nodes are not, does a discard-changes by a 3rd party session work (a) at all, (b)only on the unlocked nodes, or (c) up to the agent to decide (a) or (b)? Same question for commit? *** Comments on partial locking draft: *** It may seem that the manager can ignore the config and just lock the subtree in the (since writes to the are not allowed). But if some other session takes out a a global or a partial lock covering your subtree, you control only the version, and can not commit your changes. Sec. 2.4.1, para 4 of partial-lock-03 says: A operation MUST be handled atomically by the NETCONF server. The server either locks all requested parts of the data store or none; I.e. if during the operation one of the requested parts cannot be locked the server MUST unlock all parts that have been already locked during that operation. Clearly, getting all the locks you need at once is important, and simplifies implementation for the manager. However, this is not supported in NETCONF or . IMO, the 'target' parameter should be a leaf-list, not a leaf. If not a leaf-list, then a 'bits' parameter, since the URL form is not allowed anyway. The most common use case is going to be a partial-lock of the same subtrees in both the and configs. Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Oct 16 10:48: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 CD7493A6A04; Thu, 16 Oct 2008 10:48: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 0CD483A63D3 for ; Thu, 16 Oct 2008 10:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, 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 XiiVNKlDwC1m for ; Thu, 16 Oct 2008 10:48:16 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 3D2ED3A6A04 for ; Thu, 16 Oct 2008 10:48:16 -0700 (PDT) Received: (qmail 46327 invoked from network); 16 Oct 2008 17:49:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 16 Oct 2008 17:49:16 -0000 X-YMail-OSG: DVf.brAVM1k148dghoZHCiBtyTq55mnCtgRsgTHIEdz6uZmp6zXXUWHWLU0BsZHMZbg_XBHpfiRuvmF3E9Ns62iMujjHv63ozYcsF4pSRWp.nMZ8TbFL7cVdhevPJeCJKWE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48F77E9B.90705@netconfcentral.com> Date: Thu, 16 Oct 2008 10:49:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: NETCONF Subject: [Netconf] candidate config details 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 Hi, I'm looking closely at the NETCONF specs wrt/ the candidate config. It is not obvious from the text that anybody can invoke discard-changes and/or commit if locks are not used. The original session which neglected to use the lock will continue to write to the until another session locks it, and probably try to commit it as well. So use locking! And lock the candidate and running, plus startup if :startup capability advertised. The candidate lock controls edit-config and discard-changes. The running lock controls 'commit'. The startup lock controls 'copy-config to '. *** Questions about partial locking draft: *** If partial locking is used, and some dirty nodes are locked, but other dirty nodes are not, does a discard-changes by a 3rd party session work (a) at all, (b)only on the unlocked nodes, or (c) up to the agent to decide (a) or (b)? Same question for commit? *** Comments on partial locking draft: *** It may seem that the manager can ignore the config and just lock the subtree in the (since writes to the are not allowed). But if some other session takes out a a global or a partial lock covering your subtree, you control only the version, and can not commit your changes. Sec. 2.4.1, para 4 of partial-lock-03 says: A operation MUST be handled atomically by the NETCONF server. The server either locks all requested parts of the data store or none; I.e. if during the operation one of the requested parts cannot be locked the server MUST unlock all parts that have been already locked during that operation. Clearly, getting all the locks you need at once is important, and simplifies implementation for the manager. However, this is not supported in NETCONF or . IMO, the 'target' parameter should be a leaf-list, not a leaf. If not a leaf-list, then a 'bits' parameter, since the URL form is not allowed anyway. The most common use case is going to be a partial-lock of the same subtrees in both the and configs. Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Oct 16 11:54: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 77E653A6A6B; Thu, 16 Oct 2008 11:54: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 2CCA53A684C for ; Thu, 16 Oct 2008 11:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 YDNvXqLDqCBz for ; Thu, 16 Oct 2008 11:54:46 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2D36E3A6A6B for ; Thu, 16 Oct 2008 11:54:46 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id D7E7176C314; Thu, 16 Oct 2008 20:55:46 +0200 (CEST) Date: Thu, 16 Oct 2008 20:55:46 +0200 (CEST) Message-Id: <20081016.205546.06745984.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48F77E9B.90705@netconfcentral.com> References: <48F77E9B.90705@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] candidate config details 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: > *** Questions about partial locking draft: *** > > If partial locking is used, and some dirty nodes are locked, > but other dirty nodes are not, does a discard-changes by > a 3rd party session work (a) at all, (b)only on the unlocked nodes, > or (c) up to the agent to decide (a) or (b)? It will not work, since discard-changes is supposed to completely reset the candidate, and the dirty locked nodes must not be modified. > Same question for commit? If some nodes are dirty in the candidate, and they are locked in running, then, by the same reasoning, a 3rd party session's commit will not succeed. I think you can view nodes that are locked as if you don't have access to them (while they are locked). > *** Comments on partial locking draft: *** > > It may seem that the manager can ignore the > config and just lock the subtree in the > (since writes to the are not allowed). > But if some other session takes out a a global or a partial > lock covering your subtree, you control only > the version, and can not commit your changes. Yes. We debated whether to put text about this in the draft or not; maybe we should be explicit about this (if it's not there already). > Sec. 2.4.1, para 4 of partial-lock-03 says: > > A operation MUST be handled atomically by the NETCONF > server. The server either locks all requested parts of the data > store or none; I.e. if during the operation one of the requested > parts cannot be locked the server MUST unlock all parts that have > been already locked during that operation. > > Clearly, getting all the locks you need at once is important, > and simplifies implementation for the manager. However, this > is not supported in NETCONF or . > > IMO, the 'target' parameter should be a leaf-list, not a leaf. > If not a leaf-list, then a 'bits' parameter, since the URL form > is not allowed anyway. Good idea! leaf-list is probably right. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Oct 16 11:54: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 77E653A6A6B; Thu, 16 Oct 2008 11:54: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 2CCA53A684C for ; Thu, 16 Oct 2008 11:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 YDNvXqLDqCBz for ; Thu, 16 Oct 2008 11:54:46 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2D36E3A6A6B for ; Thu, 16 Oct 2008 11:54:46 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id D7E7176C314; Thu, 16 Oct 2008 20:55:46 +0200 (CEST) Date: Thu, 16 Oct 2008 20:55:46 +0200 (CEST) Message-Id: <20081016.205546.06745984.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <48F77E9B.90705@netconfcentral.com> References: <48F77E9B.90705@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] candidate config details 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: > *** Questions about partial locking draft: *** > > If partial locking is used, and some dirty nodes are locked, > but other dirty nodes are not, does a discard-changes by > a 3rd party session work (a) at all, (b)only on the unlocked nodes, > or (c) up to the agent to decide (a) or (b)? It will not work, since discard-changes is supposed to completely reset the candidate, and the dirty locked nodes must not be modified. > Same question for commit? If some nodes are dirty in the candidate, and they are locked in running, then, by the same reasoning, a 3rd party session's commit will not succeed. I think you can view nodes that are locked as if you don't have access to them (while they are locked). > *** Comments on partial locking draft: *** > > It may seem that the manager can ignore the > config and just lock the subtree in the > (since writes to the are not allowed). > But if some other session takes out a a global or a partial > lock covering your subtree, you control only > the version, and can not commit your changes. Yes. We debated whether to put text about this in the draft or not; maybe we should be explicit about this (if it's not there already). > Sec. 2.4.1, para 4 of partial-lock-03 says: > > A operation MUST be handled atomically by the NETCONF > server. The server either locks all requested parts of the data > store or none; I.e. if during the operation one of the requested > parts cannot be locked the server MUST unlock all parts that have > been already locked during that operation. > > Clearly, getting all the locks you need at once is important, > and simplifies implementation for the manager. However, this > is not supported in NETCONF or . > > IMO, the 'target' parameter should be a leaf-list, not a leaf. > If not a leaf-list, then a 'bits' parameter, since the URL form > is not allowed anyway. Good idea! leaf-list is probably right. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Oct 17 15: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 3DED528C12F; Fri, 17 Oct 2008 15: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 B717C28C0FD; Fri, 17 Oct 2008 15:30: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: <20081017223001.B717C28C0FD@core3.amsl.com> Date: Fri, 17 Oct 2008 15:30:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-tls-05.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-05.txt Pages : 9 Date : 2008-10-17 The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-05.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-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-17152225.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 Oct 17 15: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 3DED528C12F; Fri, 17 Oct 2008 15: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 B717C28C0FD; Fri, 17 Oct 2008 15:30: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: <20081017223001.B717C28C0FD@core3.amsl.com> Date: Fri, 17 Oct 2008 15:30:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-tls-05.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-05.txt Pages : 9 Date : 2008-10-17 The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-05.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-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-17152225.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 Oct 17 15:33:29 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 3A7E43A6B15; Fri, 17 Oct 2008 15:33:29 -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 2DE2C28C15E for ; Fri, 17 Oct 2008 15:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_20=-0.74, 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 F3Hz3MwyR0Ah for ; Fri, 17 Oct 2008 15:33:27 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 329973A6897 for ; Fri, 17 Oct 2008 15:33:27 -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 m9HNYTuF897124 for ; Sat, 18 Oct 2008 00:34:29 +0100 Received: from 88.175.65.115 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Sat, 18 Oct 2008 00:34:24 +0200 (CEST) Message-ID: <56055.88.175.65.115.1224282864.squirrel@www.isima.fr> Date: Sat, 18 Oct 2008 00:34:24 +0200 (CEST) From: badra@isima.fr To: netconf@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20081018003424_55744" X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Sat, 18 Oct 2008 00:34:30 +0100 (WEST) Subject: [Netconf] New version of draft-ietf-netconf-tls 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 ------=_20081018003424_55744 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Dear all, After the WGLC, I posted a revised version of draft-ietf-netconf-tls, which addresses comments and issues raised during the WGLC. Below is a summary of changes, please don't hesitate to read the document and send your comments on any missed point. Changes from -04 Removed any text related to PSK based authentication. Revised to TLS with certificate-based mutual authentication. Removed Cipher Suite Requirements section which was redundant with TLS. Added small clarifications to the "Introduction" and "Endpoint Authentication and Identification" sections. Section 2.1: Included mandatory to implement cipher suites that track future versions of the TLS Section 2.2: Revised the connection closure session with regards to TLS 1.2 Section 5: Revised to help IANA with the port assignment. Section 8: Removed RFC4086 and RFC4279 from the reference section A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-05.txt Best regards, Badra ------=_20081018003424_55744 Content-Type: message/external-body; name="draft-ietf-netconf-tls-05.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="draft-ietf-netconf-tls-05.txt" Content-Type: text/plain Content-ID: <2008-10-17152225.I-D@ietf.org> ------=_20081018003424_55744 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 ------=_20081018003424_55744-- From netconf-bounces@ietf.org Fri Oct 17 15:33:29 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 3A7E43A6B15; Fri, 17 Oct 2008 15:33:29 -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 2DE2C28C15E for ; Fri, 17 Oct 2008 15:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_20=-0.74, 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 F3Hz3MwyR0Ah for ; Fri, 17 Oct 2008 15:33:27 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 329973A6897 for ; Fri, 17 Oct 2008 15:33:27 -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 m9HNYTuF897124 for ; Sat, 18 Oct 2008 00:34:29 +0100 Received: from 88.175.65.115 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Sat, 18 Oct 2008 00:34:24 +0200 (CEST) Message-ID: <56055.88.175.65.115.1224282864.squirrel@www.isima.fr> Date: Sat, 18 Oct 2008 00:34:24 +0200 (CEST) From: badra@isima.fr To: netconf@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20081018003424_55744" X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Sat, 18 Oct 2008 00:34:30 +0100 (WEST) Subject: [Netconf] New version of draft-ietf-netconf-tls 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 ------=_20081018003424_55744 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Dear all, After the WGLC, I posted a revised version of draft-ietf-netconf-tls, which addresses comments and issues raised during the WGLC. Below is a summary of changes, please don't hesitate to read the document and send your comments on any missed point. Changes from -04 Removed any text related to PSK based authentication. Revised to TLS with certificate-based mutual authentication. Removed Cipher Suite Requirements section which was redundant with TLS. Added small clarifications to the "Introduction" and "Endpoint Authentication and Identification" sections. Section 2.1: Included mandatory to implement cipher suites that track future versions of the TLS Section 2.2: Revised the connection closure session with regards to TLS 1.2 Section 5: Revised to help IANA with the port assignment. Section 8: Removed RFC4086 and RFC4279 from the reference section A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-05.txt Best regards, Badra ------=_20081018003424_55744 Content-Type: message/external-body; name="draft-ietf-netconf-tls-05.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="draft-ietf-netconf-tls-05.txt" Content-Type: text/plain Content-ID: <2008-10-17152225.I-D@ietf.org> ------=_20081018003424_55744 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 ------=_20081018003424_55744-- From netconf-bounces@ietf.org Sat Oct 18 19:44: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 44F7E3A69FE; Sat, 18 Oct 2008 19:44: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 81E6F3A6A08 for ; Sat, 18 Oct 2008 19:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] 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 2rNOJq7Y5sx4 for ; Sat, 18 Oct 2008 19:44:51 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 9867F3A69FE for ; Sat, 18 Oct 2008 19:44:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=FcdmvUCFZFw0f26ilXFP9R7ls5LhMT227uV2fgemt45bWJ5TeW9y6AbXzzxoicwx; 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 [69.3.25.176] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KrOIp-0002P9-BW for netconf@ietf.org; Sat, 18 Oct 2008 22:45:59 -0400 Message-ID: <000401c93194$ecc4a180$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <62034.88.164.98.77.1223317108.squirrel@www.isima.fr> Date: Sat, 18 Oct 2008 19:46:43 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e4d93c93d116ec7c6485b6a7e28594e64f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.25.176 Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt: Connection Closure 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: > To: > Sent: Monday, October 06, 2008 11:18 AM > Subject: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt: Connection Closure > > Dear all, > > Below is a new tentative to agree on the text related to the Section > 'Connection Closure'. The text is much closed to Section 4.4 of > draft-ietf-syslog-transport-tls-14 with one exception; in Netconf, both > the agent and the manager may send data. > > A TLS client (NETCONF manager) MUST close the associated TLS connection > if the connection is not expected to deliver any rpc operation > later. It MUST send a TLS close_notify alert before closing the > connection. The TLS client MAY choose to not wait for the TLS server > (NETCONF agent) close_notify alert and simply close the connection, > thus generating an incomplete close on the TLS server side. Once the > TLS server gets a close_notify from the TLS client, it MUST reply with > From netconf-bounces@ietf.org Sat Oct 18 19:44: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 44F7E3A69FE; Sat, 18 Oct 2008 19:44: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 81E6F3A6A08 for ; Sat, 18 Oct 2008 19:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] 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 2rNOJq7Y5sx4 for ; Sat, 18 Oct 2008 19:44:51 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 9867F3A69FE for ; Sat, 18 Oct 2008 19:44:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=FcdmvUCFZFw0f26ilXFP9R7ls5LhMT227uV2fgemt45bWJ5TeW9y6AbXzzxoicwx; 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 [69.3.25.176] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KrOIp-0002P9-BW for netconf@ietf.org; Sat, 18 Oct 2008 22:45:59 -0400 Message-ID: <000401c93194$ecc4a180$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <62034.88.164.98.77.1223317108.squirrel@www.isima.fr> Date: Sat, 18 Oct 2008 19:46:43 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e4d93c93d116ec7c6485b6a7e28594e64f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.25.176 Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt: Connection Closure 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: > To: > Sent: Monday, October 06, 2008 11:18 AM > Subject: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt: Connection Closure > > Dear all, > > Below is a new tentative to agree on the text related to the Section > 'Connection Closure'. The text is much closed to Section 4.4 of > draft-ietf-syslog-transport-tls-14 with one exception; in Netconf, both > the agent and the manager may send data. > > A TLS client (NETCONF manager) MUST close the associated TLS connection > if the connection is not expected to deliver any rpc operation > later. It MUST send a TLS close_notify alert before closing the > connection. The TLS client MAY choose to not wait for the TLS server > (NETCONF agent) close_notify alert and simply close the connection, > thus generating an incomplete close on the TLS server side. Once the > TLS server gets a close_notify from the TLS client, it MUST reply with > a clo a close_notify unless it becomes aware that the connection has already > been closed by the TLS client (e.g., the closure was indicated by TCP). > > When no data is received from a connection for a long time (where the > application decides what "long" means), a NETCONF peer MAY close the > connection. The NETCONF peer MUST attempt to initiate an exchange of > close_notify alerts with the other NETCONF peer before closing the > connection. The close_notify's sender that is unprepared to receive > any more data MAY close the connection after sending the close_notify > alert, thus generating an incomplete close on the close_notify's > receiver side. > > Comments? ... RFC 2119 says "Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm...." In practice, my experience has been that "MUST" has been used in cases where things would break or not interoperate, and "SHOULD" has been used regarding questions of sound operational practice. >From that perspective, some of the "MUSTs" above sound like they really should be "SHOULDs". For example, will systems fail to interoperate or otherwise break if a client fails to close a connection which is "not expected to deliver any rpc operation later" ? Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf se_notify unless it becomes aware that the connection has already > been closed by the TLS client (e.g., the closure was indicated by TCP). > > When no data is received from a connection for a long time (where the > application decides what "long" means), a NETCONF peer MAY close the > connection. The NETCONF peer MUST attempt to initiate an exchange of > close_notify alerts with the other NETCONF peer before closing the > connection. The close_notify's sender that is unprepared to receive > any more data MAY close the connection after sending the close_notify > alert, thus generating an incomplete close on the close_notify's > receiver side. > > Comments? ... RFC 2119 says "Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm...." In practice, my experience has been that "MUST" has been used in cases where things would break or not interoperate, and "SHOULD" has been used regarding questions of sound operational practice. >From that perspective, some of the "MUSTs" above sound like they really should be "SHOULDs". For example, will systems fail to interoperate or otherwise break if a client fails to close a connection which is "not expected to deliver any rpc operation later" ? Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Oct 19 03:53:26 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 C0F3D3A69C5; Sun, 19 Oct 2008 03:53:26 -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 1CF383A68B7 for ; Sun, 19 Oct 2008 03:53:26 -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: ...etconf-t?=\n =?utf-8?Q?Re:\302\240[Netconf]\302\240WGL[...] X-Spam-Flag: NO X-Spam-Score: -0.659 X-Spam-Level: X-Spam-Status: No, score=-0.659 tagged_above=-999 required=5 tests=[AWL=-0.448, 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 q+CScD4HeGY7 for ; Sun, 19 Oct 2008 03:53:25 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 0707F3A69C5 for ; Sun, 19 Oct 2008 03:53:24 -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 m9JBsQDk880684; Sun, 19 Oct 2008 12:54:26 +0100 Received: from 88.175.65.115 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Sun, 19 Oct 2008 12:54:18 +0200 (CEST) Message-ID: <50702.88.175.65.115.1224413658.squirrel@www.isima.fr> In-Reply-To: <000401c93194$ecc4a180$6801a8c0@oemcomputer> References: <62034.88.164.98.77.1223317108.squirrel@www.isima.fr> <000401c93194$ecc4a180$6801a8c0@oemcomputer> Date: Sun, 19 Oct 2008 12:54:18 +0200 (CEST) From: "Mohamad Badra" To: =?utf-8?Q?Randy=C2_Presuhn=C2?= 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]); Sun, 19 Oct 2008 12:54:28 +0100 (WEST) Cc: netconf@ietf.org Subject: [Netconf] =?utf-8?b?IFJlOsKgwqBXR0xDwqBmb3LCoGRyYWZ0LWlldGYtbmV0?= =?utf-8?b?Y29uZi10UmU6wqDCoFdHTEPCoGZvcsKgZHJhZnQtaWV0Zi1uZXRjb25mLXRs?= =?utf-8?q?s-04=2Etxt=3A=C2=A0ConnectionClosure?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mbadra@gmail.com 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 Randy, > Hi - > >> From: >> To: >> Sent: Monday, October 06, 2008 11:18 AM >> Subject: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt: Connection >> Closure >> >> Dear all, >> >> Below is a new tentative to agree on the text related to the Section >> 'Connection Closure'. The text is much closed to Section 4.4 of >> draft-ietf-syslog-transport-tls-14 with one exception; in Netconf, both >> the agent and the manager may send data. >> >> A TLS client (NETCONF manager) MUST close the associated TLS >> connection >> if the connection is not expected to deliver any rpc operation >> later. It MUST send a TLS close_notify alert before closing the >> connection. The TLS client MAY choose to not wait for the TLS server >> (NETCONF agent) close_notify alert and simply cFrom netconf-bounces@ietf.org Sun Oct 19 03:53:26 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 C0F3D3A69C5; Sun, 19 Oct 2008 03:53:26 -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 1CF383A68B7 for ; Sun, 19 Oct 2008 03:53:26 -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: ...etconf-t?=\n =?utf-8?Q?Re:\302\240[Netconf]\302\240WGL[...] X-Spam-Flag: NO X-Spam-Score: -0.659 X-Spam-Level: X-Spam-Status: No, score=-0.659 tagged_above=-999 required=5 tests=[AWL=-0.448, 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 q+CScD4HeGY7 for ; Sun, 19 Oct 2008 03:53:25 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 0707F3A69C5 for ; Sun, 19 Oct 2008 03:53:24 -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 m9JBsQDk880684; Sun, 19 Oct 2008 12:54:26 +0100 Received: from 88.175.65.115 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Sun, 19 Oct 2008 12:54:18 +0200 (CEST) Message-ID: <50702.88.175.65.115.1224413658.squirrel@www.isima.fr> In-Reply-To: <000401c93194$ecc4a180$6801a8c0@oemcomputer> References: <62034.88.164.98.77.1223317108.squirrel@www.isima.fr> <000401c93194$ecc4a180$6801a8c0@oemcomputer> Date: Sun, 19 Oct 2008 12:54:18 +0200 (CEST) From: "Mohamad Badra" To: =?utf-8?Q?Randy=C2_Presuhn=C2?= 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]); Sun, 19 Oct 2008 12:54:28 +0100 (WEST) Cc: netconf@ietf.org Subject: [Netconf] =?utf-8?b?IFJlOsKgwqBXR0xDwqBmb3LCoGRyYWZ0LWlldGYtbmV0?= =?utf-8?b?Y29uZi10UmU6wqDCoFdHTEPCoGZvcsKgZHJhZnQtaWV0Zi1uZXRjb25mLXRs?= =?utf-8?q?s-04=2Etxt=3A=C2=A0ConnectionClosure?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mbadra@gmail.com 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 Randy, > Hi - > >> From: >> To: >> Sent: Monday, October 06, 2008 11:18 AM >> Subject: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt: Connection >> Closure >> >> Dear all, >> >> Below is a new tentative to agree on the text related to the Section >> 'Connection Closure'. The text is much closed to Section 4.4 of >> draft-ietf-syslog-transport-tls-14 with one exception; in Netconf, both >> the agent and the manager may send data. >> >> A TLS client (NETCONF manager) MUST close the associated TLS >> connection >> if the connection is not expected to deliver any rpc operation >> later. It MUST send a TLS close_notify alert before closing the >> connection. The TLS client MAY choose to not wait for the TLS server >> (NETCONF agent) close_notify alert and simply close the connection, >> thus generating an incomplete close on the TLS server side. Once the >> TLS server gets a close_notify from the TLS client, it MUST reply >> with >> a close_notify unless it becomes aware that the connection has >> already >> been closed by the TLS client (e.g., the closure was indicated by >> TCP). >> >> When no data is received from a connection for a long time (where the >> application decides what "long" means), a NETCONF peer MAY close the >> connection. The NETCONF peer MUST attempt to initiate an exchange of >> close_notify alerts with the other NETCONF peer before closing the >> connection. The close_notify's sender that is unprepared to receive >> any more data MAY close the connection after sending the close_notify >> alert, thus generating an incomplete close on the close_notify's >> receiver side. >> >> Comments? > ... > > RFC 2119 says "Imperatives of the type defined in this memo must > be used with care and sparingly. In particular, they MUST only be > used where it is actually required for interoperation or to limit > behavior which has potential for causing harm...." In practice, my > experience has been that "MUST" has been used in cases where > things would break or not interoperate, and "SHOULD" has been > used regarding questions of sound operational practice. > >>From that perspective, some of the "MUSTs" above sound like > they really should be "SHOULDs". For example, will systems fail > to interoperate or otherwise break if a client fails to close a > connection which is "not expected to deliver any rpc operation later" ? I can share your point of view (Version -04 has a quite different text). But during WGLC discussion, we agreed to adopt the same text used by syslog-tls regarding the closure. Note that this text [1] has been approved by IESG and some WG members have recommended using the same syslog-tls document's language within netconf-tls. [1] http://tools.ietf.org/html/draft-ietf-syslog-transport-tls-14#page-8 Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf lose the connection, >> thus generating an incomplete close on the TLS server side. Once the >> TLS server gets a close_notify from the TLS client, it MUST reply >> with >> a close_notify unless it becomes aware that the connection has >> already >> been closed by the TLS client (e.g., the closure was indicated by >> TCP). >> >> When no data is received from a connection for a long time (where the >> application decides what "long" means), a NETCONF peer MAY close the >> connection. The NETCONF peer MUST attempt to initiate an exchange of >> close_notify alerts with the other NETCONF peer before closing the >> connection. The close_notify's sender that is unprepared to receive >> any more data MAY close the connection after sending the close_notify >> alert, thus generating an incomplete close on the close_notify's >> receiver side. >> >> Comments? > ... > > RFC 2119 says "Imperatives of the type defined in this memo must > be used with care and sparingly. In particular, they MUST only be > used where it is actually required for interoperation or to limit > behavior which has potential for causing harm...." In practice, my > experience has been that "MUST" has been used in cases where > things would break or not interoperate, and "SHOULD" has been > used regarding questions of sound operational practice. > >>From that perspective, some of the "MUSTs" above sound like > they really should be "SHOULDs". For example, will systems fail > to interoperate or otherwise break if a client fails to close a > connection which is "not expected to deliver any rpc operation later" ? I can share your point of view (Version -04 has a quite different text). But during WGLC discussion, we agreed to adopt the same text used by syslog-tls regarding the closure. Note that this text [1] has been approved by IESG and some WG members have recommended using the same syslog-tls document's language within netconf-tls. [1] http://tools.ietf.org/html/draft-ietf-syslog-transport-tls-14#page-8 Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Oct 20 05:37: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 DAB9A3A6A2F; Mon, 20 Oct 2008 05:37: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 1A95D28C0F7 for ; Mon, 20 Oct 2008 05:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.013 X-Spam-Level: X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 cVb9V4uGbW7v for ; Mon, 20 Oct 2008 05:37:46 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D90193A6A29 for ; Mon, 20 Oct 2008 05:37:45 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 5A02A76C502 for ; Mon, 20 Oct 2008 14:38:52 +0200 (CEST) Date: Mon, 20 Oct 2008 14:38:03 +0200 (CEST) Message-Id: <20081020.143803.15997854.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Subject: [Netconf] rpc-error 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, At the NETMOD interim meeting we discussed what the NETCONF spec says about how errors in / processing are treated by a server. It turns out that of four implementations, all four handle such errors differently. There's also a fifth alternative, which noone (of the people there) implements. The spec says: The element is sent in messages if an error occurs during the processing of an request. and: i.e. zero or more elements are followed by zero or one element. The five different ways of handling such errors: 1. Buffer all data, and if any error occurs, send the element(s) (and possibly also send the element). If no error occured, send all buffered data in the element. Noone implements this, since buffering all state data is out of the question for larger systems. 2. Stream the , and if a particular object cannot be retrieved, silently skip that element in the output. A client cannot know if a missing element means it is not there, or if an error occured. 3. Stream the , and if any object has an error, close the underlying transport in the middle of the XML stream. A client cannot know if a closed transport meant that an error occured, or that a network failure occured. 4. Stream the , and buffer any errors as they occur. Send the errors as as in alternative 1, but send them *after* the element. This alternative is not conformant with the XSD, which says that any elements must come before . 5. Stream the , and send inline in the element. Like this: 1500 ... Could not retrieve interface stats: EIO ... ... Clients have to be prepared to parse these errors in the middle of the stream. It is not obvious from the spec if this is allowed or not. The XSD seems to indicate that this is not allowed (the group "rpcResponse" could be reused inline in the data, but it is not perfect.) The question to the NETCONF WG is if the spec should state how errors are supposed to be handled, or if it should be clarified that servers may handle such errors differently. Inline errors are may be out of scope for the protocol, but in scope for a data modelling language. In this case, we might want to clarify that the element in the netconf namespace should be used by a DML to indicate inline errors. (The exact rules for where they can occur must be up to the DML). /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Oct 20 05:37: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 DAB9A3A6A2F; Mon, 20 Oct 2008 05:37: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 1A95D28C0F7 for ; Mon, 20 Oct 2008 05:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.013 X-Spam-Level: X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 cVb9V4uGbW7v for ; Mon, 20 Oct 2008 05:37:46 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D90193A6A29 for ; Mon, 20 Oct 2008 05:37:45 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 5A02A76C502 for ; Mon, 20 Oct 2008 14:38:52 +0200 (CEST) Date: Mon, 20 Oct 2008 14:38:03 +0200 (CEST) Message-Id: <20081020.143803.15997854.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Subject: [Netconf] rpc-error 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, At the NETMOD interim meeting we discussed what the NETCONF spec says about how errors in / processing are treated by a server. It turns out that of four implementations, all four handle such errors differently. There's also a fifth alternative, which noone (of the people there) implements. The spec says: The element is sent in messages if an error occurs during the processing of an request. and: i.e. zero or more elements are followed by zero or one element. The five different ways of handling such errors: 1. Buffer all data, and if any error occurs, send the element(s) (and possibly also send the element). If no error occured, send all buffered data in the element. Noone implements this, since buffering all state data is out of the question for larger systems. 2. Stream the , and if a particular object cannot be retrieved, silently skip that element in the output. A client cannot know if a missing element means it is not there, or if an error occured. 3. Stream the , and if any object has an error, close the underlying transport in the middle of the XML stream. A client cannot know if a closed transport meant that an error occured, or that a network failure occured. 4. Stream the , and buffer any errors as they occur. Send the errors as as in alternative 1, but send them *after* the element. This alternative is not conformant with the XSD, which says that any elements must come before . 5. Stream the , and send inline in the element. Like this: 1500 ... Could not retrieve interface stats: EIO ... ... Clients have to be prepared to parse these errors in the middle of the stream. It is not obvious from the spec if this is allowed or not. The XSD seems to indicate that this is not allowed (the group "rpcResponse" could be reused inline in the data, but it is not perfect.) The question to the NETCONF WG is if the spec should state how errors are supposed to be handled, or if it should be clarified that servers may handle such errors differently. Inline errors are may be out of scope for the protocol, but in scope for a data modelling language. In this case, we might want to clarify that the element in the netconf namespace should be used by a DML to indicate inline errors. (The exact rules for where they can occur must be up to the DML). /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Oct 20 06:10:16 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 400023A68DA; Mon, 20 Oct 2008 06:10:16 -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 5D5493A681A for ; Mon, 20 Oct 2008 06:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.237 X-Spam-Level: X-Spam-Status: No, score=-6.237 tagged_above=-999 required=5 tests=[AWL=0.012, 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 W0yfB3Nz+2z0 for ; Mon, 20 Oct 2008 06:10:14 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7426C3A69F5 for ; Mon, 20 Oct 2008 06:10:14 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 83B6421457; Mon, 20 Oct 2008 15:11:24 +0200 (CEST) X-AuditID: c1b4fb3e-aa688bb000007a96-93-48fc83727655 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AEE8421622; Mon, 20 Oct 2008 15:11:14 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Oct 2008 15:11:13 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Oct 2008 15:11:13 +0200 Message-ID: <48FC8370.6040207@ericsson.com> Date: Mon, 20 Oct 2008 15:11:12 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <20081020.143803.15997854.mbj@tail-f.com> In-Reply-To: <20081020.143803.15997854.mbj@tail-f.com> X-OriginalArrivalTime: 20 Oct 2008 13:11:13.0120 (UTC) FILETIME=[53AEBE00:01C932B5] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-error 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 Would be nice to clarify. Balazs Martin Bjorklund wrote: > > 5. Stream the , and send inline in the > element. Like this: > > > > > > 1500 > ... > > > > > > Could not retrieve interface stats: EIO > > ... > > > ... > > > > Clients have to be prepared to parse these errors in the middle > of the stream. It is not obviFrom netconf-bounces@ietf.org Mon Oct 20 06:10:16 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 400023A68DA; Mon, 20 Oct 2008 06:10:16 -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 5D5493A681A for ; Mon, 20 Oct 2008 06:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.237 X-Spam-Level: X-Spam-Status: No, score=-6.237 tagged_above=-999 required=5 tests=[AWL=0.012, 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 W0yfB3Nz+2z0 for ; Mon, 20 Oct 2008 06:10:14 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7426C3A69F5 for ; Mon, 20 Oct 2008 06:10:14 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 83B6421457; Mon, 20 Oct 2008 15:11:24 +0200 (CEST) X-AuditID: c1b4fb3e-aa688bb000007a96-93-48fc83727655 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AEE8421622; Mon, 20 Oct 2008 15:11:14 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Oct 2008 15:11:13 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Oct 2008 15:11:13 +0200 Message-ID: <48FC8370.6040207@ericsson.com> Date: Mon, 20 Oct 2008 15:11:12 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <20081020.143803.15997854.mbj@tail-f.com> In-Reply-To: <20081020.143803.15997854.mbj@tail-f.com> X-OriginalArrivalTime: 20 Oct 2008 13:11:13.0120 (UTC) FILETIME=[53AEBE00:01C932B5] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-error 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 Would be nice to clarify. Balazs Martin Bjorklund wrote: > > 5. Stream the , and send inline in the > element. Like this: > > > > > > 1500 > ... > > > > > > Could not retrieve interface stats: EIO > > ... > > > ... > > > > Clients have to be prepared to parse these errors in the middle > of the stream. It is noous from the spec if this > is allowed or not. The XSD seems to indicate that this is not > allowed (the group "rpcResponse" could be reused inline in the > data, but it is not perfect.) > BALAZS: As data is anyxml it does not strictly forbid us to send us rpc-errors there. I think the ideal place to write this would e the rfc4741 even if opening it is a big work. Shall we add this to the tracker? _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf t obvious from the spec if this > is allowed or not. The XSD seems to indicate that this is not > allowed (the group "rpcResponse" could be reused inline in the > data, but it is not perfect.) > BALAZS: As data is anyxml it does not strictly forbid us to send us rpc-errors there. I think the ideal place to write this would e the rfc4741 even if opening it is a big work. Shall we add this to the tracker? _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Oct 20 06:58: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 13BB83A6A5E; Mon, 20 Oct 2008 06:58: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 0633D3A68D0 for ; Mon, 20 Oct 2008 06:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.985 X-Spam-Level: X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=0.614, 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 c88qGhWNb3Fa for ; Mon, 20 Oct 2008 06:58:37 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id A03143A6A5E for ; Mon, 20 Oct 2008 06:58:36 -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 m9KDxhcA011032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 Oct 2008 15:59:43 +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 m9KDxeib008477; Mon, 20 Oct 2008 15:59:40 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Oct 2008 15:59:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 20 Oct 2008 15:59:39 +0200 Message-ID: In-Reply-To: <48FC8370.6040207@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] rpc-error Thread-Index: AckytWPNWYWGiZTyQlCEFGawLbIxEgAAwp6w References: <20081020.143803.15997854.mbj@tail-f.com> <48FC8370.6040207@ericsson.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Balazs Lengyel" , "Martin Bjorklund" X-OriginalArrivalTime: 20 Oct 2008 13:59:40.0843 (UTC) FILETIME=[18D20FB0:01C932BC] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081020155943-40300BB0-DC5E64E9/0-0/0-15 X-purgate-size: 2137/0 Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-error 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 Thank you to Martin for bringing up this issue! BTW: To which implementations do the different ways match? > BALAZS: Shall we add this to the tracker? Yes, we should add it to the tracker. Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Balazs Lengyel > Sent: Monday, October 20, 2008 3:11 PM > To: Martin Bjorklund > Cc: netconf@ietf.org > Subject: Re: [Netconf] rpc-error > > Would be nice to clarify. > Balazs > > Martin Bjorklund wrote: > > > > 5. Stream the , and send inline in the > > element. Like this: > > > > > > > > > > > > 1500 > > ... > > > > > > > > > > > > Could not retrieve interface stats: EIO > > > > ... > > > > > > ... > > > > > > > > Clients have to be prepared to parse these errors in > the middle > > of the stream. It is not obvious from the spec if this > > is allowed or not. The XSD seems to indicate that this is not > > allowed (the group "rpcResponse" could be reused inline in the > > data, but it is not perfect.) > > > BALAZS: As data is anyxml it does not strictly forbid us to > send us rpc-errors there. > I think the ideal place to write this would e the rfc4741 > even if opening it is a big work. > Shall we add this to the tracker? > _______________________________________________ > 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 Oct 20 06:58: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 13BB83A6A5E; Mon, 20 Oct 2008 06:58: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 0633D3A68D0 for ; Mon, 20 Oct 2008 06:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.985 X-Spam-Level: X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=0.614, 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 c88qGhWNb3Fa for ; Mon, 20 Oct 2008 06:58:37 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id A03143A6A5E for ; Mon, 20 Oct 2008 06:58:36 -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 m9KDxhcA011032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 Oct 2008 15:59:43 +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 m9KDxeib008477; Mon, 20 Oct 2008 15:59:40 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Oct 2008 15:59:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 20 Oct 2008 15:59:39 +0200 Message-ID: In-Reply-To: <48FC8370.6040207@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] rpc-error Thread-Index: AckytWPNWYWGiZTyQlCEFGawLbIxEgAAwp6w References: <20081020.143803.15997854.mbj@tail-f.com> <48FC8370.6040207@ericsson.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Balazs Lengyel" , "Martin Bjorklund" X-OriginalArrivalTime: 20 Oct 2008 13:59:40.0843 (UTC) FILETIME=[18D20FB0:01C932BC] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081020155943-40300BB0-DC5E64E9/0-0/0-15 X-purgate-size: 2137/0 Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-error 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 Thank you to Martin for bringing up this issue! BTW: To which implementations do the different ways match? > BALAZS: Shall we add this to the tracker? Yes, we should add it to the tracker. Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Balazs Lengyel > Sent: Monday, October 20, 2008 3:11 PM > To: Martin Bjorklund > Cc: netconf@ietf.org > Subject: Re: [Netconf] rpc-error > > Would be nice to clarify. > Balazs > > Martin Bjorklund wrote: > > > > 5. Stream the , and send inline in the > > element. Like this: > > > > > > > > > > > > 1500 > > ... > > > > > > > > > > > > Could not retrieve interface stats: EIO > > > > ... > > > > > > ... > > > > > > > > Clients have to be prepared to parse these errors in > the middle > > of the stream. It is not obvious from the spec if this > > is allowed or not. The XSD seems to indicate that this is not > > allowed (the group "rpcResponse" could be reused inline in the > > data, but it is not perfect.) > > > BALAZS: As data is anyxml it does not strictly forbid us to > send us rpc-errors there. > I think the ideal place to write this would e the rfc4741 > even if opening it is a big work. > Shall we add this to the tracker? > _______________________________________________ > 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 Oct 20 08:38: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 39E673A69F4; Mon, 20 Oct 2008 08:38: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 A054A3A69F4 for ; Mon, 20 Oct 2008 08:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 G3QlOqONXLUm for ; Mon, 20 Oct 2008 08:38:30 -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 6F11A3A68B5 for ; Mon, 20 Oct 2008 08:38:30 -0700 (PDT) Received: (qmail 93111 invoked from network); 20 Oct 2008 15:39:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 20 Oct 2008 15:39:31 -0000 X-YMail-OSG: Y0VGYiEVM1m8GzkV0eUzPmjUwS.WhoVyINX14lj9fpy40SuuqjGHwwLy0q1gMCG0fG4VgYZghR8R6bMyLHdR.IzRP81lXEgnOqtigDe_EL3m0oAmmi.vapeLxL6daG82R2EFlfTgwT_npQeK0NHk5ERU X-Yahoo-Newman-Property: ymail-3 Message-ID: <48FCA632.5010405@netconfcentral.com> Date: Mon, 20 Oct 2008 08:39:30 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <20081020.143803.15997854.mbj@tail-f.com> In-Reply-To: <20081020.143803.15997854.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-error 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 Martin Bjorklund wrote: > Hi, > I think (5) is the best. I think (2) and (3) are the worst (and I implement (2)). There are really (at least) 2 phases of request processing: 1) validate that the PDU is correct, and the session is authorized to perform the operation with the specified parameters (except contents of element). 2) generate the ; for get and get-config, go through the database tree, skip nodes that the session is not authorized to view, and return the other requested nodes (if there was a filter) If (1) fails, then the will contain only elements. In our example, (1) succeeds. This issue relates to run-time exceptions that occur once the agent has determined it needs to return a particular non-config node that the database does not actually store the value. Instead the agent must dive into the instrumentation somehow and get the value. SNMPv3 has an exception mechanism for this purpose, where a portion of the inline data can be marked as missing. Solution (5) is most consistent with that approach. Andy > At the NETMOD interim meeting we discussed what the NETCONF spec says > about how errors in / processing are treated by a > server. > > It turns out that of four implementations, all four handle such errFrom netconf-bounces@ietf.org Mon Oct 20 08:38: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 39E673A69F4; Mon, 20 Oct 2008 08:38: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 A054A3A69F4 for ; Mon, 20 Oct 2008 08:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 G3QlOqONXLUm for ; Mon, 20 Oct 2008 08:38:30 -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 6F11A3A68B5 for ; Mon, 20 Oct 2008 08:38:30 -0700 (PDT) Received: (qmail 93111 invoked from network); 20 Oct 2008 15:39:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 20 Oct 2008 15:39:31 -0000 X-YMail-OSG: Y0VGYiEVM1m8GzkV0eUzPmjUwS.WhoVyINX14lj9fpy40SuuqjGHwwLy0q1gMCG0fG4VgYZghR8R6bMyLHdR.IzRP81lXEgnOqtigDe_EL3m0oAmmi.vapeLxL6daG82R2EFlfTgwT_npQeK0NHk5ERU X-Yahoo-Newman-Property: ymail-3 Message-ID: <48FCA632.5010405@netconfcentral.com> Date: Mon, 20 Oct 2008 08:39:30 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Martin Bjorklund References: <20081020.143803.15997854.mbj@tail-f.com> In-Reply-To: <20081020.143803.15997854.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-error 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 Martin Bjorklund wrote: > Hi, > I think (5) is the best. I think (2) and (3) are the worst (and I implement (2)). There are really (at least) 2 phases of request processing: 1) validate that the PDU is correct, and the session is authorized to perform the operation with the specified parameters (except contents of element). 2) generate the ; for get and get-config, go through the database tree, skip nodes that the session is not authorized to view, and return the other requested nodes (if there was a filter) If (1) fails, then the will contain only elements. In our example, (1) succeeds. This issue relates to run-time exceptions that occur once the agent has determined it needs to return a particular non-config node that the database does not actually store the value. Instead the agent must dive into the instrumentation somehow and get the value. SNMPv3 has an exception mechanism for this purpose, where a portion of the inline data can be marked as missing. Solution (5) is most consistent with that approach. Andy > At the NETMOD interim meeting we discussed what the NETCONF spec says > about how errors in / processing are treated by a > server. > > It turns out that of four implementations, all four handle such errors > differently. There's also a fifth alternative, which noone (of the > people there) implements. > > The spec says: > > The element is sent in messages if an error > occurs during the processing of an request. > > and: > > > > minOccurs="0" maxOccurs="unbounded"/> > > > > > i.e. zero or more elements are followed by zero or > one element. > > > The five different ways of handling such errors: > > 1. Buffer all data, and if any error occurs, send the > element(s) (and possibly also send the element). If no > error occured, send all buffered data in the element. > > Noone implements this, since buffering all state data is out of > the question for larger systems. > > 2. Stream the , and if a particular object cannot be > retrieved, silently skip that element in the output. > > A client cannot know if a missing element means it is not there, > or if an error occured. > > 3. Stream the , and if any object has an error, close the > underlying transport in the middle of the XML stream. > > A client cannot know if a closed transport meant that an error > occured, or that a network failure occured. > > 4. Stream the , and buffer any errors as they occur. Send the > errors as as in alternative 1, but send them *after* > the element. > > This alternative is not conformant with the XSD, which says that > any elements must come before . > > 5. Stream the , and send inline in the > element. Like this: > > > > > > 1500 > ... > > > > > > Could not retrieve interface stats: EIO > > ... > > > ... > > > > Clients have to be prepared to parse these errors in the middle > of the stream. It is not obvious from the spec if this > is allowed or not. The XSD seems to indicate that this is not > allowed (the group "rpcResponse" could be reused inline in the > data, but it is not perfect.) > > > The question to the NETCONF WG is if the spec should state how errors > are supposed to be handled, or if it should be clarified that servers > may handle such errors differently. > > Inline errors are may be out of scope for the protocol, but in scope > for a data modelling language. In this case, we might want to clarify > that the element in the netconf namespace should be used > by a DML to indicate inline errors. (The exact rules for where they > can occur must be up to the DML). > > > /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 ors > differently. There's also a fifth alternative, which noone (of the > people there) implements. > > The spec says: > > The element is sent in messages if an error > occurs during the processing of an request. > > and: > > > > minOccurs="0" maxOccurs="unbounded"/> > > > > > i.e. zero or more elements are followed by zero or > one element. > > > The five different ways of handling such errors: > > 1. Buffer all data, and if any error occurs, send the > element(s) (and possibly also send the element). If no > error occured, send all buffered data in the element. > > Noone implements this, since buffering all state data is out of > the question for larger systems. > > 2. Stream the , and if a particular object cannot be > retrieved, silently skip that element in the output. > > A client cannot know if a missing element means it is not there, > or if an error occured. > > 3. Stream the , and if any object has an error, close the > underlying transport in the middle of the XML stream. > > A client cannot know if a closed transport meant that an error > occured, or that a network failure occured. > > 4. Stream the , and buffer any errors as they occur. Send the > errors as as in alternative 1, but send them *after* > the element. > > This alternative is not conformant with the XSD, which says that > any elements must come before . > > 5. Stream the , and send inline in the > element. Like this: > > > > > > 1500 > ... > > > > > > Could not retrieve interface stats: EIO > > ... > > > ... > > > > Clients have to be prepared to parse these errors in the middle > of the stream. It is not obvious from the spec if this > is allowed or not. The XSD seems to indicate that this is not > allowed (the group "rpcResponse" could be reused inline in the > data, but it is not perfect.) > > > The question to the NETCONF WG is if the spec should state how errors > are supposed to be handled, or if it should be clarified that servers > may handle such errors differently. > > Inline errors are may be out of scope for the protocol, but in scope > for a data modelling language. In this case, we might want to clarify > that the element in the netconf namespace should be used > by a DML to indicate inline errors. (The exact rules for where they > can occur must be up to the DML). > > > /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 Tue Oct 21 13:52:35 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 89E0028C117; Tue, 21 Oct 2008 13:52:35 -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 4FA4428C117 for ; Tue, 21 Oct 2008 13:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=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 BtEzD4P2Q2zj for ; Tue, 21 Oct 2008 13:52:33 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id AB0C93A679F for ; Tue, 21 Oct 2008 13:52:32 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m9LKrfr23147 for ; Tue, 21 Oct 2008 20:53:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C933BF.1755F13C" Date: Tue, 21 Oct 2008 16:53:32 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC4BA87B@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72 Thread-Index: AckzvxQeDKpMqDAHR0258usWp1GayA== From: "Mark Scott" To: Subject: [Netconf] [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C933BF.1755F13C Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C933BF.1755F13C" ------_=_NextPart_002_01C933BF.1755F13C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 An open item discussed at IETF 72 is the definition of data types in the monitoring draft. Specifically whether or not data types required in the model should be explicitly defined in this draft or whether they should reference other standardized XSD definitions (where they exist). =20 In particular draft-ietf-netconf-monitoring-02 currently contains an explicit definition for an IP address data type. This can be found in sec 5.2 of the draft. I have also included it below for reference. =20 Rationale at the time of authoring v02 was to explicitly define this since no other standardized XSD was available. Although I am aware of similiar work in-progress to define standardized XSD data types I am still now aware of one suitable for this draft at this time. =20 The item which looked most promising (which was discussed in Dublin) was alignment to the definitions in draft-ietf-opsawg-smi-datatypes-in-xsd-03 (sec 5.4). That draft focuses on representing existing SMI datatypes in XSD. This in insufficient for the needs of the monitoring draft where we require an enhanced definition. In particular one with the ability to handle both IPv4 and IPv6 addresses. =20 So I would like to seek concencus from the group that the current explicit definition in draft-ietf-netconf-monitoring-02 is sufficient for our NETCONF monitoring needs and that we will leave the explicit definition in the draft in the next update (-03). =20 thank you, Mark =20 ipAddress.xsd: =20 The ipAddress type represents an IP address and is IP version neutral. The format of the textual representations implies the IP version. =20 =20 The ipv4Address type represents an IPv4 address in dotted-quad notation. The IPv4 address may include a zone index, separated by a % sign. =20 =20 The ipv6Address type represents an IPv6 address in full, mixed, shortened and shortened mixed notation. The IPv6 address may include a zone index, separated by a % sign. =20 =20 The domainName type represents a DNS domain name. The name SHOULD be fully qualified whenever possible. =20 The description clause of objects using the domainName type MUST describe how (and when) these names are resolved to IP addresses. =20 Note that the resolution of a domainName value may require to query multiple DNS records (e.g., A for IPv4 and AAAA for IPv6). The order of the resolution process and which DNS record takes precedence depends on the configuration of the resolver. =20 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 89E0028C117; Tue, 21 Oct 2008 13:52:35 -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 4FA4428C117 for ; Tue, 21 Oct 2008 13:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=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 BtEzD4P2Q2zj for ; Tue, 21 Oct 2008 13:52:33 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id AB0C93A679F for ; Tue, 21 Oct 2008 13:52:32 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m9LKrfr23147 for ; Tue, 21 Oct 2008 20:53:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C933BF.1755F13C" Date: Tue, 21 Oct 2008 16:53:32 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC4BA87B@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72 Thread-Index: AckzvxQeDKpMqDAHR0258usWp1GayA== From: "Mark Scott" To: Subject: [Netconf] [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C933BF.1755F13C Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C933BF.1755F13C" ------_=_NextPart_002_01C933BF.1755F13C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 An open item discussed at IETF 72 is the definition of data types in the monitoring draft. Specifically whether or not data types required in the model should be explicitly defined in this draft or whether they should reference other standardized XSD definitions (where they exist). =20 In particular draft-ietf-netconf-monitoring-02 currently contains an explicit definition for an IP address data type. This can be found in sec 5.2 of the draft. I have also included it below for reference. =20 Rationale at the time of authoring v02 was to explicitly define this since no other standardized XSD was available. Although I am aware of similiar work in-progress to define standardized XSD data types I am still now aware of one suitable for this draft at this time. =20 The item which looked most promising (which was discussed in Dublin) was alignment to the definitions in draft-ietf-opsawg-smi-datatypes-in-xsd-03 (sec 5.4). That draft focuses on representing existing SMI datatypes in XSD. This in insufficient for the needs of the monitoring drype> =20 The host type represents either an IP address or a DNS domain name. =20 =20 ------_=_NextPart_002_01C933BF.1755F13C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
 
An = open item=20 discussed at IETF 72 is the definition of data types in the monitoring=20 draft.  Specifically whether or not data types required in the = model should=20 be explicitly defined in this draft or whether they should reference = other=20 standardized XSD definitions (where they exist).
 
In particular=20 draft-ietf-netconf-monitoring-02 = currently=20 contains an explicit definition for an IP address data type.  = This=20 can be = found in sec 5.2=20 of the draft.  I have also included it below for=20 reference.
 
Rationale at the=20 time of authoring v02 was to explicitly define this since no other = standardized=20 XSD was available.  Although I am aware of similiar work in-progress = to define=20 standardized XSD data types I am still now aware of one suitable for = this draft=20 at this time.
 
The item which looked most promising (which was = discussed in=20 Dublin) was alignment to the definitions in=20 draft-ietf-opsawg-smi-datatypes-in-xsd-03 (sec 5.4).  That draft = focuses on=20 representing existing SMI datatypes in XSD.  This in insufficient = for the=20 needs of the monitoring draft where we require an enhanced = definition.  In=20 particular one with the ability to handle both IPv4 and IPv6=20 addresses.
 
So I = would like to=20 seek concencus from the group that the current explicit definition in = draft-ietf-netconf-monitoring-02 is = sufficient=20 for our NETCONF monitoring needs and that we will leave the = explicit=20 definition in the draft in the next update (-03).
 
thank=20 you,
aft where we require an enhanced definition. In particular one with the ability to handle both IPv4 and IPv6 addresses. =20 So I would like to seek concencus from the group that the current explicit definition in draft-ietf-netconf-monitoring-02 is sufficient for our NETCONF monitoring needs and that we will leave the explicit definition in the draft in the next update (-03). =20 thank you, Mark =20 ipAddress.xsd: =20 The ipAddress type represents an IP address and is IP version neutral. The format of the textual representations implies the IP version. =20 =20 The ipv4Address type represents an IPv4 address in dotted-quad notation. The IPv4 address may include a zone index, separated by a % sign. =20 =20 The ipv6Address type represents an IPv6 address in full, mixed, shortened and shortened mixed notation. The IPv6 address may include a zone index, separated by a % sign. =20 =20 The domainName type represents a DNS domain name. The name SHOULD be fully qualified whenever possible. =20 The description clause of objects using the domainName type MUST describe how (and when) these names are resolved to IP addresses. =20 Note that the resolution of a domainName value may require to query multiple DNS records (e.g., A for IPv4 and AAAA for IPv6). The order of the resolution process and which DNS record takes precedence depends on the configuration of the resolver. =20 =Mark
 
ipAddress.xsd:
<?xml=20 version=3D"1.0" encoding=3D"UTF-8"?>
   <xs:schema = xmlns:xs=3D"http://www.w3.org/2001/XMLSchem= a"
          &nb= sp;  =20 targetNamespace=3D"urn:ietf:params:xml:ns:inet-types"
  &nbs= p;          =20 xmlns:inet=3D"urn:ietf:params:xml:ns:inet-types"
   &nb= sp;         =20 elementFormDefault=3D"qualified"
      &= nbsp;      =20 attributeFormDefault=3D"unqualified">
 
     <xs:simpleType=20 name=3D"ipAddress">
      =20 <xs:annotation>
        = =20 <xs:documentation>
       &nb= sp;  =20 The ipAddress type represents an IP address=20 and
           is = IP=20 version neutral. The format of the=20 textual
          =20 representations implies the IP=20 version.
        =20 </xs:documentation>
      =20 </xs:annotation>
 
      =20 <xs:union>
        =20 <xs:simpleType>
        =   =20 <xs:restriction=20 base=3D"inet:ipv4Address">
      &nbs= p;   =20 </xs:restriction>
       &nbs= p;=20 </xs:simpleType>
        = ;=20 <xs:simpleType>
        =   =20 <xs:restriction=20 base=3D"inet:ipv6Address">
      &nbs= p;   =20 </xs:restriction>
       &nbs= p;=20 </xs:simpleType>
      =20 </xs:union>
    =20 </xs:simpleType>
 
     <xs:simpleType=20 name=3D"ipv4Address">
      =20 <xs:annotation>
        = =20 <xs:documentation>
       &nb= sp;  =20 The ipv4Address type represents an IPv4 address=20 in
           = dotted-quad=20 notation. The IPv4 address may=20 include
           = a zone=20 index, separated by a %=20 sign.
        =20 </xs:documentation>
      =20 </xs:annotation>
 
       <xs:restriction=20 base=3D"xs:string">
        = ;=20 <xs:pattern=20 value=3D
          &= nbsp;     &20 The host type represents either an IP address or a DNS domain name. =20 =20 ------_=_NextPart_002_01C933BF.1755F13C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
 
An = open item=20 discussed at IETF 72 is the definition of data types in the monitoring=20 draft.  Specifically whether or not data types required in the = model should=20 be explicitly defined in this draft or whether they should reference = other=20 standardized XSD definitions (where they exist).
 
In particular=20 draft-ietf-netconf-monitoring-02 = currently=20 contains an explicit definition for an IP address data type.  = This=20 can be = found in sec 5.2=20 of the draft.  I have also included it below for=20 reference.
 
Rationale at the=20 time of authoring v02 was to explicitly define this since no other = standardized=20 XSD was available.  Although I am aware of similiar work in-progress = to define=20 standardized XSD data types I am still now aware of one suitable for = this draft=20 at this time.
 
The item which looked most promising (which was = discussed in=20 Dublin) was alignment to the definitions in=20 draft-ietf-opsawg-smi-datatypes-in-xsd-03 (sec 5.4).  That draft = focuses on=20 representing existing SMI datatypes in XSD.  This in insufficient = for the=20 needs of the monitoring draft where we require an enhanced = definition.  In=20 particular one with the ability to handle both IPv4 and IPv6=20 addresses.
 
So I = would like to=20 seek concencus from the group that the current explicit definition in = draft-ietf-netconf-monitoring-02 is = sufficient=20 for our NETCONF monitoring needs and that we will leave the = explicit=20 definition in the draft in the next update (-03).
 
thank=20 you,
   &nbs= p;            = ;  =20 ([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])
     =             &= nbsp;=20 (%[\p{N}\p{L}]+)?"/>
      =20 </xs:restriction>
    =20 </xs:simpleType>
 
     <xs:simpleType=20 name=3D"ipv6Address">
      =20 <xs:annotation>
        = =20 <xs:documentation>
       &nb= sp;  =20 The ipv6Address type represents an IPv6 address=20 in
           full, = mixed,=20 shortened and shortened mixed=20 notation.
          = The=20 IPv6 address may include a zone index,=20 separated
          = by a %=20 sign.
        =20 </xs:documentation>
      =20 </xs:annotation>
 
       <xs:restriction=20 base=3D"xs:string">
        = ;=20 <xs:pattern=20 value=3D
          &= nbsp;      =20 "((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})
    &= nbsp;           &n= bsp; =20 (%[\p{N}\p{L}]+)?)
        &nb= sp;         =20 |((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.
     = ;            =      =20 [0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))
     &nb= sp;           &nbs= p; =20 (%[\p{N}\p{L}]+)?)
        &nb= sp;        =20 |((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)
   &nbs= p;            = ;   =20 (([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*
    &nbs= p;            = ;  =20 (%[\p{N}\p{L}]+)?)
        &nb= sp;        =20 ((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)
    = ;            =   =20 (([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*
    &nbs= p;            = ; =20 (([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))
   &= nbsp;           &n= bsp;   =20 (%[\p{N}\p{L}]+)?)"/>
      =20 </xs:restriction>
    =20 </xs:simpleType>
 
     <xs:simpleType=20 name=3D"domainName">
      =20 <xs:annotation>
        = =20 <xs:documentation>
       &nb= sp;  =20 The domainName tyface=3DArial=20 size=3D2>Mark
 
ipAddress.xsd:
<?xml=20 version=3D"1.0" encoding=3D"UTF-8"?>
   <xs:schema = xmlns:xs=3D"http://www.w3.org/2001/XMLSchem= a"
          &nb= sp;  =20 targetNamespace=3D"urn:ietf:params:xml:ns:inet-types"
  &nbs= p;          =20 xmlns:inet=3D"urn:ietf:params:xml:ns:inet-types"
   &nb= sp;         =20 elementFormDefault=3D"qualified"
      &= nbsp;      =20 attributeFormDefault=3D"unqualified">
 
     <xs:simpleType=20 name=3D"ipAddress">
      =20 <xs:annotation>
        = =20 <xs:documentation>
       &nb= sp;  =20 The ipAddress type represents an IP address=20 and
           is = IP=20 version neutral. The format of the=20 textual
          =20 representations implies the IP=20 version.
        =20 </xs:documentation>
      =20 </xs:annotation>
 
      =20 <xs:union>
        =20 <xs:simpleType>
        =   =20 <xs:restriction=20 base=3D"inet:ipv4Address">
      &nbs= p;   =20 </xs:restriction>
       &nbs= p;=20 </xs:simpleType>
        = ;=20 <xs:simpleType>
        =   =20 <xs:restriction=20 base=3D"inet:ipv6Address">
      &nbs= p;   =20 </xs:restriction>
       &nbs= p;=20 </xs:simpleType>
      =20 </xs:union>
    =20 </xs:simpleType>
 
     <xs:simpleType=20 name=3D"ipv4Address">
      =20 <xs:annotation>
        = =20 <xs:documentation>
       &nb= sp;  =20 The ipv4Address type represents an IPv4 address=20 in
           = dotted-quad=20 notation. The IPv4 address may=20 include
           = a zone=20 index, separated by a %=20 sign.
        =20 </xs:documentation>
      =20 </xs:annotation>
 
       <xs:restriction=20 base=3D"xs:string">
        = ;=20 <xs:pattern=20 value=3D
          &= nbsp;      =pe represents a DNS=20 domain
           = name. The=20 name SHOULD be fully=20 qualified
          = =20 whenever possible.
 
           = The=20 description clause of objects using=20 the
           = domainName=20 type MUST describe how (and=20 when)
           = these=20 names are resolved to IP addresses.
 
           = Note that=20 the resolution of a domainName=20 value
           = may=20 require to query multiple DNS records=20 (e.g.,
           A = for=20 IPv4 and AAAA for IPv6).  The order of=20 the
           = resolution=20 process and which DNS record=20 takes
           = precedence=20 depends on the configuration of=20 the
          =20 resolver.
        =20 </xs:documentation>
      =20 </xs:annotation>
 
       <xs:restriction=20 base=3D"xs:string">
        = ;=20 <xs:pattern=20 value=3D"([\p{L}\p{N}]+\.)*[\p{L}\p{N}]"/>
    =   =20 </xs:restriction>
    =20 </xs:simpleType>
 
     <xs:simpleType=20 name=3D"host">
      =20 <xs:annotation>
        = =20 <xs:documentation>
       &nb= sp;  =20 The host type represents either an IP=20 address
           = or a DNS=20 domain name.
        =20 </xs:documentation>
      =20 </xs:annotation>
 
      =20 <xs:union>
        =20 <xs:simpleType>
        =   =20 <xs:restriction=20 base=3D"inet:ipAddress">
       =    =20 </xs:restriction>
       &nbs= p;=20 </xs:simpleType>
        = ;=20 <xs:simpleType>
        =   =20 <xs:restriction=20 base=3D"inet:domainName">
       = ;   =20 </xs:restriction>
       &nbs= p;=20 </xs:simpleType>
      =20 </xs:union>
    =20 </xs:simpleType>
 
  =20 </xs:schema>
------_=_NextPart_002_01C933BF.1755F13C-- ------_=_NextPart_001_01C933BF.1755F13C Content-Type: application/octet-stream; name="ipaddress.xsd" Content-Transfer-Encoding: base64 Content-Description: ipaddress.xsd Content-Disposition: attachment; filename="ipaddress.xsd" PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCiAgIDx4czpzY2hlbWEgeG1s bnM6eHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIg0KICAgICAgICAgICAgICB0 YXJnZXROYW1lc3BhY2U9InVybjppZXRmOnBhcmFtczp4bWw6bnM6aW5ldC10eXBlcyINCiAgICAg ICAgICAgICAgeG1sbnM6aW5ldD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczppbmV0LXR5cGVzIg0K ICAgICAgICAgICAgICBlbGVtZW50Rm9ybURlZmF1bHQ9InF1YWxpZmllZCINCiAgICAgICAgICAg ICAgYXR0cmlidXRlRm9ybURlZmF1bHQ9InVucXVhbGlmaWVkIj4NCg0KICAgICA8eHM6c2ltcGxl VHlwZSBuYW1lPSJpcEFkZHJlc3MiPg0KICAgICAgIDx4czphbm5vdGF0aW9uPg0KICAgICAgICAg PHhzOmRvY3VtZW50YXRpb24+DQogICAgICAgICAgIFRoZSBpcEFkZHJlc3MgdHlwZSByZXByZXNl bnRzIGFuIElQIGFkZHJlc3MgYW5kDQogICAgICAgICAgIGlzIElQIHZlcnNpb24gbmV1dHJhbC4g VGhlIGZvcm1hdCBvZiB0aGUgdGV4dHVhbA0KICAgICAgICAgICByZXByZXNlbnRhdGlvbnMgaW1w bGllcyB0aGUgSVAgdmVyc2lvbi4NCiAgICAgICAgIDwveHM6ZG9jdW1lbnRhdGlvbj4NCiAgICAg ICA8L3hzOmFubm90YXRpb24+DQoNCiAgICAgICA8eHM6dW5pb24+DQogICAgICAgICA8eHM6c2lt cGxlVHlwZT4NCiAgICAgICAgICAgPHhzOnJlc3RyaWN0aW9uIGJhc2U9ImluZXQ6aXB2NEFkZHJl c3MiPg0KICAgICAgICAgICA8L3hzOnJlc3RyaWN0aW9uPg0KICAgICAgICAgPC94czpzaW1wbGVU eXBlPg0KICAgICAgICAgPHhzOnNpbXBsZVR5cGU+DQogICAgICAgICAgIDx4czpyZXN0cmljdGlv biBiYXNlPSJpbmV0OmlwdjZBZGRyZXNzIj4NCiAgICAgICAgICAgPC94czpyZXN0cmljdGlvbj4N CiAgICAgICAgIDwveHM6c2ltcGxlVHlwZT4NCiAgICAgICA8L3hzOnVuaW9uPg0KICAgICA8L3hz OnNpbXBsZVR5cGU+DQoNCiAgICAgPHhzOnNpbXBsZVR5cGUgbmFtZT0iaXB2NEFkZHJlc3MiPg0K ICAgICAgIDx4czphbm5vdGF0aW9uPg0KICAgICAgICAgPHhzOmRvY3VtZW50YXRpb24+DQogICAg ICAgICAgIFRoZSBpcHY0QWRkcmVzcyB0eXBlIHJlcHJlc2VudHMgYW4gSVB2NCBhZGRyZXNzIGlu DQogICAgICAgICAgIGRvdHRlZC1xdWFkIG5vdGF0aW9uLiBUaGUgSVB2NCBhZGRyZXNzIG1heSBp bmNsdWRlDQogICAgICAgICAgIGEgem9uZSBpbmRleCwgc2VwYXJhdGVkIGJ5IGEgJSBzaWduLg0K ICAgICAgICAgPC94czpkb2N1bWVudGF0aW9uPg0KICAgICAgIDwveHM6YW5ub3RhdGlvbj4NCg0K ICAgICAgIDx4czpyZXN0cmljdGlvbiBiYXNlPSJ4czpzdHJpbmciPg0KICAgICAgICAgPHhzOnBh dHRlcm4gdmFsdWU9DQogICAgICAgICAgICAgICAgICAiKChbMC0xXT9bMC05XT9bMC05XXwyWzAt NF1bMC05XXwyNVswLTVdKVwuKXszfQ0KICAgICAgICAgICAgICAgICAgIChbMC0xXT9bMC05XT9b MC05XXwyWzAtNF1bMC05XXwyNVswLTVdKQ0KICAgICAgICAgICAgICAgICAgICglW1xwe059XHB7 TH1dKyk/Ii8+DQogICAgICAgPC94czpyZXN0cmljdGlvbj4NCiAgICAgPC94czpzaW1wbGVUeXBl Pg0KDQogICAgIDx4czpzaW1wbGVUeXBlIG5hbWU9ImlwdjZBZGRyZXNzIj4NCiAgICAgICA8eHM6 YW5ub3RhdGlvbj4NCiAgICAgICAgIDx4czpkb2N1bWVudGF0aW9uPg0KICAgICAgICAgICBUaGUg aXB2NkFkZHJlc3MgdHlwZSByZXByZXNlbnRzIGFuIElQdjYgYWRkcmVzcyBpbg0KICAgICAgICAg ICBmdWxsLCBtaXhlZCwgc2hvcnRlbmVkIGFuZCBzaG9ydGVuZWQgbWl4ZWQgbm90YXRpb24uDQog ICAgICAgICAgIFRoZSBJUHY2IGFkZHJlc3MgbWF5IGluY2x1ZGUgYSB6b25lIGluZGV4LCBzZXBh cmF0ZWQNCiAgICAgICAgICAgYnkgYSAlIHNpZ24uDQogICAgICAgICA8L3hzOmRvY3VtZW50YXRp b24+DQogICAgICAgPC94czphbm5vdGF0aW9uPg0KDQogICAgICAgPHhzOnJlc3RyaWN0aW9uIGJh c2U9InhzOnN0cmluZyI+DQogICAgICAgICA8eHM6cGF0dGVybiB2YWx1ZT0NCiAgICAgICAgICAg ICAgICAgICIoKChbMC05YS1mQS1GXXsxLDR9Oil7N30pKFswLTlhLWZBLUZdezEsNH0pDQogICAg ICAgICAgICAgICAgICAgKCVbXHB7Tn1ccHtMfV0rKT8pDQogICAgICAgICAgICAgICAgICAgfCgo KFswLTlhLWZBLUZdezEsNH06KXs2fSkoKFswLTldezEsM31cLg0KICAgICAgICAgICAgICAgICAg ICAgICBbMC05XXsxLDN9XC5bMC05XXsxLDN9XC5bMC05XXsxLDN9KSkNCiAgICAgICAgICAgICAg ICAgICAgKCVbXHB7Tn1ccHtMfV0rKT8pDQogICAgICAgICAgICAgICAgICB8KCgoWzAtOWEtZkEt Rl17MSw0fTopKihbMC05YS1mQS1GXXsxLDR9KSkqKDo6KQ0KICAgICAgICAgICAgICAgICAgICAo KFswLTlhLWZBLUZdezEsNH06KSooWzAtOWEtZkEtRl17MSw0fSkpKg0KICAgICAgICAgICAgICAg ICAgICAoJVtccHtOfVxwe0x9XSspPykNCiAgICAgICAgICAgICAgICAgICgoKFswLTlhLWZBLUZd ezEsNH06KSooWzAtOWEtZkEtRl17MSw0fSkpKig6OikNCiAgICAgICAgICAgICAgICAgICAoKFsw LTlhLWZBLUZdezEsNH06KSooWzAtOWEtZkEtRl17MSw0fSkpKg0KICAgICAgICAgICAgICAgICAg ICgoWzAtOV17MSwzfVwuWzAtOV17MSwzfVwuWzAtOV17MSwzfVwuWzAtOV17MSwzfSkpDQogICAg ICAgICAgICAgICAgICAgICglW1xwe059XHB7TH1dKyk/KSIvPg0KICAgICAgIDwveHM6cmVzdHJp Y3Rpb24+DQogICAgIDwveHM6c2ltcGxlVHlwZT4NCg0KICAgICA8eHM6c2ltcGxlVHlwZSBuYW1l PSJkb21haW5OYW1lIj4NCiAgICAgICA8eHM6YW5ub3RhdGlvbj4NCiAgICAgICAgIDx4czpkb2N1 bWVudGF0aW9uPg0KICAgICAgICAgICBUaGUgZG9tYWluTmFtZSB0eXBlIHJlcHJlc2VudHMgYSBE TlMgZG9tYWluDQogICAgICAgICAgIG5hbWUuIFRoZSB20 "(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}
   &nbs= p;            = ;  =20 ([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])
     =             &= nbsp;=20 (%[\p{N}\p{L}]+)?"/>
      =20 </xs:restriction>
    =20 </xs:simpleType>
 
     <xs:simpleType=20 name=3D"ipv6Address">
      =20 <xs:annotation>
        = =20 <xs:documentation>
       &nb= sp;  =20 The ipv6Address type represents an IPv6 address=20 in
           full, = mixed,=20 shortened and shortened mixed=20 notation.
          = The=20 IPv6 address may include a zone index,=20 separated
          = by a %=20 sign.
        =20 </xs:documentation>
      =20 </xs:annotation>
 
       <xs:restriction=20 base=3D"xs:string">
        = ;=20 <xs:pattern=20 value=3D
          &= nbsp;      =20 "((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})
    &= nbsp;           &n= bsp; =20 (%[\p{N}\p{L}]+)?)
        &nb= sp;         =20 |((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.
     = ;            =      =20 [0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))
     &nb= sp;           &nbs= p; =20 (%[\p{N}\p{L}]+)?)
        &nb= sp;        =20 |((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)
   &nbs= p;            = ;   =20 (([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*
    &nbs= p;            = ;  =20 (%[\p{N}\p{L}]+)?)
        &nb= sp;        =20 ((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)
    = ;            =   =20 (([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*
    &nbs= p;            = ; =20 (([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))
   &= nbsp;           &n= bsp;   =20 (%[\p{N}\p{L}]+)?)"/>
      =20 </xs:restriction>
    =20 </xs:simpleType>
 
     <xs:simpleType=20 name=3D"domainName">
      =20 <xs:annotation>
        = =20 <xs:documentation>
       &nb= sp;  =20 The domainName type repuYW1lIFNIT1VMRCBiZSBmdWxseSBxdWFs aWZpZWQNCiAgICAgICAgICAgd2hlbmV2ZXIgcG9zc2libGUuDQoNCiAgICAgICAgICAgVGhlIGRl c2NyaXB0aW9uIGNsYXVzZSBvZiBvYmplY3RzIHVzaW5nIHRoZQ0KICAgICAgICAgICBkb21haW5O YW1lIHR5cGUgTVVTVCBkZXNjcmliZSBob3cgKGFuZCB3aGVuKQ0KICAgICAgICAgICB0aGVzZSBu YW1lcyBhcmUgcmVzb2x2ZWQgdG8gSVAgYWRkcmVzc2VzLg0KDQogICAgICAgICAgIE5vdGUgdGhh dCB0aGUgcmVzb2x1dGlvbiBvZiBhIGRvbWFpbk5hbWUgdmFsdWUNCiAgICAgICAgICAgbWF5IHJl cXVpcmUgdG8gcXVlcnkgbXVsdGlwbGUgRE5TIHJlY29yZHMgKGUuZy4sDQogICAgICAgICAgIEEg Zm9yIElQdjQgYW5kIEFBQUEgZm9yIElQdjYpLiAgVGhlIG9yZGVyIG9mIHRoZQ0KICAgICAgICAg ICByZXNvbHV0aW9uIHByb2Nlc3MgYW5kIHdoaWNoIEROUyByZWNvcmQgdGFrZXMNCiAgICAgICAg ICAgcHJlY2VkZW5jZSBkZXBlbmRzIG9uIHRoZSBjb25maWd1cmF0aW9uIG9mIHRoZQ0KICAgICAg ICAgICByZXNvbHZlci4NCiAgICAgICAgIDwveHM6ZG9jdW1lbnRhdGlvbj4NCiAgICAgICA8L3hz OmFubm90YXRpb24+DQoNCiAgICAgICA8eHM6cmVzdHJpY3Rpb24gYmFzZT0ieHM6c3RyaW5nIj4N CiAgICAgICAgIDx4czpwYXR0ZXJuIHZhbHVlPSIoW1xwe0x9XHB7Tn1dK1wuKSpbXHB7TH1ccHtO fV0iLz4NCiAgICAgICA8L3hzOnJlc3RyaWN0aW9uPg0KICAgICA8L3hzOnNpbXBsZVR5cGU+DQoN CiAgICAgPHhzOnNpbXBsZVR5cGUgbmFtZT0iaG9zdCI+DQogICAgICAgPHhzOmFubm90YXRpb24+ DQogICAgICAgICA8eHM6ZG9jdW1lbnRhdGlvbj4NCiAgICAgICAgICAgVGhlIGhvc3QgdHlwZSBy ZXByZXNlbnRzIGVpdGhlciBhbiBJUCBhZGRyZXNzDQogICAgICAgICAgIG9yIGEgRE5TIGRvbWFp biBuYW1lLg0KICAgICAgICAgPC94czpkb2N1bWVudGF0aW9uPg0KICAgICAgIDwveHM6YW5ub3Rh dGlvbj4NCg0KICAgICAgIDx4czp1bmlvbj4NCiAgICAgICAgIDx4czpzaW1wbGVUeXBlPg0KICAg ICAgICAgICA8eHM6cmVzdHJpY3Rpb24gYmFzZT0iaW5ldDppcEFkZHJlc3MiPg0KICAgICAgICAg ICA8L3hzOnJlc3RyaWN0aW9uPg0KICAgICAgICAgPC94czpzaW1wbGVUeXBlPg0KICAgICAgICAg PHhzOnNpbXBsZVR5cGU+DQogICAgICAgICAgIDx4czpyZXN0cmljdGlvbiBiYXNlPSJpbmV0OmRv bWFpbk5hbWUiPg0KICAgICAgICAgICA8L3hzOnJlc3RyaWN0aW9uPg0KICAgICAgICAgPC94czpz aW1wbGVUeXBlPg0KICAgICAgIDwveHM6dW5pb24+DQogICAgIDwveHM6c2ltcGxlVHlwZT4NCg0K ICAgPC94czpzY2hlbWE+ ------_=_NextPart_001_01C933BF.1755F13C 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_001_01C933BF.1755F13C-- resents a DNS=20 domain
           = name. The=20 name SHOULD be fully=20 qualified
          = =20 whenever possible.
 
           = The=20 description clause of objects using=20 the
           = domainName=20 type MUST describe how (and=20 when)
           = these=20 names are resolved to IP addresses.
 
           = Note that=20 the resolution of a domainName=20 value
           = may=20 require to query multiple DNS records=20 (e.g.,
           A = for=20 IPv4 and AAAA for IPv6).  The order of=20 the
           = resolution=20 process and which DNS record=20 takes
           = precedence=20 depends on the configuration of=20 the
          =20 resolver.
        =20 </xs:documentation>
      =20 </xs:annotation>
 
       <xs:restriction=20 base=3D"xs:string">
        = ;=20 <xs:pattern=20 value=3D"([\p{L}\p{N}]+\.)*[\p{L}\p{N}]"/>
    =   =20 </xs:restriction>
    =20 </xs:simpleType>
 
     <xs:simpleType=20 name=3D"host">
      =20 <xs:annotation>
        = =20 <xs:documentation>
       &nb= sp;  =20 The host type represents either an IP=20 address
           = or a DNS=20 domain name.
        =20 </xs:documentation>
      =20 </xs:annotation>
 
      =20 <xs:union>
        =20 <xs:simpleType>
        =   =20 <xs:restriction=20 base=3D"inet:ipAddress">
       =    =20 </xs:restriction>
       &nbs= p;=20 </xs:simpleType>
        = ;=20 <xs:simpleType>
        =   =20 <xs:restriction=20 base=3D"inet:domainName">
       = ;   =20 </xs:restriction>
       &nbs= p;=20 </xs:simpleType>
      =20 </xs:union>
    =20 </xs:simpleType>
 
  =20 </xs:schema>
------_=_NextPart_002_01C933BF.1755F13C-- ------_=_NextPart_001_01C933BF.1755F13C Content-Type: application/octet-stream; name="ipaddress.xsd" Content-Transfer-Encoding: base64 Content-Description: ipaddress.xsd Content-Disposition: attachment; filename="ipaddress.xsd" PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCiAgIDx4czpzY2hlbWEgeG1s bnM6eHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIg0KICAgICAgICAgICAgICB0 YXJnZXROYW1lc3BhY2U9InVybjppZXRmOnBhcmFtczp4bWw6bnM6aW5ldC10eXBlcyINCiAgICAg ICAgICAgICAgeG1sbnM6aW5ldD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczppbmV0LXR5cGVzIg0K ICAgICAgICAgICAgICBlbGVtZW50Rm9ybURlZmF1bHQ9InF1YWxpZmllZCINCiAgICAgICAgICAg ICAgYXR0cmlidXRlRm9ybURlZmF1bHQ9InVucXVhbGlmaWVkIj4NCg0KICAgICA8eHM6c2ltcGxl VHlwZSBuYW1lPSJpcEFkZHJlc3MiPg0KICAgICAgIDx4czphbm5vdGF0aW9uPg0KICAgICAgICAg PHhzOmRvY3VtZW50YXRpb24+DQogICAgICAgICAgIFRoZSBpcEFkZHJlc3MgdHlwZSByZXByZXNl bnRzIGFuIElQIGFkZHJlc3MgYW5kDQogICAgICAgICAgIGlzIElQIHZlcnNpb24gbmV1dHJhbC4g VGhlIGZvcm1hdCBvZiB0aGUgdGV4dHVhbA0KICAgICAgICAgICByZXByZXNlbnRhdGlvbnMgaW1w bGllcyB0aGUgSVAgdmVyc2lvbi4NCiAgICAgICAgIDwveHM6ZG9jdW1lbnRhdGlvbj4NCiAgICAg ICA8L3hzOmFubm90YXRpb24+DQoNCiAgICAgICA8eHM6dW5pb24+DQogICAgICAgICA8eHM6c2lt cGxlVHlwZT4NCiAgICAgICAgICAgPHhzOnJlc3RyaWN0aW9uIGJhc2U9ImluZXQ6aXB2NEFkZHJl c3MiPg0KICAgICAgICAgICA8L3hzOnJlc3RyaWN0aW9uPg0KICAgICAgICAgPC94czpzaW1wbGVU eXBlPg0KICAgICAgICAgPHhzOnNpbXBsZVR5cGU+DQogICAgICAgICAgIDx4czpyZXN0cmljdGlv biBiYXNlPSJpbmV0OmlwdjZBZGRyZXNzIj4NCiAgICAgICAgICAgPC94czpyZXN0cmljdGlvbj4N CiAgICAgICAgIDwveHM6c2ltcGxlVHlwZT4NCiAgICAgICA8L3hzOnVuaW9uPg0KICAgICA8L3hz OnNpbXBsZVR5cGU+DQoNCiAgICAgPHhzOnNpbXBsZVR5cGUgbmFtZT0iaXB2NEFkZHJlc3MiPg0K ICAgICAgIDx4czphbm5vdGF0aW9uPg0KICAgICAgICAgPHhzOmRvY3VtZW50YXRpb24+DQogICAg ICAgICAgIFRoZSBpcHY0QWRkcmVzcyB0eXBlIHJlcHJlc2VudHMgYW4gSVB2NCBhZGRyZXNzIGlu DQogICAgICAgICAgIGRvdHRlZC1xdWFkIG5vdGF0aW9uLiBUaGUgSVB2NCBhZGRyZXNzIG1heSBp bmNsdWRlDQogICAgICAgICAgIGEgem9uZSBpbmRleCwgc2VwYXJhdGVkIGJ5IGEgJSBzaWduLg0K ICAgICAgICAgPC94czpkb2N1bWVudGF0aW9uPg0KICAgICAgIDwveHM6YW5ub3RhdGlvbj4NCg0K ICAgICAgIDx4czpyZXN0cmljdGlvbiBiYXNlPSJ4czpzdHJpbmciPg0KICAgICAgICAgPHhzOnBh dHRlcm4gdmFsdWU9DQogICAgICAgICAgICAgICAgICAiKChbMC0xXT9bMC05XT9bMC05XXwyWzAt NF1bMC05XXwyNVswLTVdKVwuKXszfQ0KICAgICAgICAgICAgICAgICAgIChbMC0xXT9bMC05XT9b MC05XXwyWzAtNF1bMC05XXwyNVswLTVdKQ0KICAgICAgICAgICAgICAgICAgICglW1xwe059XHB7 TH1dKyk/Ii8+DQogICAgICAgPC94czpyZXN0cmljdGlvbj4NCiAgICAgPC94czpzaW1wbGVUeXBl Pg0KDQogICAgIDx4czpzaW1wbGVUeXBlIG5hbWU9ImlwdjZBZGRyZXNzIj4NCiAgICAgICA8eHM6 YW5ub3RhdGlvbj4NCiAgICAgICAgIDx4czpkb2N1bWVudGF0aW9uPg0KICAgICAgICAgICBUaGUg aXB2NkFkZHJlc3MgdHlwZSByZXByZXNlbnRzIGFuIElQdjYgYWRkcmVzcyBpbg0KICAgICAgICAg ICBmdWxsLCBtaXhlZCwgc2hvcnRlbmVkIGFuZCBzaG9ydGVuZWQgbWl4ZWQgbm90YXRpb24uDQog ICAgICAgICAgIFRoZSBJUHY2IGFkZHJlc3MgbWF5IGluY2x1ZGUgYSB6b25lIGluZGV4LCBzZXBh cmF0ZWQNCiAgICAgICAgICAgYnkgYSAlIHNpZ24uDQogICAgICAgICA8L3hzOmRvY3VtZW50YXRp b24+DQogICAgICAgPC94czphbm5vdGF0aW9uPg0KDQogICAgICAgPHhzOnJlc3RyaWN0aW9uIGJh c2U9InhzOnN0cmluZyI+DQogICAgICAgICA8eHM6cGF0dGVybiB2YWx1ZT0NCiAgICAgICAgICAg ICAgICAgICIoKChbMC05YS1mQS1GXXsxLDR9Oil7N30pKFswLTlhLWZBLUZdezEsNH0pDQogICAg ICAgICAgICAgICAgICAgKCVbXHB7Tn1ccHtMfV0rKT8pDQogICAgICAgICAgICAgICAgICAgfCgo KFswLTlhLWZBLUZdezEsNH06KXs2fSkoKFswLTldezEsM31cLg0KICAgICAgICAgICAgICAgICAg ICAgICBbMC05XXsxLDN9XC5bMC05XXsxLDN9XC5bMC05XXsxLDN9KSkNCiAgICAgICAgICAgICAg ICAgICAgKCVbXHB7Tn1ccHtMfV0rKT8pDQogICAgICAgICAgICAgICAgICB8KCgoWzAtOWEtZkEt Rl17MSw0fTopKihbMC05YS1mQS1GXXsxLDR9KSkqKDo6KQ0KICAgICAgICAgICAgICAgICAgICAo KFswLTlhLWZBLUZdezEsNH06KSooWzAtOWEtZkEtRl17MSw0fSkpKg0KICAgICAgICAgICAgICAg ICAgICAoJVtccHtOfVxwe0x9XSspPykNCiAgICAgICAgICAgICAgICAgICgoKFswLTlhLWZBLUZd ezEsNH06KSooWzAtOWEtZkEtRl17MSw0fSkpKig6OikNCiAgICAgICAgICAgICAgICAgICAoKFsw LTlhLWZBLUZdezEsNH06KSooWzAtOWEtZkEtRl17MSw0fSkpKg0KICAgICAgICAgICAgICAgICAg ICgoWzAtOV17MSwzfVwuWzAtOV17MSwzfVwuWzAtOV17MSwzfVwuWzAtOV17MSwzfSkpDQogICAg ICAgICAgICAgICAgICAgICglW1xwe059XHB7TH1dKyk/KSIvPg0KICAgICAgIDwveHM6cmVzdHJp Y3Rpb24+DQogICAgIDwveHM6c2ltcGxlVHlwZT4NCg0KICAgICA8eHM6c2ltcGxlVHlwZSBuYW1l PSJkb21haW5OYW1lIj4NCiAgICAgICA8eHM6YW5ub3RhdGlvbj4NCiAgICAgICAgIDx4czpkb2N1 bWVudGF0aW9uPg0KICAgICAgICAgICBUaGUgZG9tYWluTmFtZSB0eXBlIHJlcHJlc2VudHMgYSBE TlMgZG9tYWluDQogICAgICAgICAgIG5hbWUuIFRoZSBuYW1lIFNIT1VMRCBiZSBmdWxseSBxdWFs aWZpZWQNCiAgICAgICAgICAgd2hlbmV2ZXIgcG9zc2libGUuDQoNCiAgICAgICAgICAgVGhlIGRl c2NyaXB0aW9uIGNsYXVzZSBvZiBvYmplY3RzIHVzaW5nIHRoZQ0KICAgICAgICAgICBkb21haW5O YW1lIHR5cGUgTVVTVCBkZXNjcmliZSBob3cgKGFuZCB3aGVuKQ0KICAgICAgICAgICB0aGVzZSBu YW1lcyBhcmUgcmVzb2x2ZWQgdG8gSVAgYWRkcmVzc2VzLg0KDQogICAgICAgICAgIE5vdGUgdGhh dCB0aGUgcmVzb2x1dGlvbiBvZiBhIGRvbWFpbk5hbWUgdmFsdWUNCiAgICAgICAgICAgbWF5IHJl cXVpcmUgdG8gcXVlcnkgbXVsdGlwbGUgRE5TIHJlY29yZHMgKGUuZy4sDQogICAgICAgICAgIEEg Zm9yIElQdjQgYW5kIEFBQUEgZm9yIElQdjYpLiAgVGhlIG9yZGVyIG9mIHRoZQ0KICAgICAgICAg ICByZXNvbHV0aW9uIHByb2Nlc3MgYW5kIHdoaWNoIEROUyByZWNvcmQgdGFrZXMNCiAgICAgICAg ICAgcHJlY2VkZW5jZSBkZXBlbmRzIG9uIHRoZSBjb25maWd1cmF0aW9uIG9mIHRoZQ0KICAgICAg ICAgICByZXNvbHZlci4NCiAgICAgICAgIDwveHM6ZG9jdW1lbnRhdGlvbj4NCiAgICAgICA8L3hz OmFubm90YXRpb24+DQoNCiAgICAgICA8eHM6cmVzdHJpY3Rpb24gYmFzZT0ieHM6c3RyaW5nIj4N CiAgICAgICAgIDx4czpwYXR0ZXJuIHZhbHVlPSIoW1xwe0x9XHB7Tn1dK1wuKSpbXHB7TH1ccHtO fV0iLz4NCiAgICAgICA8L3hzOnJlc3RyaWN0aW9uPg0KICAgICA8L3hzOnNpbXBsZVR5cGU+DQoN CiAgICAgPHhzOnNpbXBsZVR5cGUgbmFtZT0iaG9zdCI+DQogICAgICAgPHhzOmFubm90YXRpb24+ DQogICAgICAgICA8eHM6ZG9jdW1lbnRhdGlvbj4NCiAgICAgICAgICAgVGhlIGhvc3QgdHlwZSBy ZXByZXNlbnRzIGVpdGhlciBhbiBJUCBhZGRyZXNzDQogICAgICAgICAgIG9yIGEgRE5TIGRvbWFp biBuYW1lLg0KICAgICAgICAgPC94czpkb2N1bWVudGF0aW9uPg0KICAgICAgIDwveHM6YW5ub3Rh dGlvbj4NCg0KICAgICAgIDx4czp1bmlvbj4NCiAgICAgICAgIDx4czpzaW1wbGVUeXBlPg0KICAg ICAgICAgICA8eHM6cmVzdHJpY3Rpb24gYmFzZT0iaW5ldDppcEFkZHJlc3MiPg0KICAgICAgICAg ICA8L3hzOnJlc3RyaWN0aW9uPg0KICAgICAgICAgPC94czpzaW1wbGVUeXBlPg0KICAgICAgICAg PHhzOnNpbXBsZVR5cGU+DQogICAgICAgICAgIDx4czpyZXN0cmljdGlvbiBiYXNlPSJpbmV0OmRv bWFpbk5hbWUiPg0KICAgICAgICAgICA8L3hzOnJlc3RyaWN0aW9uPg0KICAgICAgICAgPC94czpz aW1wbGVUeXBlPg0KICAgICAgIDwveHM6dW5pb24+DQogICAgIDwveHM6c2ltcGxlVHlwZT4NCg0K ICAgPC94czpzY2hlbWE+ ------_=_NextPart_001_01C933BF.1755F13C 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_001_01C933BF.1755F13C-- From netconf-bounces@ietf.org Wed Oct 22 04:00: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 63D9A3A6B8C; Wed, 22 Oct 2008 04:00: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 0DF0B28C11C; Wed, 22 Oct 2008 04: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: <20081022110002.0DF0B28C11C@core3.amsl.com> Date: Wed, 22 Oct 2008 04:00:02 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-tls-06.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-06.txt Pages : 9 Date : 2008-10-22 The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-06.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-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-22034949.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 Oct 22 04:00: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 63D9A3A6B8C; Wed, 22 Oct 2008 04:00: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 0DF0B28C11C; Wed, 22 Oct 2008 04: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: <20081022110002.0DF0B28C11C@core3.amsl.com> Date: Wed, 22 Oct 2008 04:00:02 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-tls-06.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-06.txt Pages : 9 Date : 2008-10-22 The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-06.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-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-22034949.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 Oct 22 04:15:33 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 0BC8F3A6B97; Wed, 22 Oct 2008 04:15:33 -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 4EB9B28C128 for ; Wed, 22 Oct 2008 04:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.515 X-Spam-Level: X-Spam-Status: No, score=-0.515 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_LIST=2.3] 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 sIuUrPz7SS4u for ; Wed, 22 Oct 2008 04:15:31 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 29D523A6B87 for ; Wed, 22 Oct 2008 04:15:31 -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 m9MCGEJT946372 for ; Wed, 22 Oct 2008 13:16:14 +0100 Message-ID: <48FF0B47.90905@isima.fr> Date: Wed, 22 Oct 2008 13:15:19 +0200 From: Mohamad Badra User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: netconf@ietf.org Content-Type: multipart/mixed; boundary="------------060903090803030006030002" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Wed, 22 Oct 2008 13:16:14 +0100 (WEST) Subject: [Netconf] [Fwd: I-D Action:draft-ietf-netconf-tls-06.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 This is a multi-part message in MIME format. --------------060903090803030006030002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I posted a revised version of draft-ietf-netconf-tls with the following editorial changes. (1) Section 2.1, 1st paragraph: Near the end of that paragraph, insert "case" : ..., in which case the server replies ... ^^^^^^ (2) Section 3.1: s/left-most/leftmost/ (3) Section 5, replace "Anycast" with "No" Broadcast, Multicast or Anycast: No. ^^^^ Best regrads, -- Mohamad Badra CNRS - LIMOS Laboratory --------------060903090803030006030002 Content-Type: message/rfc822; name="[Netconf] I-D Action:draft-ietf-netconf-tls-06.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="[Netconf] I-D Action:draft-ietf-netconf-tls-06.txt.eml" X-Account-Key: account2 X-Mozilla-Keys: Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m9MC1PK1950406 for ; Wed, 22 Oct 2008 13:01:26 +0100 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 851423A6B91; Wed, 22 Oct 2008 04:00: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 0DF0B28C11C; Wed, 22 Oct 2008 04: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: From netconf-bounces@ietf.org Wed Oct 22 04:15:33 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 0BC8F3A6B97; Wed, 22 Oct 2008 04:15:33 -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 4EB9B28C128 for ; Wed, 22 Oct 2008 04:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.515 X-Spam-Level: X-Spam-Status: No, score=-0.515 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_LIST=2.3] 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 sIuUrPz7SS4u for ; Wed, 22 Oct 2008 04:15:31 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 29D523A6B87 for ; Wed, 22 Oct 2008 04:15:31 -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 m9MCGEJT946372 for ; Wed, 22 Oct 2008 13:16:14 +0100 Message-ID: <48FF0B47.90905@isima.fr> Date: Wed, 22 Oct 2008 13:15:19 +0200 From: Mohamad Badra User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: netconf@ietf.org Content-Type: multipart/mixed; boundary="------------060903090803030006030002" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Wed, 22 Oct 2008 13:16:14 +0100 (WEST) Subject: [Netconf] [Fwd: I-D Action:draft-ietf-netconf-tls-06.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 This is a multi-part message in MIME format. --------------060903090803030006030002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I posted a revised version of draft-ietf-netconf-tls with the following editorial changes. (1) Section 2.1, 1st paragraph: Near the end of that paragraph, insert "case" : ..., in which case the server replies ... ^^^^^^ (2) Section 3.1: s/left-most/leftmost/ (3) Section 5, replace "Anycast" with "No" Broadcast, Multicast or Anycast: No. ^^^^ Best regrads, -- Mohamad Badra CNRS - LIMOS Laboratory --------------060903090803030006030002 Content-Type: message/rfc822; name="[Netconf] I-D Action:draft-ietf-netconf-tls-06.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="[Netconf] I-D Action:draft-ietf-netconf-tls-06.txt.eml" X-Account-Key: account2 X-Mozilla-Keys: Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m9MC1PK1950406 for ; Wed, 22 Oct 2008 13:01:26 +0100 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 851423A6B91; Wed, 22 Oct 2008 04:00: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 0DF0B28C11C; Wed, 22 Oct 2008 04: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 Messag<20081022110002.0DF0B28C11C@core3.amsl.com> Date: Wed, 22 Oct 2008 04:00:02 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-tls-06.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 X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Wed, 22 Oct 2008 13:01:26 +0100 (WEST) X-Virus-Scanned: by AMaViS 0.3.12 --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-06.txt Pages : 9 Date : 2008-10-22 The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-06.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-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-22034949.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-- --------------060903090803030006030002 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 --------------060903090803030006030002-- e-Id: <20081022110002.0DF0B28C11C@core3.amsl.com> Date: Wed, 22 Oct 2008 04:00:02 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-tls-06.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 X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Wed, 22 Oct 2008 13:01:26 +0100 (WEST) X-Virus-Scanned: by AMaViS 0.3.12 --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-06.txt Pages : 9 Date : 2008-10-22 The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-06.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-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-22034949.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-- --------------060903090803030006030002 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 --------------060903090803030006030002-- From netconf-bounces@ietf.org Wed Oct 22 07:05:43 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 1E8F83A6804; Wed, 22 Oct 2008 07:05:43 -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 982793A6804 for ; Wed, 22 Oct 2008 07:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.024, 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 CZPDs4-TBeWA for ; Wed, 22 Oct 2008 07:05:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 653013A677D for ; Wed, 22 Oct 2008 07:05:41 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C020DC0032; Wed, 22 Oct 2008 16:06:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6oCfWbo47ZNV; Wed, 22 Oct 2008 16:06:50 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D4561C0055; Wed, 22 Oct 2008 16:06:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 69C9A82640D; Wed, 22 Oct 2008 16:06:50 +0200 (CEST) Date: Wed, 22 Oct 2008 16:06:50 +0200 From: Juergen Schoenwaelder To: Mark Scott Message-ID: <20081022140650.GA26069@elstar.local> Mail-Followup-To: Mark Scott , netconf@ietf.org References: <238C6E77EA42504DA038BAEE6D1C11EC4BA87B@zcarhxm0.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <238C6E77EA42504DA038BAEE6D1C11EC4BA87B@zcarhxm0.corp.nortel.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72 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, Oct 21, 2008 at 04:53:32PM -0400, Mark Scott wrote: > An open item discussed at IETF 72 is the definition of data types in the > monitoring draft. Specifically whether or not data types required in > the model should be explicitly defined in this draft or whether they > should reference other standardized XSD definitions (where they exist). > > In particular draft-ietf-netconf-monitoring-02 currently contains an > explicit definition for an IP address data type. This can be found in > sec 5.2 of the draft. I have also included it below for reference. > > Rationale at the time of authoring v02 was to explicitly define this > since no other standardized XSD was available. Although I am aware of > similiar work in-progress to define standardized XSDFrom netconf-bounces@ietf.org Wed Oct 22 07:05:43 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 1E8F83A6804; Wed, 22 Oct 2008 07:05:43 -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 982793A6804 for ; Wed, 22 Oct 2008 07:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.024, 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 CZPDs4-TBeWA for ; Wed, 22 Oct 2008 07:05:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 653013A677D for ; Wed, 22 Oct 2008 07:05:41 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C020DC0032; Wed, 22 Oct 2008 16:06:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6oCfWbo47ZNV; Wed, 22 Oct 2008 16:06:50 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D4561C0055; Wed, 22 Oct 2008 16:06:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 69C9A82640D; Wed, 22 Oct 2008 16:06:50 +0200 (CEST) Date: Wed, 22 Oct 2008 16:06:50 +0200 From: Juergen Schoenwaelder To: Mark Scott Message-ID: <20081022140650.GA26069@elstar.local> Mail-Followup-To: Mark Scott , netconf@ietf.org References: <238C6E77EA42504DA038BAEE6D1C11EC4BA87B@zcarhxm0.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <238C6E77EA42504DA038BAEE6D1C11EC4BA87B@zcarhxm0.corp.nortel.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72 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, Oct 21, 2008 at 04:53:32PM -0400, Mark Scott wrote: > An open item discussed at IETF 72 is the definition of data types in the > monitoring draft. Specifically whether or not data types required in > the model should be explicitly defined in this draft or whether they > should reference other standardized XSD definitions (where they exist). > > In particular draft-ietf-netconf-monitoring-02 currently contains an > explicit definition for an IP address data type. This can be found in > sec 5.2 of the draft. I have also included it below for reference. > > Rationale at the time of authoring v02 was to explicitly define this > since no other standardized XSD was available. Although I am aware of > similiar work in-progress to define standardiz data types I am > still now aware of one suitable for this draft at this time. Do you have a list of work in progress documents where similar XSD definitions are provided? > The item which looked most promising (which was discussed in Dublin) was > alignment to the definitions in > draft-ietf-opsawg-smi-datatypes-in-xsd-03 (sec 5.4). That draft focuses > on representing existing SMI datatypes in XSD. This in insufficient for > the needs of the monitoring draft where we require an enhanced > definition. In particular one with the ability to handle both IPv4 and > IPv6 addresses. > > So I would like to seek concencus from the group that the current > explicit definition in draft-ietf-netconf-monitoring-02 is sufficient > for our NETCONF monitoring needs and that we will leave the explicit > definition in the draft in the next update (-03). Some questions: a) What is going to be the final scope of this? Are these definitions going to be NETCONF monitoring specific only or are there expectations that these definitions are used in the wider context of the IETF? (The suggested namespace might imply a much wider context.) b) I see differences in the patterns compared to what we have in draft-ietf-netmod-yang-types-00.txt (and the corresponding XSD in the appendix). Perhaps this should be synchronized. c) In the context of the YANG work, we recently discussed the issue of types allowing multiple representations for a single value from the value space. This leads to the question of normalization. For example, IPv6 addresses can be represented in different ways, e.g., ::1 and 0:0:0:0:0:0:0:1 denote the same value. If we assume that a NETCONF implementation only maintains the value and not its representation, is there a normalized representation you can expect to be returned by the NETCONF server? Since you are dealing with IPv6 addresses, you might have to deal with the same issue (and not surprisingly, I like the NETCONF monitoring document to be consistent with the YANG types document about this issue). /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 ed XSD data types I am > still now aware of one suitable for this draft at this time. Do you have a list of work in progress documents where similar XSD definitions are provided? > The item which looked most promising (which was discussed in Dublin) was > alignment to the definitions in > draft-ietf-opsawg-smi-datatypes-in-xsd-03 (sec 5.4). That draft focuses > on representing existing SMI datatypes in XSD. This in insufficient for > the needs of the monitoring draft where we require an enhanced > definition. In particular one with the ability to handle both IPv4 and > IPv6 addresses. > > So I would like to seek concencus from the group that the current > explicit definition in draft-ietf-netconf-monitoring-02 is sufficient > for our NETCONF monitoring needs and that we will leave the explicit > definition in the draft in the next update (-03). Some questions: a) What is going to be the final scope of this? Are these definitions going to be NETCONF monitoring specific only or are there expectations that these definitions are used in the wider context of the IETF? (The suggested namespace might imply a much wider context.) b) I see differences in the patterns compared to what we have in draft-ietf-netmod-yang-types-00.txt (and the corresponding XSD in the appendix). Perhaps this should be synchronized. c) In the context of the YANG work, we recently discussed the issue of types allowing multiple representations for a single value from the value space. This leads to the question of normalization. For example, IPv6 addresses can be represented in different ways, e.g., ::1 and 0:0:0:0:0:0:0:1 denote the same value. If we assume that a NETCONF implementation only maintains the value and not its representation, is there a normalized representation you can expect to be returned by the NETCONF server? Since you are dealing with IPv6 addresses, you might have to deal with the same issue (and not surprisingly, I like the NETCONF monitoring document to be consistent with the YANG types document about this issue). /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 Wed Oct 22 09:18: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 74B9D3A69B8; Wed, 22 Oct 2008 09:18: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 8A2E23A68AD for ; Wed, 22 Oct 2008 09:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 6uyweXaU+1ZH for ; Wed, 22 Oct 2008 09:18:01 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 9B4EF3A69B8 for ; Wed, 22 Oct 2008 09:18:00 -0700 (PDT) Received: (qmail 17945 invoked from network); 22 Oct 2008 16:19:16 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 22 Oct 2008 16:19:16 -0000 Message-ID: From: "Bert Wijnen \(IETF\)" To: , "Mark Scott" References: <238C6E77EA42504DA038BAEE6D1C11EC4BA87B@zcarhxm0.corp.nortel.com> <20081022140650.GA26069@elstar.local> In-Reply-To: <20081022140650.GA26069@elstar.local> Date: Wed, 22 Oct 2008 18:18:58 +0200 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72 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: multipart/mixed; boundary="===============1404252889==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1404252889== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A54_01C93472.A6A29A00" This is a multi-part message in MIME format. ------=_NextPart_000_0A54_01C93472.A6A29A00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Juergen for your follow up. I have responded to Mark (privately) that we actually had a gentlemens = agreement at=20 the last IETF that he would try to get some interested folk in this = space together to analyze, study the topic and alternatives and that that small group = would then document one or more possile solutions and explain the pros/cons of = each. I hope that that effort will still take place (albeit somewhat later = that we wanted) I also urge those who want to do that work (analyze, document the = alternatives, make some well-documented proposals) to get in tocuh with Mark. You can copy the WG list (or just the WG chairs) if you want. Bert ----- Original Message -----=20 From: Juergen Schoenwaelder=20 To: Mark Scott=20 Cc: netconf@ietf.org=20 Sent: Wednesday, October 22, 2008 4:06 PM Subject: Re: [Netconf] [NETCONF] monitoring data type = definitions;proposed resolution to open item from IETF72 On Tue, Oct 21, 2008 at 04:53:32PM -0400, Mark Scott wrote: =20 > An open item discussed at IETF 72 is the definition of data types in = the > monitoring draft. Specifically whether or not data types required = in > the model should be explicitly defined in this draft or whether they > should reference other standardized XSD definitions (where they = exist). > =20 > In particular draft-ietf-netconf-monitoring-02 currently contains an > explicit definition for an IP address data type. This can be found = in > sec 5.2 of the draft. I have also included it below for reference. > =20 > Rationale at the time of authoring v02 was to explicitly define this > since no other standardized XSD was available. Although I am aware = of > similiar work in-progress to define standardized XSD data types I am > still now aware of one suitable for this draft at this time. Do you have a list of work in progress documents where similar XSD definitions are provided? > The item which looked most promising (which was discussed in Dublin) = was > alignment to the definitions in > draft-ietf-opsawg-smi-datatypes-in-xsd-03 (sec 5.4). That draft = focuses > on representing existing SMI datatypes in XSD. This in insufficient = for > the needs of the monitoring draft where we require an enhanced > definition. In particular one with the ability to handle both IPv4 = and > IPv6 addresses. > =20 > So I would like to seek concencus from the group that the current > explicit definition in draft-ietf-netconf-monitoring-02 is = sufficient > for our NETCONF monitoring needs and that we will leave the explicit > definition in the draft in the next update (-03). Some questions: a) What is going to be the final scope of this? Are these definitions going to be NETCONF monitoring specific only or are there expectations that these definitions are used in the wider context of the IETF? (The suggested namespace might imply a much wider context.) b) I see differences in the patterns compared to what we have in draft-ietf-netmod-yang-types-00.txt (and the corresponding XSD in the appendix). Perhaps this should be synchronized. c) In the context of the YANG work, we recently discussed the issue of types allowing multiple representations for a single value from the value space. This leads to the question of normalization. For example, IPv6 addresses can be represented in different ways, e.g., ::1 and 0:0:0:0:0:0:0:1 denote the same value. If we assume that a NETCONF implementation only maintains the value and not its representation, is there a normalized representation you can expect to be returned by the NETCONF server? Since you are dealing with IPv6 addresses, you might have to deal with the same issue (and not surprisingly, I like the NETCONF monitoring document to be consistent with the YANG types document about this issue). /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_0A54_01C93472.A6A29A00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks Juergen for your follow up.
 
I have responded to Mark (privately) that we = actually had a=20 gentlemens agreement at
the last IETF that he would try to get some = interested folk in=20 this space together
to analyze, study the topic and alternatives and = that that=20 small group would then
document one or more possile solutions and explain = the=20 pros/cons of each.
 
I hope that that effort will still take place = (albeit somewhat=20 later that we wanted)
 
I also urge those who want to do that work (analyze, = document=20 the alternatives,
make some well-documented proposals) to get in tocuh = with=20 Mark.
You can copy the WG list (or just the WG chairs) if = you=20 want.
 
Bert
----- Original Message -----
From:=20 Juergen = Schoenwaelder=20
Sent: Wednesday, October 22, = 2008 4:06=20 PM
Subject: Re: [Netconf] = [NETCONF]=20 monitoring data type definitions;proposed resolution to open item from = IETF72

On Tue, Oct 21, 2008 at 04:53:32PM -0400, Mark Scott=20 wrote:
 
> An open item discussed at IETF 72 is the = definition=20 of data types in the
> monitoring draft.  Specifically = whether or=20 not data types required in
> the model should be explicitly = defined in=20 this draft or whether they
> should reference other standardized = XSD=20 definitions (where they exist).
> 
> In particular=20 draft-ietf-netconf-monitoring-02 currently contains an
> = explicit=20 definition for an IP address data type.  This can be found = in
> sec=20 5.2 of the draft.  I have also included it below for=20 reference.
> 
> Rationale at the time of authoring = v02 was=20 to explicitly define this
> since no other standardized XSD was=20 available.  Although I am aware of
> similiar work = in-progress to=20 define standardized XSD data types I am
> still now aware of one = suitable for this draft at this time.

Do you have a list of = work in=20 progress documents where similar XSD
definitions are = provided?

>=20 The item which looked most promising (which was discussed in Dublin)=20 was
> alignment to the definitions in
>=20 draft-ietf-opsawg-smi-datatypes-in-xsd-03 (sec 5.4).  That draft=20 focuses
> on representing existing SMI datatypes in XSD.  = This in=20 insufficient for
> the needs of the monitoring draft where we = require an=20 enhanced
> definition.  In particular one with the ability = to=20 handle both IPv4 and
> IPv6 addresses.
> 
> So = I would=20 like to seek concencus from the group that the current
> = explicit=20 definition in draft-ietf-netconf-monitoring-02 is sufficient
> = for our=20 NETCONF monitoring needs and that we will leave the explicit
>=20 definition in the draft in the next update (-03).

Some=20 questions:

a) What is going to be the final scope of this? Are = these=20 definitions
   going to be NETCONF monitoring specific = only or=20 are there
   expectations that these definitions are used = in the=20 wider context
   of the IETF? (The suggested namespace = might=20 imply a much wider
   context.)

b) I see = differences in=20 the patterns compared to what we have in
  =20 draft-ietf-netmod-yang-types-00.txt (and the corresponding XSD=20 in
   the appendix). Perhaps this should be=20 synchronized.

c) In the context of the YANG work, we recently = discussed=20 the issue of
   types allowing multiple representations = for a=20 single value from the
   value space. This leads to the = question=20 of normalization. For
   example, IPv6 addresses can be=20 represented in different ways, e.g.,
   ::1 and = 0:0:0:0:0:0:0:1=20 denote the same value. If we assume that a
   NETCONF=20 implementation only maintains the value and not its
  =20 representation, is there a normalized representation you can=20 expect
   to be returned by the NETCONF server? Since you = are=20 dealing with
   IPv6 addresses, you might have to deal = with the=20 same issue (and not
   surprisingly, I like the NETCONF=20 monitoring document to be
   consistent with the YANG = types=20 document about this issue).

/js

--
Juergen=20 = Schoenwaelder          = =20 Jacobs University Bremen gGmbH
Phone: +49 421 200=20 3587         Campus Ring 1, = 28759=20 Bremen, Germany
Fax:   +49 421 200=20 3103         <http://www.jacobs-university.de= />
_______________________________________________
Netconf=20 mailing list
Netconf@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netconf

------=_NextPart_000_0A54_01C93472.A6A29A00-- --===============1404252889== 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 --===============1404252889==-- From netconf-bounces@ietf.org Wed Oct 22 09:18: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 74B9D3A69B8; Wed, 22 Oct 2008 09:18: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 8A2E23A68AD for ; Wed, 22 Oct 2008 09:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 6uyweXaU+1ZH for ; Wed, 22 Oct 2008 09:18:01 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 9B4EF3A69B8 for ; Wed, 22 Oct 2008 09:18:00 -0700 (PDT) Received: (qmail 17945 invoked from network); 22 Oct 2008 16:19:16 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 22 Oct 2008 16:19:16 -0000 Message-ID: From: "Bert Wijnen \(IETF\)" To: , "Mark Scott" References: <238C6E77EA42504DA038BAEE6D1C11EC4BA87B@zcarhxm0.corp.nortel.com> <20081022140650.GA26069@elstar.local> In-Reply-To: <20081022140650.GA26069@elstar.local> Date: Wed, 22 Oct 2008 18:18:58 +0200 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72 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: multipart/mixed; boundary="===============1404252889==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1404252889== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A54_01C93472.A6A29A00" This is a multi-part message in MIME format. ------=_NextPart_000_0A54_01C93472.A6A29A00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Juergen for your follow up. I have responded to Mark (privately) that we actually had a gentlemens = agreement at=20 the last IETF that he would try to get some interested folk in this = space together to analyze, study the topic and alternatives and that that small group = would then document one or more possile solutions and explain the pros/cons of = each. I hope that that effort will still take place (albeit somewhat later = that we wanted) I also urge those who want to do that work (analyze, document the = alternatives, make some well-documented proposals) to get in tocuh with Mark. You can copy the WG list (or just the WG chairs) if you want. Bert ----- Original Message -----=20 From: Juergen Schoenwaelder=20 To: Mark Scott=20 Cc: netconf@ietf.org=20 Sent: Wednesday, October 22, 2008 4:06 PM Subject: Re: [Netconf] [NETCONF] monitoring data type = definitions;proposed resolution to open item from IETF72 On Tue, Oct 21, 2008 at 04:53:32PM -0400, Mark Scott wrote: =20 > An open item discussed at IETF 72 is the definition of data types in = the > monitoring draft. Specifically whether or not data types required = in > the model should be explicitly defined in this draft or whether they > should reference other standardized XSD definitions (where they = exist). > =20 > In particular draft-ietf-netconf-monitoring-02 currently contains an > explicit definition for an IP address data type. This can be found = in > sec 5.2 of the draft. I have also included it below for reference. > =20 > Rationale at the time of authoring v02 was to explicitly define this > since no other standardized XSD was available. Although I am aware = of > similiar work in-progress to define standardized XSD data types I am > still now aware of one suitable for this draft at this time. Do you have a list of work in progress documents where similar XSD definitions are provided? > The item which looked most promising (which was discussed in Dublin) = was > alignment to the definitions in > draft-ietf-opsawg-smi-datatypes-in-xsd-03 (sec 5.4). That draft = focuses > on representing existing SMI datatypes in XSD. This in insufficient = for > the needs of the monitoring draft where we require an enhanced > definition. In particular one with the ability to handle both IPv4 = and > IPv6 addresses. > =20 > So I would like to seek concencus from the group that the current > explicit definition in draft-ietf-netconf-monitoring-02 is = sufficient > for our NETCONF monitoring needs and that we will leave the explicit > definition in the draft in the next update (-03). Some questions: a) What is going to be the final scope of this? Are these definitions going to be NETCONF monitoring specific only or are there expectations that these definitions are used in the wider context of the IETF? (The suggested namespace might imply a much wider context.) b) I see differences in the patterns compared to what we have in draft-ietf-netmod-yang-types-00.txt (and the corresponding XSD in the appendix). Perhaps this should be synchronized. c) In the context of the YANG work, we recently discussed the issue of types allowing multiple representations for a single value from the value space. This leads to the question of normalization. For example, IPv6 addresses can be represented in different ways, e.g., ::1 and 0:0:0:0:0:0:0:1 denote the same value. If we assume that a NETCONF implementation only maintains the value and not its representation, is there a normalized representation you can expect to be returned by the NETCONF server? Since you are dealing with IPv6 addresses, you might have to deal with the same issue (and not surprisingly, I like the NETCONF monitoring document to be consistent with the YANG types document about this issue). /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_0A54_01C93472.A6A29A00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks Juergen for your follow up.
 
I have responded to Mark (privately) that we = actually had a=20 gentlemens agreement at
the last IETF that he would try to get some = interested folk in=20 this space together
to analyze, study the topic and alternatives and = that that=20 small group would then
document one or more possile solutions and explain = the=20 pros/cons of each.
 
I hope that that effort will still take place = (albeit somewhat=20 later that we wanted)
 
I also urge those who want to do that work (analyze, = document=20 the alternatives,
make some well-documented proposals) to get in tocuh = with=20 Mark.
You can copy the WG list (or just the WG chairs) if = you=20 want.
 
Bert
----- Original Message -----
From:=20 Juergen = Schoenwaelder=20
Sent: Wednesday, October 22, = 2008 4:06=20 PM
Subject: Re: [Netconf] = [NETCONF]=20 monitoring data type definitions;proposed resolution to open item from = IETF72

On Tue, Oct 21, 2008 at 04:53:32PM -0400, Mark Scott=20 wrote:
 
> An open item discussed at IETF 72 is the = definition=20 of data types in the
> monitoring draft.  Specifically = whether or=20 not data types required in
> the model should be explicitly = defined in=20 this draft or whether they
> should reference other standardized = XSD=20 definitions (where they exist).
> 
> In particular=20 draft-ietf-netconf-monitoring-02 currently contains an
> = explicit=20 definition for an IP address data type.  This can be found = in
> sec=20 5.2 of the draft.  I have also included it below for=20 reference.
> 
> Rationale at the time of authoring = v02 was=20 to explicitly define this
> since no other standardized XSD was=20 available.  Although I am aware of
> similiar work = in-progress to=20 define standardized XSD data types I am
> still now aware of one = suitable for this draft at this time.

Do you have a list of = work in=20 progress documents where similar XSD
definitions are = provided?

>=20 The item which looked most promising (which was discussed in Dublin)=20 was
> alignment to the definitions in
>=20 draft-ietf-opsawg-smi-datatypes-in-xsd-03 (sec 5.4).  That draft=20 focuses
> on representing existing SMI datatypes in XSD.  = This in=20 insufficient for
> the needs of the monitoring draft where we = require an=20 enhanced
> definition.  In particular one with the ability = to=20 handle both IPv4 and
> IPv6 addresses.
> 
> So = I would=20 like to seek concencus from the group that the current
> = explicit=20 definition in draft-ietf-netconf-monitoring-02 is sufficient
> = for our=20 NETCONF monitoring needs and that we will leave the explicit
>=20 definition in the draft in the next update (-03).

Some=20 questions:

a) What is going to be the final scope of this? Are = these=20 definitions
   going to be NETCONF monitoring specific = only or=20 are there
   expectations that these definitions are used = in the=20 wider context
   of the IETF? (The suggested namespace = might=20 imply a much wider
   context.)

b) I see = differences in=20 the patterns compared to what we have in
  =20 draft-ietf-netmod-yang-types-00.txt (and the corresponding XSD=20 in
   the appendix). Perhaps this should be=20 synchronized.

c) In the context of the YANG work, we recently = discussed=20 the issue of
   types allowing multiple representations = for a=20 single value from the
   value space. This leads to the = question=20 of normalization. For
   example, IPv6 addresses can be=20 represented in different ways, e.g.,
   ::1 and = 0:0:0:0:0:0:0:1=20 denote the same value. If we assume that a
   NETCONF=20 implementation only maintains the value and not its
  =20 representation, is there a normalized representation you can=20 expect
   to be returned by the NETCONF server? Since you = are=20 dealing with
   IPv6 addresses, you might have to deal = with the=20 same issue (and not
   surprisingly, I like the NETCONF=20 monitoring document to be
   consistent with the YANG = types=20 document about this issue).

/js

--
Juergen=20 = Schoenwaelder          = =20 Jacobs University Bremen gGmbH
Phone: +49 421 200=20 3587         Campus Ring 1, = 28759=20 Bremen, Germany
Fax:   +49 421 200=20 3103         <http://www.jacobs-university.de= />
_______________________________________________
Netconf=20 mailing list
Netconf@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netconf

------=_NextPart_000_0A54_01C93472.A6A29A00-- --===============1404252889== 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 --===============1404252889==-- From netconf-bounces@ietf.org Wed Oct 22 09:37: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 31E2D3A68AD; Wed, 22 Oct 2008 09:37: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 E2E773A67DB for ; Wed, 22 Oct 2008 09:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 QSXV6JVilnjW for ; Wed, 22 Oct 2008 09:36:57 -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 CCEB63A6778 for ; Wed, 22 Oct 2008 09:36:57 -0700 (PDT) Received: (qmail 21567 invoked from network); 22 Oct 2008 16:38:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 22 Oct 2008 16:38:12 -0000 X-YMail-OSG: t_7v3QsVM1lTm5UKEGjs0WYcyodoX94RCK8Es75VX0wGFil2GG0EY7JstvnSM4_90sh0uz3Yv1DDcmnsGvx71qGNFI1A8gdTGwQKPOwulsu6196SYDmFVdky8vfZyreGOWwLxxWNljDw7WId8enGxQze X-Yahoo-Newman-Property: ymail-3 Message-ID: <48FF56F2.3060908@netconfcentral.com> Date: Wed, 22 Oct 2008 09:38:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <238C6E77EA42504DA038BAEE6D1C11EC4BA87B@zcarhxm0.corp.nortel.com> <20081022140650.GA26069@elstar.local> In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72 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 Bert Wijnen (IETF) wrote: > Thanks Juergen for your follow up. > > I have responded to Mark (privately) that we actually had a gentlemens > agreement at > the last IETF that he would try to get some interested folk in this > space together > to analyze, study the topic and alternatives and that that small group > would then > document one or more possile solutions and explain the pros/cons of each. > > I hope that that effort will still take place (albeit somewhat later > that we wanted) > > I also urge those who want to do that work (analyze, document the > alternatives, > make some well-documented proposals) to get in tocuh with Mark. > You can copy the WG list (or just the WG chairs) if you want. > Creating multiple data model representations of an address is not acceptable. I raised this issue 3 or 4 IETFs ago, and the 'quick-fix' solution is still not available. The most basic data structure in the entire IETF is the InetAddress. If we can't settle on a typedef for an InetAddress after all this time, that is pretty sad. Listen to Juergen. He is right, and we should use inet-types.yang typedefs and patterns. This issue has already been studied, examined, and delayed long enough. > Bert Andy > > ----- Original Message ----- > *From:* Juergen Schoenwaelder > > *To:* Mark Scott > *Cc:* netconf@ietf.org > *Sent:* Wednesday, October 22, 2008 4:06 PM > *Subject:* Re: [Netconf] [NETCONF] monitoring data type > definitions;proposed resolution to open item from IETF72 > > On Tue, Oct 21, 2008 at 04:53:32PM -0400, Mark Scott wrote: > > > An open item discussed at IETF 72 is the definition of data types > in the > > monitoring draft. Specifically whether or not data types required in > > the model should be explicitly defined in this draft or whether they > > should reference other standardized XSD definitions (where they > exist). > > > > In particular draft-ietf-netconf-monitoring-02 currently contains an > > explicit definition for an IP address data type. This can be > found in > > sec 5.2 of the draft. I have also included it below for reference. > > > > Rationale at the time of authoring v02 was to explicitly define this > > since no other standardized XSD was available. Although I am > aware of > > similiar work in-progress to define standardized XSD data types I am > > still now aware of one suitable for this draft at this time. > > Do you have a list of work in progress documents where similar XSD > definitions are provided? > > > The item which looked most promising (which was discussed in > Dublin) was > > alignment to the definitions in > > draft-ietf-opsawg-smi-datatypes-in-xsd-03 (sec 5.4). That draft > focuses > > on representing existing SMI datatypes in XSD. This in > insufficient for > > the needs of the monitoring draft where we require an enhanced > > definition. In particular one with the ability to handle both > IPv4 and > > IPv6 addresses. > > > > So I would like to seek concencus from the group that the current > > explicit definition in draft-ietf-netconf-monitoring-02 is sufficient > > for our NETCONF monitoring needs and that we will leave the explicit > > definition in the draft in the next update (-03). > > Some questions: > > a) What is going to be the final scope of this? Are these definitions > going to be NETCONF monitoring specific only or are there > expectations that these definitions are used in the wider context > of the IETF? (The suggested namespace might imply a much wider > context.) > > b) I see differences in the patterns compared to what we have in > draft-ietf-netmod-yang-types-00.txt (and the corresponding XSD in > the appendix). Perhaps this should be synchronized. > > c) In the context of the YANG work, we recently discussed the issue of > types allowing multiple representations for a single value from the > value space. This leads to the question of normalization. For > example, IPv6 addresses can be represented in different ways, e.g., > ::1 and 0:0:0:0:0:0:0:1 denote the same value. If we assume that a > NETCONF implementation only maintains the value and not its > representation, is there a normalized representation you can expect > to be returned by the NETCONF server? Since you are dealing with > IPv6 addresses, you might have to deal with the same issue (and not > surprisingly, I like the NETCONF monitoring document to be > consistent with the YANG types document about this issue). > > /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 Wed Oct 22 09:37: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 31E2D3A68AD; Wed, 22 Oct 2008 09:37: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 E2E773A67DB for ; Wed, 22 Oct 2008 09:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 QSXV6JVilnjW for ; Wed, 22 Oct 2008 09:36:57 -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 CCEB63A6778 for ; Wed, 22 Oct 2008 09:36:57 -0700 (PDT) Received: (qmail 21567 invoked from network); 22 Oct 2008 16:38:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 22 Oct 2008 16:38:12 -0000 X-YMail-OSG: t_7v3QsVM1lTm5UKEGjs0WYcyodoX94RCK8Es75VX0wGFil2GG0EY7JstvnSM4_90sh0uz3Yv1DDcmnsGvx71qGNFI1A8gdTGwQKPOwulsu6196SYDmFVdky8vfZyreGOWwLxxWNljDw7WId8enGxQze X-Yahoo-Newman-Property: ymail-3 Message-ID: <48FF56F2.3060908@netconfcentral.com> Date: Wed, 22 Oct 2008 09:38:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <238C6E77EA42504DA038BAEE6D1C11EC4BA87B@zcarhxm0.corp.nortel.com> <20081022140650.GA26069@elstar.local> In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72 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 Bert Wijnen (IETF) wrote: > Thanks Juergen for your follow up. > > I have responded to Mark (privately) that we actually had a gentlemens > agreement at > the last IETF that he would try to get some interested folk in this > space together > to analyze, study the topic and alternatives and that that small group > would then > document one or more possile solutions and explain the pros/cons of each. > > I hope that that effort will still take place (albeit somewhat later > that we wanted) > > I also urge those who want to do that work (analyze, document the > alternatives, > make some well-documented proposals) to get in tocuh with Mark. > You can copy the WG list (or just the WG chairs) if you want. > Creating multiple data model representations of an address is not acceptable. I raised this issue 3 or 4 IETFs ago, and the 'quick-fix' solution is still not available. The most basic data structure in the entire IETF is the InetAddress. If we can't settle on a typedef for an InetAddress after all this time, that is pretty sad. Listen to Juergen. He is right, and we should use inet-types.yang typedefs and patterns. This issue has already been studied, examined, and delayed long enough. > Bert Andy > > ----- Original Message ----- > *From:* Juergen Schoenwaelder > > *To:* Mark Scott > *Cc:* netconf@ietf.org > *Sent:* Wednesday, October 22, 2008 4:06 PM > *Subject:* Re: [Netconf] [NETCONF] monitoring data type > definitions;proposed resolution to open item from IETF72 > > On Tue, Oct 21, 2008 at 04:53:32PM -0400, Mark Scott wrote: > > > An open item discussed at IETF 72 is the definition of data types > in the > > monitoring draft. Specifically whether or not data types required in > > the model should be explicitly defined in this draft or whether they > > should reference other standardized XSD definitions (where they > exist). > > > > In particular draft-ietf-netconf-monitoring-02 currently contains an > > explicit definition for an IP address data type. This can be > found in > > sec 5.2 of the draft. I have also included it below for reference. > > > > Rationale at the time of authoring v02 was to explicitly define this > > since no other standardized XSD was available. Although I am > aware of > > similiar work in-progress to define standardized XSD data types I am > > still now aware of one suitable for this draft at this time. > > Do you have a list of work in progress documents where similar XSD > definitions are provided? > > > The item which looked most promising (which was discussed in > Dublin) was > > alignment to the definitions in > > draft-ietf-opsawg-smi-datatypes-in-xsd-03 (sec 5.4). That draft > focuses > > on representing existing SMI datatypes in XSD. This in > insufficient for > > the needs of the monitoring draft where we require an enhanced > > definition. In particular one with the ability to handle both > IPv4 and > > IPv6 addresses. > > > > So I would like to seek concencus from the group that the current > > explicit definition in draft-ietf-netconf-monitoring-02 is sufficient > > for our NETCONF monitoring needs and that we will leave the explicit > > definition in the draft in the next update (-03). > > Some questions: > > a) What is going to be the final scope of this? Are these definitions > going to be NETCONF monitoring specific only or are there > expectations that these definitions are used in the wider context > of the IETF? (The suggested namespace might imply a much wider > context.) > > b) I see differences in the patterns compared to what we have in > draft-ietf-netmod-yang-types-00.txt (and the corresponding XSD in > the appendix). Perhaps this should be synchronized. > > c) In the context of the YANG work, we recently discussed the issue of > types allowing multiple representations for a single value from the > value space. This leads to the question of normalization. For > example, IPv6 addresses can be represented in different ways, e.g., > ::1 and 0:0:0:0:0:0:0:1 denote the same value. If we assume that a > NETCONF implementation only maintains the value and not its > representation, is there a normalized representation you can expect > to be returned by the NETCONF server? Since you are dealing with > IPv6 addresses, you might have to deal with the same issue (and not > surprisingly, I like the NETCONF monitoring document to be > consistent with the YANG types document about this issue). > > /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 Wed Oct 22 11:01: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 6A16228C1B5; Wed, 22 Oct 2008 11:01: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 EFECF28C1B5 for ; Wed, 22 Oct 2008 11:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.024, 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 nwLRX8OLXZjc for ; Wed, 22 Oct 2008 11:01:44 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 493D23A6A08 for ; Wed, 22 Oct 2008 11:01:37 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1CDADC002A; Wed, 22 Oct 2008 20:02:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7LpZcKAmE2Tq; Wed, 22 Oct 2008 20:02:47 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D11FC0027; Wed, 22 Oct 2008 20:02:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CB1A7826A25; Wed, 22 Oct 2008 20:02:45 +0200 (CEST) Date: Wed, 22 Oct 2008 20:02:45 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20081022180245.GA26907@elstar.local> Mail-Followup-To: Andy Bierman , "Bert Wijnen (IETF)" , Mark Scott , netconf@ietf.org References: <238C6E77EA42504DA038BAEE6D1C11EC4BA87B@zcarhxm0.corp.nortel.com> <20081022140650.GA26069@elstar.local> <48FF56F2.3060908@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48FF56F2.3060908@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72 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 Wed, Oct 22, 2008 at 09:38:10AM -0700, Andy Bierman wrote: > Creating multiple data model representations of an address > is not acceptable. I raised this issue 3 or 4 IETFs ago, > and the 'quick-fix' solution is still not available. > > The most basic data structure in the entire IETF is > the InetAddress. If we can't settle on a typedef for an > InetAddress after all this time, that is pretty sad. A single XSD definition of an IP address is not going to happen anymore and probably this is not really a drama. I think EPP has an XSD definition in RFCs and I would not be surprised to find more if I start searching more systematically. > Listen to Juergen. He is right, and we should use inet-types.yang > typedefs and patterns. This issue has already been studied, > examined, and delayed long enough. Since it is too late (and too difficult) to have consistent IETF wide definitions, having consistent definitions for NETCONF content or even within IETF management content might be a more realistic goal. /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 Wed Oct 22 11:01: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 6A16228C1B5; Wed, 22 Oct 2008 11:01: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 EFECF28C1B5 for ; Wed, 22 Oct 2008 11:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.024, 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 nwLRX8OLXZjc for ; Wed, 22 Oct 2008 11:01:44 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 493D23A6A08 for ; Wed, 22 Oct 2008 11:01:37 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1CDADC002A; Wed, 22 Oct 2008 20:02:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7LpZcKAmE2Tq; Wed, 22 Oct 2008 20:02:47 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D11FC0027; Wed, 22 Oct 2008 20:02:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CB1A7826A25; Wed, 22 Oct 2008 20:02:45 +0200 (CEST) Date: Wed, 22 Oct 2008 20:02:45 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20081022180245.GA26907@elstar.local> Mail-Followup-To: Andy Bierman , "Bert Wijnen (IETF)" , Mark Scott , netconf@ietf.org References: <238C6E77EA42504DA038BAEE6D1C11EC4BA87B@zcarhxm0.corp.nortel.com> <20081022140650.GA26069@elstar.local> <48FF56F2.3060908@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48FF56F2.3060908@netconfcentral.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72 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 Wed, Oct 22, 2008 at 09:38:10AM -0700, Andy Bierman wrote: > Creating multiple data model representations of an address > is not acceptable. I raised this issue 3 or 4 IETFs ago, > and the 'quick-fix' solution is still not available. > > The most basic data structure in the entire IETF is > the InetAddress. If we can't settle on a typedef for an > InetAddress after all this time, that is pretty sad. A single XSD definition of an IP address is not going to happen anymore and probably this is not really a drama. I think EPP has an XSD definition in RFCs and I would not be surprised to find more if I start searching more systematically. > Listen to Juergen. He is right, and we should use inet-types.yang > typedefs and patterns. This issue has already been studied, > examined, and delayed long enough. Since it is too late (and too difficult) to have consistent IETF wide definitions, having consistent definitions for NETCONF content or even within IETF management content might be a more realistic goal. /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 Wed Oct 22 14:33:31 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 6B8233A6AA2; Wed, 22 Oct 2008 14:33:31 -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 64CBD3A6861 for ; Wed, 22 Oct 2008 14:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-1.300, 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 S5hHtXLyX4bM for ; Wed, 22 Oct 2008 14:33: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 3D9AE3A6AA2 for ; Wed, 22 Oct 2008 14:33:29 -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 m9MLYeXE024129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Oct 2008 23:34:40 +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 m9MLYbA9028506; Wed, 22 Oct 2008 23:34:40 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Oct 2008 23:34:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Oct 2008 23:34:25 +0200 Message-ID: In-Reply-To: <56055.88.175.65.115.1224282864.squirrel@www.isima.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-netconf-tls for IESG Review Thread-Index: AckwqIjr7uN2Z5tOTqCEt5fBd8zGnAD0oyxQ References: <56055.88.175.65.115.1224282864.squirrel@www.isima.fr> From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 22 Oct 2008 21:34:27.0341 (UTC) FILETIME=[F5AABBD0:01C9348D] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081022233440-6ABE5BB0-621F7260/0-0/0-15 X-purgate-size: 2127/0 Subject: [Netconf] draft-ietf-netconf-tls for IESG Review 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 NETCONF WG, based on the WGLC discussions and the resulting new document for NETCONF over TLS the WG co-chairs believe that the draft has WG consensus to proceed to the IESG for publication as a PS RFC. (see http://tools.ietf.org/html/draft-ietf-netconf-tls-06 and the summary of the changes in http://www.ietf.org/mail-archive/web/netconf/current/msg03873.html and http://www.ietf.org/mail-archive/web/netconf/current/msg03882.html) Unless anybody has strong objections before Okt 28th, we will bring the WG item one step further and ask Dan for the consideration for IESG review. Cheers, Mehmet & Bert > -----OriFrom netconf-bounces@ietf.org Wed Oct 22 14:33:31 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 6B8233A6AA2; Wed, 22 Oct 2008 14:33:31 -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 64CBD3A6861 for ; Wed, 22 Oct 2008 14:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-1.300, 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 S5hHtXLyX4bM for ; Wed, 22 Oct 2008 14:33: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 3D9AE3A6AA2 for ; Wed, 22 Oct 2008 14:33:29 -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 m9MLYeXE024129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Oct 2008 23:34:40 +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 m9MLYbA9028506; Wed, 22 Oct 2008 23:34:40 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Oct 2008 23:34:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Oct 2008 23:34:25 +0200 Message-ID: In-Reply-To: <56055.88.175.65.115.1224282864.squirrel@www.isima.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-netconf-tls for IESG Review Thread-Index: AckwqIjr7uN2Z5tOTqCEt5fBd8zGnAD0oyxQ References: <56055.88.175.65.115.1224282864.squirrel@www.isima.fr> From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 22 Oct 2008 21:34:27.0341 (UTC) FILETIME=[F5AABBD0:01C9348D] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081022233440-6ABE5BB0-621F7260/0-0/0-15 X-purgate-size: 2127/0 Subject: [Netconf] draft-ietf-netconf-tls for IESG Review 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 NETCONF WG, based on the WGLC discussions and the resulting new document for NETCONF over TLS the WG co-chairs believe that the draft has WG consensus to proceed to the IESG for publication as a PS RFC. (see http://tools.ietf.org/html/draft-ietf-netconf-tls-06 and the summary of the changes in http://www.ietf.org/mail-archive/web/netconf/current/msg03873.html and http://www.ietf.org/mail-archive/web/netconf/current/msg03882.html) Unless anybody has strong objections before Okt 28th, we will bring the WG item one step further and ask Dan for the consideration for IESG review. Cheers, Mehmet & Bert > -----Original ginal Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext badra@isima.fr > Sent: Saturday, October 18, 2008 12:34 AM > To: netconf@ietf.org > Subject: [Netconf] New version of draft-ietf-netconf-tls > > Dear all, > > After the WGLC, I posted a revised version of draft-ietf-netconf-tls, > which addresses comments and issues raised during the WGLC. Below is a > summary of changes, please don't hesitate to read the > document and send > your comments on any missed point. > > Changes from -04 > > Removed any text related to PSK based authentication. > > Revised to TLS with certificate-based mutual authentication. > > Removed Cipher Suite Requirements section which was > redundant with TLS. > > Added small clarifications to the "Introduction" and "Endpoint > Authentication and Identification" sections. > > Section 2.1: Included mandatory to implement cipher suites > that track > future versions of the TLS > > Section 2.2: Revised the connection closure session with regards to > TLS 1.2 > > Section 5: Revised to help IANA with the port assignment. > > Section 8: Removed RFC4086 and RFC4279 from the reference section > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-05.txt > > Best regards, > Badra > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext badra@isima.fr > Sent: Saturday, October 18, 2008 12:34 AM > To: netconf@ietf.org > Subject: [Netconf] New version of draft-ietf-netconf-tls > > Dear all, > > After the WGLC, I posted a revised version of draft-ietf-netconf-tls, > which addresses comments and issues raised during the WGLC. Below is a > summary of changes, please don't hesitate to read the > document and send > your comments on any missed point. > > Changes from -04 > > Removed any text related to PSK based authentication. > > Revised to TLS with certificate-based mutual authentication. > > Removed Cipher Suite Requirements section which was > redundant with TLS. > > Added small clarifications to the "Introduction" and "Endpoint > Authentication and Identification" sections. > > Section 2.1: Included mandatory to implement cipher suites > that track > future versions of the TLS > > Section 2.2: Revised the connection closure session with regards to > TLS 1.2 > > Section 5: Revised to help IANA with the port assignment. > > Section 8: Removed RFC4086 and RFC4279 from the reference section > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-05.txt > > Best regards, > Badra > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Oct 23 15:26:44 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 368723A68F7; Thu, 23 Oct 2008 15:26:44 -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 1050C3A6826 for ; Thu, 23 Oct 2008 15:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 xJ9i+Y-9KHx0 for ; Thu, 23 Oct 2008 15:26:42 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id D5A073A67AF for ; Thu, 23 Oct 2008 15:26:41 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m9NMP4e21956; Thu, 23 Oct 2008 22:25:04 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 23 Oct 2008 18:27:55 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC56D786@zcarhxm0.corp.nortel.com> In-Reply-To: <20081022180245.GA26907@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72 Thread-Index: Ack0cGuJrz7RvDWyS7Wp31eJbS9ajgA4d8hA References: <238C6E77EA42504DA038BAEE6D1C11EC4BA87B@zcarhxm0.corp.nortel.com> <20081022140650.GA26069@elstar.local> <48FF56F2.3060908@netconfcentral.com> <20081022180245.GA26907@elstar.local> From: "Mark Scott" To: , "Andy Bierman" Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72 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, Thank you for the comments. Per earlier response from Bert I'm going to kick-off further discussion on this amongst the stakeholders identified at IETF72. We'll post a proposal back to the mailing list. To answer the specific questions from your earlier email: 1. [Juergen] Do you have a list of work in progress documents where similar XSD definitions are provided? - The only IETF reference I could find was draft-ietf-opsawg-smi-datatypes-in-xsd-03 (SMI specific). - I also looked at some proprietary data type defs (including within my own company) but these are not standards. 2. [Juergen] a) What is going to be the final scope of this? Are these definitions going to be NETCONF monitoring specific only or are there expectations that these definitions are used in the wider context of the IETF? (The suggested namespace might imply a much wider context.) [Mark]: My preference would be wider scope but if we can agree specifically for NETCONF that would suffice for NETCONF monitoring. We From netconf-bounces@ietf.org Thu Oct 23 15:26:44 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 368723A68F7; Thu, 23 Oct 2008 15:26:44 -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 1050C3A6826 for ; Thu, 23 Oct 2008 15:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 xJ9i+Y-9KHx0 for ; Thu, 23 Oct 2008 15:26:42 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id D5A073A67AF for ; Thu, 23 Oct 2008 15:26:41 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m9NMP4e21956; Thu, 23 Oct 2008 22:25:04 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 23 Oct 2008 18:27:55 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC56D786@zcarhxm0.corp.nortel.com> In-Reply-To: <20081022180245.GA26907@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72 Thread-Index: Ack0cGuJrz7RvDWyS7Wp31eJbS9ajgA4d8hA References: <238C6E77EA42504DA038BAEE6D1C11EC4BA87B@zcarhxm0.corp.nortel.com> <20081022140650.GA26069@elstar.local> <48FF56F2.3060908@netconfcentral.com> <20081022180245.GA26907@elstar.local> From: "Mark Scott" To: , "Andy Bierman" Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72 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, Thank you for the comments. Per earlier response from Bert I'm going to kick-off further discussion on this amongst the stakeholders identified at IETF72. We'll post a proposal back to the mailing list. To answer the specific questions from your earlier email: 1. [Juergen] Do you have a list of work in progress documents where similar XSD definitions are provided? - The only IETF reference I could find was draft-ietf-opsawg-smi-datatypes-in-xsd-03 (SMI specific). - I also looked at some proprietary data type defs (including within my own company) but these are not standards. 2. [Juergen] a) What is going to be the final scope of this? Are these definitions going to be NETCONF monitoring specific only or are there expectations that these definitions are used in the wider context of the IETF? (The suggested namespace might imply a much wider context.) [Mark]: My preference would be wider scope but if we can agree specifically for NETCONF that would suffice for NETCONF monitoring. We can adcan adjust the namespace accordingly. 3. [Juergen] b) I see differences in the patterns compared to what we have in draft-ietf-netmod-yang-types-00.txt (and the corresponding XSD in the appendix). Perhaps this should be synchronized. [Mark]: Agreed. Let's align these. 4. [Juergen] c) In the context of the YANG work, we recently discussed the issue of types allowing multiple representations for a single value from the value space. This leads to the question of normalization. For example, IPv6 addresses can be represented in different ways, e.g., ::1 and 0:0:0:0:0:0:0:1 denote the same value. If we assume that a NETCONF implementation only maintains the value and not its representation, is there a normalized representation you can expect to be returned by the NETCONF server? Since you are dealing with IPv6 addresses, you might have to deal with the same issue (and not surprisingly, I like the NETCONF monitoring document to be consistent with the YANG types document about this issue). [Mark]: I also assume a NETCONF implementation only maintains the value. To date (to avoid this issue) we have used normalized representations for machine-to-machine exchange. Our presentation layers (clients) handle multiple representations as needed. For monitoring I don't think multiple server patterns will be an issue. I believe YANG has agreed to AND the patterns with multiple typedefs. This also works in XSD (nested types with restrictions). So as long as we do align the definitions we should be fine even in cases where client and server are using different formats for the monitoring schema. cheers, Mark -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Wednesday, October 22, 2008 2:03 PM To: Andy Bierman Cc: Bert Wijnen (IETF); Scott, Mark (CAR:2Y01); netconf@ietf.org Subject: Re: [Netconf] [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72 On Wed, Oct 22, 2008 at 09:38:10AM -0700, Andy Bierman wrote: > Creating multiple data model representations of an address is not > acceptable. I raised this issue 3 or 4 IETFs ago, and the 'quick-fix' > solution is still not available. > > The most basic data structure in the entire IETF is the InetAddress. > If we can't settle on a typedef for an InetAddress after all this > time, that is pretty sad. A single XSD definition of an IP address is not going to happen anymore and probably this is not really a drama. I think EPP has an XSD definition in RFCs and I would not be surprised to find more if I start searching more systematically. > Listen to Juergen. He is right, and we should use inet-types.yang > typedefs and patterns. This issue has already been studied, examined, > and delayed long enough. Since it is too late (and too difficult) to have consistent IETF wide definitions, having consistent definitions for NETCONF content or even within IETF management content might be a more realistic goal. /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 just the namespace accordingly. 3. [Juergen] b) I see differences in the patterns compared to what we have in draft-ietf-netmod-yang-types-00.txt (and the corresponding XSD in the appendix). Perhaps this should be synchronized. [Mark]: Agreed. Let's align these. 4. [Juergen] c) In the context of the YANG work, we recently discussed the issue of types allowing multiple representations for a single value from the value space. This leads to the question of normalization. For example, IPv6 addresses can be represented in different ways, e.g., ::1 and 0:0:0:0:0:0:0:1 denote the same value. If we assume that a NETCONF implementation only maintains the value and not its representation, is there a normalized representation you can expect to be returned by the NETCONF server? Since you are dealing with IPv6 addresses, you might have to deal with the same issue (and not surprisingly, I like the NETCONF monitoring document to be consistent with the YANG types document about this issue). [Mark]: I also assume a NETCONF implementation only maintains the value. To date (to avoid this issue) we have used normalized representations for machine-to-machine exchange. Our presentation layers (clients) handle multiple representations as needed. For monitoring I don't think multiple server patterns will be an issue. I believe YANG has agreed to AND the patterns with multiple typedefs. This also works in XSD (nested types with restrictions). So as long as we do align the definitions we should be fine even in cases where client and server are using different formats for the monitoring schema. cheers, Mark -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Wednesday, October 22, 2008 2:03 PM To: Andy Bierman Cc: Bert Wijnen (IETF); Scott, Mark (CAR:2Y01); netconf@ietf.org Subject: Re: [Netconf] [NETCONF] monitoring data type definitions; proposed resolution to open item from IETF72 On Wed, Oct 22, 2008 at 09:38:10AM -0700, Andy Bierman wrote: > Creating multiple data model representations of an address is not > acceptable. I raised this issue 3 or 4 IETFs ago, and the 'quick-fix' > solution is still not available. > > The most basic data structure in the entire IETF is the InetAddress. > If we can't settle on a typedef for an InetAddress after all this > time, that is pretty sad. A single XSD definition of an IP address is not going to happen anymore and probably this is not really a drama. I think EPP has an XSD definition in RFCs and I would not be surprised to find more if I start searching more systematically. > Listen to Juergen. He is right, and we should use inet-types.yang > typedefs and patterns. This issue has already been studied, examined, > and delayed long enough. Since it is too late (and too difficult) to have consistent IETF wide definitions, having consistent definitions for NETCONF content or even within IETF management content might be a more realistic goal. /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 Fri Oct 24 08:33: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 91DFE3A6BCA; Fri, 24 Oct 2008 08:33: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 2346E3A6A5D for ; Fri, 24 Oct 2008 08:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 MCtfk21qhd-6 for ; Fri, 24 Oct 2008 08:33:47 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 5BB2D3A6BAC for ; Fri, 24 Oct 2008 08:33:47 -0700 (PDT) Received: (qmail 65112 invoked from network); 24 Oct 2008 15:35:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 24 Oct 2008 15:35:06 -0000 X-YMail-OSG: leu406kVM1l4PmIGSqmDLQ.8Od5ALNCL3.IJLquvTQxJLnjVkhh2nUspHDWIWS46rTroFqRQBMZddMYTgbcbgnYwthT0INEKlB86qbVV77cfSALhpyUlCf7VgVFD7_DNZP0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4901EB28.8010006@netconfcentral.com> Date: Fri, 24 Oct 2008 08:35:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Johan Rydberg References: <200808202134.m7KLYLOZ003375@idle.juniper.net><48AF3DD0.7010800@netconfcentral.com> <046b01c90904$89d003c0$0601a8c0@allison> <48BFE77C.4050004@netconfcentral.com> <4901B96B.2080200@edgeware.tv> In-Reply-To: <4901B96B.2080200@edgeware.tv> Cc: NETCONF Subject: Re: [Netconf] continue-on-error 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 Johan Rydberg wrote: > >> The original intent was to support the 'load startup config' >> operation found in CLI. Config file commands that cause errors >> don't automatically crash a router. This is not always the >> case in other applications, such as Apache -- if httpd.conf >> has unknown or invalid commands the WEB server will not start. > > I'm trying to implement c-o-e for general use throughout our > agent. Currently we're modeling the "load config" operation > as an editing operation on the current configuration, with > the new configuration as source. In other words, we do inline > editing to the existing configuration tree while we're applying > the new configuration. The reason behind this is that you can > in case of error do a simple rollback by re-applying the old > configuration to the somewhat edited tree. > > The problem is what to do when you want to continue on an error. > > Is it OK to leave the edited configuration in state where it > does not validate? Must the running configuration always > be valid according to the schema? > yes -- it makes implementation much harder if you leave known-to-be-bad subtrees in the config. > As example, say that the agent fails to remove an leaf from > a list entry, when it tries to remove the list entry. Should > the list entry be left in place with the failing leaf, possible > without key leafs. Or should the list entry be removed in > either case? > Good question. Short answer: it depends on the data model. If you are trying to automate the operations in the central stack, then it is difficult to use a generalized algorithm. Even if you let the error ripple up to the root (top-level ancestor in the same namespace), you can still leave the config invalid due to 'must' restrictions that reference the sub-tree you just deleted. > ~jr Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Oct 24 08:33: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 91DFE3A6BCA; Fri, 24 Oct 2008 08:33: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 2346E3A6A5D for ; Fri, 24 Oct 2008 08:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 MCtfk21qhd-6 for ; Fri, 24 Oct 2008 08:33:47 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 5BB2D3A6BAC for ; Fri, 24 Oct 2008 08:33:47 -0700 (PDT) Received: (qmail 65112 invoked from network); 24 Oct 2008 15:35:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 24 Oct 2008 15:35:06 -0000 X-YMail-OSG: leu406kVM1l4PmIGSqmDLQ.8Od5ALNCL3.IJLquvTQxJLnjVkhh2nUspHDWIWS46rTroFqRQBMZddMYTgbcbgnYwthT0INEKlB86qbVV77cfSALhpyUlCf7VgVFD7_DNZP0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4901EB28.8010006@netconfcentral.com> Date: Fri, 24 Oct 2008 08:35:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Johan Rydberg References: <200808202134.m7KLYLOZ003375@idle.juniper.net><48AF3DD0.7010800@netconfcentral.com> <046b01c90904$89d003c0$0601a8c0@allison> <48BFE77C.4050004@netconfcentral.com> <4901B96B.2080200@edgeware.tv> In-Reply-To: <4901B96B.2080200@edgeware.tv> Cc: NETCONF Subject: Re: [Netconf] continue-on-error 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 Johan Rydberg wrote: > >> The original intent was to support the 'load startup config' >> operation found in CLI. Config file commands that cause errors >> don't automatically crash a router. This is not always the >> case in other applications, such as Apache -- if httpd.conf >> has unknown or invalid commands the WEB server will not start. > > I'm trying to implement c-o-e for general use throughout our > agent. Currently we're modeling the "load config" operation > as an editing operation on the current configuration, with > the new configuration as source. In other words, we do inline > editing to the existing configuration tree while we're applying > the new configuration. The reason behind this is that you can > in case of error do a simple rollback by re-applying the old > configuration to the somewhat edited tree. > > The problem is what to do when you want to continue on an error. > > Is it OK to leave the edited configuration in state where it > does not validate? Must the running configuration always > be valid according to the schema? > yes -- it makes implementation much harder if you leave known-to-be-bad subtrees in the config. > As example, say that the agent fails to remove an leaf from > a list entry, when it tries to remove the list entry. Should > the list entry be left in place with the failing leaf, possible > without key leafs. Or should the list entry be removed in > either case? > Good question. Short answer: it depends on the data model. If you are trying to automate the operations in the central stack, then it is difficult to use a generalized algorithm. Even if you let the error ripple up to the root (top-level ancestor in the same namespace), you can still leave the config invalid due to 'must' restrictions that reference the sub-tree you just deleted. > ~jr Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Oct 27 13:50: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 E63FF3A6B90; Mon, 27 Oct 2008 13:50: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 1F4143A6B90 for ; Mon, 27 Oct 2008 13:50: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 Z+ZOzAhbMLzX for ; Mon, 27 Oct 2008 13:50: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 F1D633A6849 for ; Mon, 27 Oct 2008 13:50:07 -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 m9RKo4rm004542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Oct 2008 21:50:04 +0100 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 m9RKo29w007161; Mon, 27 Oct 2008 21:50:03 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 21:49:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Oct 2008 21:49:37 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Agenda for IETF #73 NETCONF Session Thread-Index: Ack3rUNhNkRAkFZaS4KuINXIjughagAx7caw From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 27 Oct 2008 20:49:44.0888 (UTC) FILETIME=[8ADDA380:01C93875] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081027215004-115F3BB0-48E5242F/0-0/0-15 X-purgate-size: 1808/0 Subject: [Netconf] Draft Agenda for IETF #73 NETCONF Session 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 NETCONF WG, > below is the draft agenda for the NETCONF WG session at the IETF #73. Our session will be on Monday after the afternoon beverage and snack break II at 1740-1930. > Please send us your comments and requests concerning the agenda. Our main focus in the session will be as usual on open issue discussion but we have a few additional topics this time. > We need to summarize the 4741bis relevant issues as starter for discussion. Please let us know if there is anybody who wants to jump in for this. > BTW: We need to organize the scribes and minute takers > before the meeting. Please help us to start the session > timely and send us a note if you volunteer. > Bert & Mehmet > ________________________________________From netconf-bounces@ietf.org Mon Oct 27 13:50: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 E63FF3A6B90; Mon, 27 Oct 2008 13:50: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 1F4143A6B90 for ; Mon, 27 Oct 2008 13:50: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 Z+ZOzAhbMLzX for ; Mon, 27 Oct 2008 13:50: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 F1D633A6849 for ; Mon, 27 Oct 2008 13:50:07 -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 m9RKo4rm004542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Oct 2008 21:50:04 +0100 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 m9RKo29w007161; Mon, 27 Oct 2008 21:50:03 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 21:49:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Oct 2008 21:49:37 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Agenda for IETF #73 NETCONF Session Thread-Index: Ack3rUNhNkRAkFZaS4KuINXIjughagAx7caw From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 27 Oct 2008 20:49:44.0888 (UTC) FILETIME=[8ADDA380:01C93875] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081027215004-115F3BB0-48E5242F/0-0/0-15 X-purgate-size: 1808/0 Subject: [Netconf] Draft Agenda for IETF #73 NETCONF Session 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 NETCONF WG, > below is the draft agenda for the NETCONF WG session at the IETF #73. Our session will be on Monday after the afternoon beverage and snack break II at 1740-1930. > Please send us your comments and requests concerning the agenda. Our main focus in the session will be as usual on open issue discussion but we have a few additional topics this time. > We need to summarize the 4741bis relevant issues as starter for discussion. Please let us know if there is anybody who wants to jump in for this. > BTW: We need to organize the scribes and minute takers > before the meeting. Please help us to start the session > timely and send us a note if you volunteer. > Bert & Mehmet > _____________________________________________ _____ > NETCONF WG > IETF 73, Minneapolis, MN, USA > > MONDAY, November 17, 2008, 1740-1950 > > WG Chairs: > Bert Wijnen > Mehmet Ersue > > Scribes (IF no_volunteers THEN wait_forever) > Agenda bashing (2 minutes) > WG status review (5 minutes) > > Charter items: > > 1. NETCONF Monitoring Schema - Mark Scott (20 minutes) > draft-ietf-netconf-monitoring > 2. Partial Lock RPC for NETCONF - Balazs Lengyel (10 minutes) > draft-ietf-netconf-partial-lock > 3. NETCONF over TLS - Mohamad Badra (5 minutes) > draft-ietf-netconf-monitoring > > Not-chartered document(s): > > 1. New charter text for Notification Content - Bert Wijnen (15 > minutes) > > 2. Issues for 4741bis-draft - ?? (30 minutes) > > Open mike (15 minutes) > Any other topics to discuss? > > AOB (5 minutes) > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf > NETCONF WG > IETF 73, Minneapolis, MN, USA > > MONDAY, November 17, 2008, 1740-1950 > > WG Chairs: > Bert Wijnen > Mehmet Ersue > > Scribes (IF no_volunteers THEN wait_forever) > Agenda bashing (2 minutes) > WG status review (5 minutes) > > Charter items: > > 1. NETCONF Monitoring Schema - Mark Scott (20 minutes) > draft-ietf-netconf-monitoring > 2. Partial Lock RPC for NETCONF - Balazs Lengyel (10 minutes) > draft-ietf-netconf-partial-lock > 3. NETCONF over TLS - Mohamad Badra (5 minutes) > draft-ietf-netconf-monitoring > > Not-chartered document(s): > > 1. New charter text for Notification Content - Bert Wijnen (15 > minutes) > > 2. Issues for 4741bis-draft - ?? (30 minutes) > > Open mike (15 minutes) > Any other topics to discuss? > > AOB (5 minutes) > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Oct 28 03:11: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 9E9BA3A682A; Tue, 28 Oct 2008 03:11: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 E6D963A67AF for ; Tue, 28 Oct 2008 03:11:58 -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 xgTtOsenPfK6 for ; Tue, 28 Oct 2008 03:11:58 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id EE8FD3A682A for ; Tue, 28 Oct 2008 03:11:57 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 25F6C21200; Tue, 28 Oct 2008 11:11:19 +0100 (CET) X-AuditID: c1b4fb3c-ae0cebb0000015b5-80-4906e547ab42 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 032392089F; Tue, 28 Oct 2008 11:11:19 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 11:10:09 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 11:10:09 +0100 Message-ID: <4906E500.2020105@ericsson.com> Date: Tue, 28 Oct 2008 11:10:08 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" , Bert Wijnen - IETF References: In-Reply-To: X-OriginalArrivalTime: 28 Oct 2008 10:10:09.0561 (UTC) FILETIME=[5BCD3090:01C938E5] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #73 NETCONF Session 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 Hello Mehmet, Bert, I would like to have our with-defaults draft on the agenda as a proposed new work item for the WG. http://tools.ietf.org/html/draft-bierman-netconf-with-defaults-01 Balazs Ersue, Mehmet (NSN - DE/Munich) wrote: >> Dear NETCONF WG, >> below is the draft agenda for the NETCONF WG session > at the IETF #73. Our session will be on Monday after > the afternoon beverage and snack break II at 1740-1930. >> Please send us your comments and requests concerning > the agenda. Our main focus in the session will be as usual > on open issue discussion but we have a few additional > topics this time. >> We need to summarize the 4741bis relevant issues as > starter for discussion. Please let us know if there is > anybody who wants to jump in for this. >> BTW: WeFrom netconf-bounces@ietf.org Tue Oct 28 03:11: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 9E9BA3A682A; Tue, 28 Oct 2008 03:11: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 E6D963A67AF for ; Tue, 28 Oct 2008 03:11:58 -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 xgTtOsenPfK6 for ; Tue, 28 Oct 2008 03:11:58 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id EE8FD3A682A for ; Tue, 28 Oct 2008 03:11:57 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 25F6C21200; Tue, 28 Oct 2008 11:11:19 +0100 (CET) X-AuditID: c1b4fb3c-ae0cebb0000015b5-80-4906e547ab42 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 032392089F; Tue, 28 Oct 2008 11:11:19 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 11:10:09 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 11:10:09 +0100 Message-ID: <4906E500.2020105@ericsson.com> Date: Tue, 28 Oct 2008 11:10:08 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" , Bert Wijnen - IETF References: In-Reply-To: X-OriginalArrivalTime: 28 Oct 2008 10:10:09.0561 (UTC) FILETIME=[5BCD3090:01C938E5] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #73 NETCONF Session 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 Hello Mehmet, Bert, I would like to have our with-defaults draft on the agenda as a proposed new work item for the WG. http://tools.ietf.org/html/draft-bierman-netconf-with-defaults-01 Balazs Ersue, Mehmet (NSN - DE/Munich) wrote: >> Dear NETCONF WG, >> below is the draft agenda for the NETCONF WG session > at the IETF #73. Our session will be on Monday after > the afternoon beverage and snack break II at 1740-1930. >> Please send us your comments and requests concerning > the agenda. Our main focus in the session will be as usual > on open issue discussion but we have a few additional > topics this time. >> We need to summarize the 4741bis relevant issues as > starter for discussion. Please let us know if there is > anybody who wants to jump in for this. >> B need to organize the scribes and minute takers >> before the meeting. Please help us to start the session >> timely and send us a note if you volunteer. >> Bert & Mehmet >> _____________________________________________ >> NETCONF WG >> IETF 73, Minneapolis, MN, USA >> >> MONDAY, November 17, 2008, 1740-1950 >> >> WG Chairs: >> Bert Wijnen >> Mehmet Ersue >> >> Scribes (IF no_volunteers THEN wait_forever) >> Agenda bashing (2 minutes) >> WG status review (5 minutes) >> >> Charter items: >> >> 1. NETCONF Monitoring Schema - Mark Scott (20 minutes) >> draft-ietf-netconf-monitoring >> 2. Partial Lock RPC for NETCONF - Balazs Lengyel (10 minutes) >> draft-ietf-netconf-partial-lock >> 3. NETCONF over TLS - Mohamad Badra (5 minutes) >> draft-ietf-netconf-monitoring >> >> Not-chartered document(s): >> >> 1. New charter text for Notification Content - Bert Wijnen (15 >> minutes) >> >> 2. Issues for 4741bis-draft - ?? (30 minutes) >> >> Open mike (15 minutes) >> Any other topics to discuss? >> >> AOB (5 minutes) >> > _______________________________________________ > 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 TW: We need to organize the scribes and minute takers >> before the meeting. Please help us to start the session >> timely and send us a note if you volunteer. >> Bert & Mehmet >> _____________________________________________ >> NETCONF WG >> IETF 73, Minneapolis, MN, USA >> >> MONDAY, November 17, 2008, 1740-1950 >> >> WG Chairs: >> Bert Wijnen >> Mehmet Ersue >> >> Scribes (IF no_volunteers THEN wait_forever) >> Agenda bashing (2 minutes) >> WG status review (5 minutes) >> >> Charter items: >> >> 1. NETCONF Monitoring Schema - Mark Scott (20 minutes) >> draft-ietf-netconf-monitoring >> 2. Partial Lock RPC for NETCONF - Balazs Lengyel (10 minutes) >> draft-ietf-netconf-partial-lock >> 3. NETCONF over TLS - Mohamad Badra (5 minutes) >> draft-ietf-netconf-monitoring >> >> Not-chartered document(s): >> >> 1. New charter text for Notification Content - Bert Wijnen (15 >> minutes) >> >> 2. Issues for 4741bis-draft - ?? (30 minutes) >> >> Open mike (15 minutes) >> Any other topics to discuss? >> >> AOB (5 minutes) >> > _______________________________________________ > 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 Tue Oct 28 04:03: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 EB24028C0E2; Tue, 28 Oct 2008 04:03: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 D7F883A6990 for ; Tue, 28 Oct 2008 04:03:45 -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 tgNQgZWdr8F4 for ; Tue, 28 Oct 2008 04:03:45 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D22B53A6986 for ; Tue, 28 Oct 2008 04:03:44 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E935B2066C; Tue, 28 Oct 2008 12:03:42 +0100 (CET) X-AuditID: c1b4fb3e-aaf7ebb00000537b-69-4906f18ef0f2 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D73D620485; Tue, 28 Oct 2008 12:03:42 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 12:02:28 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 12:02:27 +0100 Message-ID: <4906F143.60902@ericsson.com> Date: Tue, 28 Oct 2008 12:02:27 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Johan Rydberg References: <4906E500.2020105@ericsson.com> <4906EF4E.3060305@edgeware.tv> In-Reply-To: <4906EF4E.3060305@edgeware.tv> X-OriginalArrivalTime: 28 Oct 2008 11:02:27.0767 (UTC) FILETIME=[AA516C70:01C938EC] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #73 NETCONF Session 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 Hello Johan, Because the NETCONF XSD allows any attribute on the RPC, but not on the operation. On the other hand I would agree with you that it would be more logical on the get/get-congig/copy-config operation. Anyway once we get the draft into the workgroup we can debate and change this if needed. Balazs Johan Rydberg wrote: > Balazs Lengyel skrev: >> Hello Mehmet, Bert, >> I would like to have our with-defaults draft on the agenda as a >> proposed new work item for the WG. >> >> http://tools.ietf.org/html/draft-bierman-netconf-with-defaults-01 > > May I ask why the attribute is on the element and not on the > operation element (get, copy-config, ..) ? It seems that it is an > attribute to the protocol and not to the transport/rpc layer. > -- 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 Tue Oct 28 04:03: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 EB24028C0E2; Tue, 28 Oct 2008 04:03: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 D7F883A6990 for ; Tue, 28 Oct 2008 04:03:45 -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 tgNQgZWdr8F4 for ; Tue, 28 Oct 2008 04:03:45 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D22B53A6986 for ; Tue, 28 Oct 2008 04:03:44 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E935B2066C; Tue, 28 Oct 2008 12:03:42 +0100 (CET) X-AuditID: c1b4fb3e-aaf7ebb00000537b-69-4906f18ef0f2 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D73D620485; Tue, 28 Oct 2008 12:03:42 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 12:02:28 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 12:02:27 +0100 Message-ID: <4906F143.60902@ericsson.com> Date: Tue, 28 Oct 2008 12:02:27 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Johan Rydberg References: <4906E500.2020105@ericsson.com> <4906EF4E.3060305@edgeware.tv> In-Reply-To: <4906EF4E.3060305@edgeware.tv> X-OriginalArrivalTime: 28 Oct 2008 11:02:27.0767 (UTC) FILETIME=[AA516C70:01C938EC] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #73 NETCONF Session 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 Hello Johan, Because the NETCONF XSD allows any attribute on the RPC, but not on the operation. On the other hand I would agree with you that it would be more logical on the get/get-congig/copy-config operation. Anyway once we get the draft into the workgroup we can debate and change this if needed. Balazs Johan Rydberg wrote: > Balazs Lengyel skrev: >> Hello Mehmet, Bert, >> I would like to have our with-defaults draft on the agenda as a >> proposed new work item for the WG. >> >> http://tools.ietf.org/html/draft-bierman-netconf-with-defaults-01 > > May I ask why the attribute is on the element and not on the > operation element (get, copy-config, ..) ? It seems that it is an > attribute to the protocol and not to the transport/rpc layer. > -- 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 Tue Oct 28 05:29:53 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 72DD23A6C1A; Tue, 28 Oct 2008 05:29: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 D770D3A6C2E for ; Tue, 28 Oct 2008 05:29:52 -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 nrloBzDtbHGs for ; Tue, 28 Oct 2008 05:29:48 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 9662E3A693F for ; Tue, 28 Oct 2008 05:29:48 -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 m9SCTdsr005739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Oct 2008 13:29:39 +0100 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 m9SCTZn8013762; Tue, 28 Oct 2008 13:29:39 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Oct 2008 13:29:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 28 Oct 2008 13:29:13 +0100 Message-ID: In-Reply-To: <4906E500.2020105@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Draft Agenda for IETF #73 NETCONF Session Thread-Index: Ack45Zvik1vc+l2nQo+fEkFeJp3mAQAENe4g References: <4906E500.2020105@ericsson.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Balazs Lengyel" X-OriginalArrivalTime: 28 Oct 2008 12:29:17.0051 (UTC) FILETIME=[CB4B14B0:01C938F8] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081028132939-115F2BB0-2FD8EDDA/0-0/0-15 X-purgate-size: 3116/0 Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #73 NETCONF Session 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, we need for sure a discussion on this. How much time do you need for discussion? Does this going to become a part of 4741bis or do you see it rather as a standalone RFC? Cheers, Mehmet > -----Original Message----- > From: ext Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > Sent: Tuesday, October 28, 2008 11:10 AM > To: Ersue, Mehmet (NSN - DE/Munich); Bert Wijnen - IETF > Cc: netconf@ietf.org > Subject: Re: [Netconf] Draft Agenda for IETF #73 NETCONF Session > > Hello Mehmet, Bert, > I would like to have our with-defaults draft on the agenda as > a proposed new work item for the WG. > > http://tools.ietf.org/html/draft-bierman-netconf-with-defaults-01 > > Balazs > > Ersue, Mehmet (NSN - DE/Munich) wrote: > >> Dear NETCONF WG, > >> below is the draft agenda for the NETCONF WG session > > at the IETF #73. Our session will be on Monday after > > the afternoon beverage and snack break II at 1740-1930. > >> Please send us your comments and requests concerning > > the agenda. Our main focus in the session will be as usual > > on open issue discussion but we have a few additional > > topics this time. > >> We need to summarize the 4741bis relevant issues as > > starter for discussion. Please let us know if there is > > anybody who wants to jump in for this. > >> BTW: We need to organize the scribes and minute takers > >> before the meeting. Please help us to start the session > >> timely and send us a note if you volunteer. > >> Bert & Mehmet > >> _____________________________________________ > >> NETCONF WG > >> IETF 73, Minneapolis, MN, USA > >> > >> MONDAY, November 17, 2008, 1740-1950 > >> > >> WG Chairs: > >> Bert Wijnen > >> Mehmet Ersue > >> > >> Scribes (IF no_volunteers THEN wait_forever) > >> Agenda bashing (2 minutes) > >> WG status review (5 minutes) > >> > >> Charter items: > >> > >> 1. NETCONF Monitoring Schema - Mark Scott (20 minutes) > >> draft-ietf-netconf-monitoring > >> 2. Partial Lock RPC for NETCONF - Balazs Lengyel (10 > minutes) > >> draft-ietf-netconf-partial-lock > >> 3. NETCONF over TLS - Mohamad Badra (5 minutes) > >> draft-ietf-netconf-monitoring > >> > >> Not-chartered document(s): > >> > >> 1. New charter text for Notification Content - Bert > Wijnen (15 > >> minutes) > >> > >> 2. Issues for 4741bis-draft - ?? (30 minutes) > >> > >> Open mike (15 minutes) > >> Any other topics to discuss? > >> > >> AOB (5 minutes) > >> > > _______________________________________________ > > 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 Tue Oct 28 05:29:53 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 72DD23A6C1A; Tue, 28 Oct 2008 05:29: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 D770D3A6C2E for ; Tue, 28 Oct 2008 05:29:52 -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 nrloBzDtbHGs for ; Tue, 28 Oct 2008 05:29:48 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 9662E3A693F for ; Tue, 28 Oct 2008 05:29:48 -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 m9SCTdsr005739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Oct 2008 13:29:39 +0100 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 m9SCTZn8013762; Tue, 28 Oct 2008 13:29:39 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Oct 2008 13:29:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 28 Oct 2008 13:29:13 +0100 Message-ID: In-Reply-To: <4906E500.2020105@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Draft Agenda for IETF #73 NETCONF Session Thread-Index: Ack45Zvik1vc+l2nQo+fEkFeJp3mAQAENe4g References: <4906E500.2020105@ericsson.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Balazs Lengyel" X-OriginalArrivalTime: 28 Oct 2008 12:29:17.0051 (UTC) FILETIME=[CB4B14B0:01C938F8] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081028132939-115F2BB0-2FD8EDDA/0-0/0-15 X-purgate-size: 3116/0 Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #73 NETCONF Session 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, we need for sure a discussion on this. How much time do you need for discussion? Does this going to become a part of 4741bis or do you see it rather as a standalone RFC? Cheers, Mehmet > -----Original Message----- > From: ext Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > Sent: Tuesday, October 28, 2008 11:10 AM > To: Ersue, Mehmet (NSN - DE/Munich); Bert Wijnen - IETF > Cc: netconf@ietf.org > Subject: Re: [Netconf] Draft Agenda for IETF #73 NETCONF Session > > Hello Mehmet, Bert, > I would like to have our with-defaults draft on the agenda as > a proposed new work item for the WG. > > http://tools.ietf.org/html/draft-bierman-netconf-with-defaults-01 > > Balazs > > Ersue, Mehmet (NSN - DE/Munich) wrote: > >> Dear NETCONF WG, > >> below is the draft agenda for the NETCONF WG session > > at the IETF #73. Our session will be on Monday after > > the afternoon beverage and snack break II at 1740-1930. > >> Please send us your comments and requests concerning > > the agenda. Our main focus in the session will be as usual > > on open issue discussion but we have a few additional > > topics this time. > >> We need to summarize the 4741bis relevant issues as > > starter for discussion. Please let us know if there is > > anybody who wants to jump in for this. > >> BTW: We need to organize the scribes and minute takers > >> before the meeting. Please help us to start the session > >> timely and send us a note if you volunteer. > >> Bert & Mehmet > >> _____________________________________________ > >> NETCONF WG > >> IETF 73, Minneapolis, MN, USA > >> > >> MONDAY, November 17, 2008, 1740-1950 > >> > >> WG Chairs: > >> Bert Wijnen > >> Mehmet Ersue > >> > >> Scribes (IF no_volunteers THEN wait_forever) > >> Agenda bashing (2 minutes) > >> WG status review (5 minutes) > >> > >> Charter items: > >> > >> 1. NETCONF Monitoring Schema - Mark Scott (20 minutes) > >> draft-ietf-netconf-monitoring > >> 2. Partial Lock RPC for NETCONF - Balazs Lengyel (10 > minutes) > >> draft-ietf-netconf-partial-lock > >> 3. NETCONF over TLS - Mohamad Badra (5 minutes) > >> draft-ietf-netconf-monitoring > >> > >> Not-chartered document(s): > >> > >> 1. New charter text for Notification Content - Bert > Wijnen (15 > >> minutes) > >> > >> 2. Issues for 4741bis-draft - ?? (30 minutes) > >> > >> Open mike (15 minutes) > >> Any other topics to discuss? > >> > >> AOB (5 minutes) > >> > > _______________________________________________ > > 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 Tue Oct 28 06:28: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 19C0328C27D; Tue, 28 Oct 2008 06:28: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 1379C28C280 for ; Tue, 28 Oct 2008 06:28: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 X+hXPNtWzeBr for ; Tue, 28 Oct 2008 06:28:46 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C604528C27D for ; Tue, 28 Oct 2008 06:28:45 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EDCD220123; Tue, 28 Oct 2008 14:28:43 +0100 (CET) X-AuditID: c1b4fb3e-abf80bb00000537b-77-4907138b12a0 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C65CE21149; Tue, 28 Oct 2008 14:28:43 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 14:27:56 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 14:27:55 +0100 Message-ID: <4907135A.2080705@ericsson.com> Date: Tue, 28 Oct 2008 14:27:54 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <4906E500.2020105@ericsson.com> In-Reply-To: X-OriginalArrivalTime: 28 Oct 2008 13:27:55.0589 (UTC) FILETIME=[FC815F50:01C93900] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #73 NETCONF Session 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 Hello Mehmet, I would rather see it as a standalone that can later be folded into a 4741bis. Putting it into the bis right now might delay it for too long. I think this is urgent stuff. I think 20 minutes would be good: My presentation would be something like: - What is the problem? - 3 ways of handling defaults - Why is this needed for interoperability? Because it effects ... - Solution basics - Open issues need to force suppressing defaults need to force presenting defaults need to advertise default handling encoding issues Balazs Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Balazs, > > we need for sure a discussion on this. How much time > do you need for discussion? > > Does this going to become a part of 4741bis or do you > see it rather as a standalone RFC? > > Cheers, > Mehmet > > >> -----Original Message----- >> From: ext Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] >> Sent: Tuesday, October 28, 2008 11:10 AM >> To: Ersue, Mehmet (NSN - DE/Munich); Bert Wijnen - IETF >> Cc: netconf@ietf.org >> Subject: Re: [Netconf] Draft Agenda for IETF #73 NETCONF Session >> >> Hello Mehmet, Bert, >> I would like to have our with-defaults draft on the agenda as >> a proposed new work item for the WG. >> >> http://tools.ietf.org/html/draft-bierman-netconf-with-defaults-01 >> >> Balazs >> >> Ersue, Mehmet (NSN - DE/Munich) wrote: >>>> Dear NETCONF WG, >>>> below is the draft agenda for the NETCONF WG session >>> at the IETF #73. Our session will be on Monday after >>> the afternoon beverage and snack break II at 1740-1930. >>>> Please send us your comments and requests concerning >>> the agenda. Our main focus in the session will be as usual >>> on open issue discussion but we have a few additional >>> topics this time. >>>> We need to summarize the 4741bis relevant issues as >>> starter for discussion. Please let us know if there is >>> anybody who wants to jump in for this. >>>> BTW: We need to organize the scribes and minute takers >>>> before the meeting. Please help us to start the session >>>> timely and send us a note if you volunteer. >>>> Bert & Mehmet >>>> _____________________________________________ >>>> NETCONF WG >>>> IETF 73, Minneapolis, MN, USA >>>> >>>> MONDAY, November 17, 2008, 1740-1950 >>>> >>>> WG Chairs: >>>> Bert Wijnen >>>> Mehmet Ersue >>>> >>>> Scribes (IF no_volunteers THEN wait_forever) >>>> Agenda bashing (2 minutes) >>>> WG status review (5 minutes) >>>> >>>> Charter items: >>>> >>>> 1. NETCONF Monitoring Schema - Mark Scott (20 minutes) >>>> draft-ietf-netconf-monitoring >>>> 2. Partial Lock RPC for NETCONF - Balazs Lengyel (10 >> minutes) >>>> draft-ietf-netconf-partial-lock >>>> 3. NETCONF over TLS - Mohamad Badra (5 minutes) >>>> draft-ietf-netconf-monitoring >>>> >>>> Not-chartered document(s): >>>> >>>> 1. New charter text for Notification Content - Bert >> Wijnen (15 >>>> minutes) >>>> >>>> 2. Issues for 4741bis-draft - ?? (30 minutes) >>>> >>>> Open mike (15 minutes) >>>> Any other topics to discuss? >>>> >>>> AOB (5 minutes) >>>> >>> _______________________________________________ >>> 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 >> -- 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 Tue Oct 28 06:28: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 19C0328C27D; Tue, 28 Oct 2008 06:28: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 1379C28C280 for ; Tue, 28 Oct 2008 06:28: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 X+hXPNtWzeBr for ; Tue, 28 Oct 2008 06:28:46 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C604528C27D for ; Tue, 28 Oct 2008 06:28:45 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EDCD220123; Tue, 28 Oct 2008 14:28:43 +0100 (CET) X-AuditID: c1b4fb3e-abf80bb00000537b-77-4907138b12a0 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C65CE21149; Tue, 28 Oct 2008 14:28:43 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 14:27:56 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 14:27:55 +0100 Message-ID: <4907135A.2080705@ericsson.com> Date: Tue, 28 Oct 2008 14:27:54 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <4906E500.2020105@ericsson.com> In-Reply-To: X-OriginalArrivalTime: 28 Oct 2008 13:27:55.0589 (UTC) FILETIME=[FC815F50:01C93900] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #73 NETCONF Session 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 Hello Mehmet, I would rather see it as a standalone that can later be folded into a 4741bis. Putting it into the bis right now might delay it for too long. I think this is urgent stuff. I think 20 minutes would be good: My presentation would be something like: - What is the problem? - 3 ways of handling defaults - Why is this needed for interoperability? Because it effects ... - Solution basics - Open issues need to force suppressing defaults need to force presenting defaults need to advertise default handling encoding issues Balazs Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Balazs, > > we need for sure a discussion on this. How much time > do you need for discussion? > > Does this going to become a part of 4741bis or do you > see it rather as a standalone RFC? > > Cheers, > Mehmet > > >> -----Original Message----- >> From: ext Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] >> Sent: Tuesday, October 28, 2008 11:10 AM >> To: Ersue, Mehmet (NSN - DE/Munich); Bert Wijnen - IETF >> Cc: netconf@ietf.org >> Subject: Re: [Netconf] Draft Agenda for IETF #73 NETCONF Session >> >> Hello Mehmet, Bert, >> I would like to have our with-defaults draft on the agenda as >> a proposed new work item for the WG. >> >> http://tools.ietf.org/html/draft-bierman-netconf-with-defaults-01 >> >> Balazs >> >> Ersue, Mehmet (NSN - DE/Munich) wrote: >>>> Dear NETCONF WG, >>>> below is the draft agenda for the NETCONF WG session >>> at the IETF #73. Our session will be on Monday after >>> the afternoon beverage and snack break II at 1740-1930. >>>> Please send us your comments and requests concerning >>> the agenda. Our main focus in the session will be as usual >>> on open issue discussion but we have a few additional >>> topics this time. >>>> We need to summarize the 4741bis relevant issues as >>> starter for discussion. Please let us know if there is >>> anybody who wants to jump in for this. >>>> BTW: We need to organize the scribes and minute takers >>>> before the meeting. Please help us to start the session >>>> timely and send us a note if you volunteer. >>>> Bert & Mehmet >>>> _____________________________________________ >>>> NETCONF WG >>>> IETF 73, Minneapolis, MN, USA >>>> >>>> MONDAY, November 17, 2008, 1740-1950 >>>> >>>> WG Chairs: >>>> Bert Wijnen >>>> Mehmet Ersue >>>> >>>> Scribes (IF no_volunteers THEN wait_forever) >>>> Agenda bashing (2 minutes) >>>> WG status review (5 minutes) >>>> >>>> Charter items: >>>> >>>> 1. NETCONF Monitoring Schema - Mark Scott (20 minutes) >>>> draft-ietf-netconf-monitoring >>>> 2. Partial Lock RPC for NETCONF - Balazs Lengyel (10 >> minutes) >>>> draft-ietf-netconf-partial-lock >>>> 3. NETCONF over TLS - Mohamad Badra (5 minutes) >>>> draft-ietf-netconf-monitoring >>>> >>>> Not-chartered document(s): >>>> >>>> 1. New charter text for Notification Content - Bert >> Wijnen (15 >>>> minutes) >>>> >>>> 2. Issues for 4741bis-draft - ?? (30 minutes) >>>> >>>> Open mike (15 minutes) >>>> Any other topics to discuss? >>>> >>>> AOB (5 minutes) >>>> >>> _______________________________________________ >>> 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 >> -- 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 Tue Oct 28 07:00:22 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 0B3F628C26A; Tue, 28 Oct 2008 07:00:22 -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 7202528C26A for ; Tue, 28 Oct 2008 07:00:21 -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 adVVtJbpHcsU for ; Tue, 28 Oct 2008 07:00:20 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id EB2713A6A0B for ; Tue, 28 Oct 2008 07:00:19 -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 m9SDxSPO020310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Oct 2008 14:59:28 +0100 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 m9SDxQ6B028450; Tue, 28 Oct 2008 14:59:28 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Oct 2008 14:59:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 28 Oct 2008 14:59:24 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Draft Agenda for IETF #73 NETCONF Session Thread-Index: Ack5ASAsYa0i6q+YQ1i20em/u1rFcQAAr1zwAABc0jA= From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Balazs Lengyel" X-OriginalArrivalTime: 28 Oct 2008 13:59:27.0676 (UTC) FILETIME=[6446EFC0:01C93905] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081028145928-63990BB0-280212E2/0-0/0-15 X-purgate-size: 4843/0 Cc: netconf@ietf.org Subject: [Netconf] FW: Draft Agenda for IETF #73 NETCONF Session 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 is what I think too. Let us run it separately today and decide later whether it should be put into the 4741bis. 20min. focusing on issues would be fine. Can you please initiate a discussion on the issues in the maillist as a preparation for the IETF #73 meeting? Cheers, Mehmet > -----Original Message----- > From: ext Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > Sent: Tuesday, October 28, 2008 2:28 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: netconf@ietf.org; Bert Wijnen - IETF > Subject: Re: [Netconf] Draft Agenda for IETF #73 NETCONF Session > > Hello Mehmet, > I would rather see it as a standalone that can later be > folded into a 4741bis. Putting it into > the bis right now might delay it for too long. I think this > is urgent stuff. > > I think 20 minutes would be good: My presentation would be > something like: > > - What is the problem? > - 3 ways of handling defaults > - Why is this needed for interoperability? Because it effects ... > - Solution basics > - Open issues > need to force suppressing defaults > need to force presenting defaults > need to advertise default handling > encoding issues > > Balazs > > Ersue, Mehmet (NSN - DE/Munich) wrote: > > Hi Balazs, > > > > we need for sure a discussion on this. How much time > > do you need for discussion? > > > > Does this going to become a part of 4741bis or do you > > see it rather as a standalone RFC? > > > > Cheers, > > Mehmet > > > > > >> -----Original Message----- > >> From: ext Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > >> Sent: Tuesday, October 28, 2008 11:10 AM > >> To: Ersue, Mehmet (NSN - DE/Munich); Bert Wijnen - IETF > >> Cc: netconf@ietf.org > >> Subject: Re: [Netconf] Draft Agenda for IETF #73 NETCONF Session > >> > >> Hello Mehmet, Bert, > >> I would like to have our with-defaults draft on the agenda as > >> a proposed new work item for the WG. > >> > >> http://tools.ietf.org/html/draft-bierman-netconf-with-defaults-01 > >> > >> Balazs > >> > >> Ersue, Mehmet (NSN - DE/Munich) wrote: > >>>> Dear NETCONF WG, > >>>> below is the draft agenda for the NETCONF WG session > >>> at the IETF #73. Our session will be on Monday after > >>> the afternoon beverage and snack break II at 1740-1930. > >>>> Please send us your comments and requests concerning > >>> the agenda. Our main focus in the session will be as usual > >>> on open issue discussion but we have a few additional > >>> topics this time. > >>>> We need to summarize the 4741bis relevant issues as > >>> starter for discussion. Please let us know if there is > >>> anybody who wants to jump in for this. > >>>> BTW: We need to organize the scribes and minute takers > >>>> before the meeting. Please help us to start the session > >>>> timely and send us a note if you volunteer. > >>>> Bert & Mehmet > >>>> _____________________________________________ > >>>> NETCONF WG > >>>> IETF 73, Minneapolis, MN, USA > >>>> > >>>> MONDAY, November 17, 2008, 1740-1950 > >>>> > >>>> WG Chairs: > >>>> Bert Wijnen > >>>> Mehmet Ersue > >>>> > >>>> Scribes (IF no_volunteers THEN wait_forever) > >>>> Agenda bashing (2 minutes) > >>>> WG status review (5 minutes) > >>>> > >>>> Charter items: > >>>> > >>>> 1. NETCONF Monitoring Schema - Mark Scott (20 minutes) > >>>> draft-ietf-netconf-monitoring > >>>> 2. Partial Lock RPC for NETCONF - Balazs Lengyel (10 > >> minutes) > >>>> draft-ietf-netconf-partial-lock > >>>> 3. NETCONF over TLS - Mohamad Badra (5 minutes) > >>>> draft-ietf-netconf-monitoring > >>>> > >>>> Not-chartered document(s): > >>>> > >>>> 1. New charter text for Notification Content - Bert > >> Wijnen (15 > >>>> minutes) > >>>> > >>>> 2. Issues for 4741bis-draft - ?? (30 minutes) > >>>> > >>>> Open mike (15 minutes) > >>>> Any other topics to discuss? > >>>> > >>>> AOB (5 minutes) > >>>> > >>> _______________________________________________ > >>> 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 > >> > > -- > 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 Tue Oct 28 07:00:22 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 0B3F628C26A; Tue, 28 Oct 2008 07:00:22 -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 7202528C26A for ; Tue, 28 Oct 2008 07:00:21 -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 adVVtJbpHcsU for ; Tue, 28 Oct 2008 07:00:20 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id EB2713A6A0B for ; Tue, 28 Oct 2008 07:00:19 -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 m9SDxSPO020310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Oct 2008 14:59:28 +0100 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 m9SDxQ6B028450; Tue, 28 Oct 2008 14:59:28 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Oct 2008 14:59:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 28 Oct 2008 14:59:24 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Draft Agenda for IETF #73 NETCONF Session Thread-Index: Ack5ASAsYa0i6q+YQ1i20em/u1rFcQAAr1zwAABc0jA= From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Balazs Lengyel" X-OriginalArrivalTime: 28 Oct 2008 13:59:27.0676 (UTC) FILETIME=[6446EFC0:01C93905] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081028145928-63990BB0-280212E2/0-0/0-15 X-purgate-size: 4843/0 Cc: netconf@ietf.org Subject: [Netconf] FW: Draft Agenda for IETF #73 NETCONF Session 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 is what I think too. Let us run it separately today and decide later whether it should be put into the 4741bis. 20min. focusing on issues would be fine. Can you please initiate a discussion on the issues in the maillist as a preparation for the IETF #73 meeting? Cheers, Mehmet > -----Original Message----- > From: ext Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > Sent: Tuesday, October 28, 2008 2:28 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: netconf@ietf.org; Bert Wijnen - IETF > Subject: Re: [Netconf] Draft Agenda for IETF #73 NETCONF Session > > Hello Mehmet, > I would rather see it as a standalone that can later be > folded into a 4741bis. Putting it into > the bis right now might delay it for too long. I think this > is urgent stuff. > > I think 20 minutes would be good: My presentation would be > something like: > > - What is the problem? > - 3 ways of handling defaults > - Why is this needed for interoperability? Because it effects ... > - Solution basics > - Open issues > need to force suppressing defaults > need to force presenting defaults > need to advertise default handling > encoding issues > > Balazs > > Ersue, Mehmet (NSN - DE/Munich) wrote: > > Hi Balazs, > > > > we need for sure a discussion on this. How much time > > do you need for discussion? > > > > Does this going to become a part of 4741bis or do you > > see it rather as a standalone RFC? > > > > Cheers, > > Mehmet > > > > > >> -----Original Message----- > >> From: ext Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > >> Sent: Tuesday, October 28, 2008 11:10 AM > >> To: Ersue, Mehmet (NSN - DE/Munich); Bert Wijnen - IETF > >> Cc: netconf@ietf.org > >> Subject: Re: [Netconf] Draft Agenda for IETF #73 NETCONF Session > >> > >> Hello Mehmet, Bert, > >> I would like to have our with-defaults draft on the agenda as > >> a proposed new work item for the WG. > >> > >> http://tools.ietf.org/html/draft-bierman-netconf-with-defaults-01 > >> > >> Balazs > >> > >> Ersue, Mehmet (NSN - DE/Munich) wrote: > >>>> Dear NETCONF WG, > >>>> below is the draft agenda for the NETCONF WG session > >>> at the IETF #73. Our session will be on Monday after > >>> the afternoon beverage and snack break II at 1740-1930. > >>>> Please send us your comments and requests concerning > >>> the agenda. Our main focus in the session will be as usual > >>> on open issue discussion but we have a few additional > >>> topics this time. > >>>> We need to summarize the 4741bis relevant issues as > >>> starter for discussion. Please let us know if there is > >>> anybody who wants to jump in for this. > >>>> BTW: We need to organize the scribes and minute takers > >>>> before the meeting. Please help us to start the session > >>>> timely and send us a note if you volunteer. > >>>> Bert & Mehmet > >>>> _____________________________________________ > >>>> NETCONF WG > >>>> IETF 73, Minneapolis, MN, USA > >>>> > >>>> MONDAY, November 17, 2008, 1740-1950 > >>>> > >>>> WG Chairs: > >>>> Bert Wijnen > >>>> Mehmet Ersue > >>>> > >>>> Scribes (IF no_volunteers THEN wait_forever) > >>>> Agenda bashing (2 minutes) > >>>> WG status review (5 minutes) > >>>> > >>>> Charter items: > >>>> > >>>> 1. NETCONF Monitoring Schema - Mark Scott (20 minutes) > >>>> draft-ietf-netconf-monitoring > >>>> 2. Partial Lock RPC for NETCONF - Balazs Lengyel (10 > >> minutes) > >>>> draft-ietf-netconf-partial-lock > >>>> 3. NETCONF over TLS - Mohamad Badra (5 minutes) > >>>> draft-ietf-netconf-monitoring > >>>> > >>>> Not-chartered document(s): > >>>> > >>>> 1. New charter text for Notification Content - Bert > >> Wijnen (15 > >>>> minutes) > >>>> > >>>> 2. Issues for 4741bis-draft - ?? (30 minutes) > >>>> > >>>> Open mike (15 minutes) > >>>> Any other topics to discuss? > >>>> > >>>> AOB (5 minutes) > >>>> > >>> _______________________________________________ > >>> 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 > >> > > -- > 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 Tue Oct 28 14:48: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 0EE5A28C0E2; Tue, 28 Oct 2008 14:48: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 56C2A3A6CAA for ; Tue, 28 Oct 2008 14:48:22 -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 fSPIdr4EpmMO for ; Tue, 28 Oct 2008 14:48:21 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 78B8C28C0E2 for ; Tue, 28 Oct 2008 14:48:21 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 257932010B for ; Tue, 28 Oct 2008 22:48:19 +0100 (CET) X-AuditID: c1b4fb3e-aff88bb00000537b-63-490788a38c16 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1DBD720072 for ; Tue, 28 Oct 2008 22:48:19 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 22:48:18 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 22:48:17 +0100 Message-ID: <490788A1.9030602@ericsson.com> Date: Tue, 28 Oct 2008 22:48:17 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf mailing list X-OriginalArrivalTime: 28 Oct 2008 21:48:17.0887 (UTC) FILETIME=[E3307EF0:01C93946] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Are capabilities static or dynamic ? 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 Hello. A netconf agent will report it's capabilities at the start of the session. But can these capabilites change later during the session? I see three use case where they might: 1) A new YANG Module (YAM) is added during run-time. This can be the result of e.g. adding a new license key to the node. 2) A capability might be configurable, the superuser might allow or disallow the usage of partial-locking or the validate capability 3) A Netconf session survives an upgrade (happens in telecom grade nodes for other OAM sessions) We could say that the capabilities change only at the end of the session, but if we have an ongoing session, that delays the capability change and a new session, that uses the new capabilities, that can really lead to confusion. Also maintaining a separate capability set for ongoing sessions is a hassle. On solution could be to allow capability changes and send a Netconf notification about them. Opinions? Balazs _____________________________From netconf-bounces@ietf.org Tue Oct 28 14:48: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 0EE5A28C0E2; Tue, 28 Oct 2008 14:48: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 56C2A3A6CAA for ; Tue, 28 Oct 2008 14:48:22 -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 fSPIdr4EpmMO for ; Tue, 28 Oct 2008 14:48:21 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 78B8C28C0E2 for ; Tue, 28 Oct 2008 14:48:21 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 257932010B for ; Tue, 28 Oct 2008 22:48:19 +0100 (CET) X-AuditID: c1b4fb3e-aff88bb00000537b-63-490788a38c16 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1DBD720072 for ; Tue, 28 Oct 2008 22:48:19 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 22:48:18 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 22:48:17 +0100 Message-ID: <490788A1.9030602@ericsson.com> Date: Tue, 28 Oct 2008 22:48:17 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf mailing list X-OriginalArrivalTime: 28 Oct 2008 21:48:17.0887 (UTC) FILETIME=[E3307EF0:01C93946] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Are capabilities static or dynamic ? 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 Hello. A netconf agent will report it's capabilities at the start of the session. But can these capabilites change later during the session? I see three use case where they might: 1) A new YANG Module (YAM) is added during run-time. This can be the result of e.g. adding a new license key to the node. 2) A capability might be configurable, the superuser might allow or disallow the usage of partial-locking or the validate capability 3) A Netconf session survives an upgrade (happens in telecom grade nodes for other OAM sessions) We could say that the capabilities change only at the end of the session, but if we have an ongoing session, that delays the capability change and a new session, that uses the new capabilities, that can really lead to confusion. Also maintaining a separate capability set for ongoing sessions is a hassle. On solution could be to allow capability changes and send a Netconf notification about them. Opinions? Balazs _____________________________________________________ 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 Oct 28 15:37:06 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 020173A6CC7; Tue, 28 Oct 2008 15:37:06 -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 C12E63A6CC8 for ; Tue, 28 Oct 2008 15:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 lXx57IjDPPVN for ; Tue, 28 Oct 2008 15:37:04 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id B60403A6CC7 for ; Tue, 28 Oct 2008 15:37:03 -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 m9SMb156016722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Oct 2008 23:37:01 +0100 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 m9SMb0XP009280; Tue, 28 Oct 2008 23:37:00 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Oct 2008 23:36:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 28 Oct 2008 23:36:39 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Agenda for IETF #73 NETCONF Session Thread-Index: Ack5TaSOWrKrjdEdSNSupJ4TNpGApQ== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 28 Oct 2008 22:36:43.0686 (UTC) FILETIME=[A72E3C60:01C9394D] Subject: [Netconf] Draft Agenda for IETF #73 NETCONF Session 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, I uploaded the draft agenda below to the meeting material site. http://www.ietf.org/proceedings/08nov/agenda/netconf.txt Cheers, Mehmet NETCONF WG IETF 73, Minneapolis, MN, USA MONDAY, November 17, 2008, 1740-1950 WG Chairs: Bert Wijnen Mehmet Ersue Scribes (IF no_volunteers THEN wait_forever) Agenda bashing (2 minutes) WG status review (5 minutes) Charter items: 1. NETCONF Monitoring Schema - Mark Scott (20 minutes) draft-ietf-netconf-monitoring 2. Partial Lock RPC for NETCONF - Balazs Lengyel (5 minutes) draft-ietf-netconf-partial-lock 3. NETCONF over TLS - Mohamad Badra (5 minutes) draft-ietf-netconf-monitoring Not-chartered document(s): 1. New charter text for Notification Content - Bert Wijnen (15 minutes) 2. Issues for 4741bis-draft - ?? (30 minutes) 3. With-defaults capability for NETCONF - A. Bierman/B. Lengyel (20 minutes) draft-bierman-netconf-with-defaults Open mike (10 minutes) Any other topics to discuss? AOB _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Oct 28 15:37:06 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 020173A6CC7; Tue, 28 Oct 2008 15:37:06 -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 C12E63A6CC8 for ; Tue, 28 Oct 2008 15:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 lXx57IjDPPVN for ; Tue, 28 Oct 2008 15:37:04 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id B60403A6CC7 for ; Tue, 28 Oct 2008 15:37:03 -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 m9SMb156016722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Oct 2008 23:37:01 +0100 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 m9SMb0XP009280; Tue, 28 Oct 2008 23:37:00 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Oct 2008 23:36:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 28 Oct 2008 23:36:39 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Agenda for IETF #73 NETCONF Session Thread-Index: Ack5TaSOWrKrjdEdSNSupJ4TNpGApQ== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 28 Oct 2008 22:36:43.0686 (UTC) FILETIME=[A72E3C60:01C9394D] Subject: [Netconf] Draft Agenda for IETF #73 NETCONF Session 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, I uploaded the draft agenda below to the meeting material site. http://www.ietf.org/proceedings/08nov/agenda/netconf.txt Cheers, Mehmet NETCONF WG IETF 73, Minneapolis, MN, USA MONDAY, November 17, 2008, 1740-1950 WG Chairs: Bert Wijnen Mehmet Ersue Scribes (IF no_volunteers THEN wait_forever) Agenda bashing (2 minutes) WG status review (5 minutes) Charter items: 1. NETCONF Monitoring Schema - Mark Scott (20 minutes) draft-ietf-netconf-monitoring 2. Partial Lock RPC for NETCONF - Balazs Lengyel (5 minutes) draft-ietf-netconf-partial-lock 3. NETCONF over TLS - Mohamad Badra (5 minutes) draft-ietf-netconf-monitoring Not-chartered document(s): 1. New charter text for Notification Content - Bert Wijnen (15 minutes) 2. Issues for 4741bis-draft - ?? (30 minutes) 3. With-defaults capability for NETCONF - A. Bierman/B. Lengyel (20 minutes) draft-bierman-netconf-with-defaults Open mike (10 minutes) Any other topics to discuss? AOB _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Oct 28 20:54: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 9124D3A6A90; Tue, 28 Oct 2008 20:54: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 220B33A6A51 for ; Tue, 28 Oct 2008 20:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[AWL=-0.435, 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 c9baF8utSll6 for ; Tue, 28 Oct 2008 20:54:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 63A973A6880 for ; Tue, 28 Oct 2008 20:54:36 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 58EC6C0048; Wed, 29 Oct 2008 04:54:35 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XRRTU7fsMKv9; Wed, 29 Oct 2008 04:54:26 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 271F7C001D; Wed, 29 Oct 2008 04:54:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F376F82E114; Wed, 29 Oct 2008 04:54:24 +0100 (CET) Date: Wed, 29 Oct 2008 04:54:24 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20081029035424.GD2467@elstar.local> Mail-Followup-To: Balazs Lengyel , netconf mailing list References: <490788A1.9030602@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <490788A1.9030602@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf mailing list Subject: Re: [Netconf] Are capabilities static or dynamic ? 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, Oct 28, 2008 at 10:48:17PM +0100, Balazs Lengyel wrote: > On solution could be to allow capability changes and send a Netconf > notification about them. Does the notification just communicate the capability-change-event and the manager then has to grab new capabilites from the NETCONF monitoring data model or is the idea that the capability-change-event carries all capabilities (or a delta of the capabilities)? /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 Oct 28 20:54: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 9124D3A6A90; Tue, 28 Oct 2008 20:54: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 220B33A6A51 for ; Tue, 28 Oct 2008 20:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[AWL=-0.435, 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 c9baF8utSll6 for ; Tue, 28 Oct 2008 20:54:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 63A973A6880 for ; Tue, 28 Oct 2008 20:54:36 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 58EC6C0048; Wed, 29 Oct 2008 04:54:35 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XRRTU7fsMKv9; Wed, 29 Oct 2008 04:54:26 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 271F7C001D; Wed, 29 Oct 2008 04:54:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F376F82E114; Wed, 29 Oct 2008 04:54:24 +0100 (CET) Date: Wed, 29 Oct 2008 04:54:24 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20081029035424.GD2467@elstar.local> Mail-Followup-To: Balazs Lengyel , netconf mailing list References: <490788A1.9030602@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <490788A1.9030602@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf mailing list Subject: Re: [Netconf] Are capabilities static or dynamic ? 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, Oct 28, 2008 at 10:48:17PM +0100, Balazs Lengyel wrote: > On solution could be to allow capability changes and send a Netconf > notification about them. Does the notification just communicate the capability-change-event and the manager then has to grab new capabilites from the NETCONF monitoring data model or is the idea that the capability-change-event carries all capabilities (or a delta of the capabilities)? /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 Wed Oct 29 02:29:07 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 A17C63A69F5; Wed, 29 Oct 2008 02:29:07 -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 54E0A3A6980 for ; Wed, 29 Oct 2008 02:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.153 X-Spam-Level: X-Spam-Status: No, score=-6.153 tagged_above=-999 required=5 tests=[AWL=0.096, 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 eLmjgsN0DQdI for ; Wed, 29 Oct 2008 02:29:05 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 84FFC3A68C0 for ; Wed, 29 Oct 2008 02:29:05 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 473FF20E9E for ; Wed, 29 Oct 2008 10:28:58 +0100 (CET) X-AuditID: c1b4fb3c-b00d2bb0000015b5-f8-49082cd9688f Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C6D2820DD3 for ; Wed, 29 Oct 2008 10:28:57 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 10:28:57 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 10:28:57 +0100 Message-ID: <49082CD8.6010102@ericsson.com> Date: Wed, 29 Oct 2008 10:28:56 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Balazs Lengyel , netconf mailing list References: <490788A1.9030602@ericsson.com> <20081029035424.GD2467@elstar.local> In-Reply-To: <20081029035424.GD2467@elstar.local> X-OriginalArrivalTime: 29 Oct 2008 09:28:57.0428 (UTC) FILETIME=[C4B56140:01C939A8] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] Are capabilities static or dynamic ? 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 Hello, IMHO the notification should carry the full list of capabilities. If someone is interested (subscribed) why should we force him to issue a get? However a notification without much content is usable as well. Sharon could include this in her draft. Balazs Juergen Schoenwaelder wrote: > On Tue, Oct 28, 2008 at 10:48:17PM +0100, Balazs Lengyel wrote: > >> On solution could be to allow capability changes and send a Netconf >> notification about them. > > Does the notification just communicate the capability-change-event and > the manager then has to grab new capabilites from the NETCONF > monitoring data model or is the idea that the capability-change-event > carries all capabilities (or a delta of the capabilities)? > > /js > -- 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 Oct 29 02:29:07 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 A17C63A69F5; Wed, 29 Oct 2008 02:29:07 -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 54E0A3A6980 for ; Wed, 29 Oct 2008 02:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.153 X-Spam-Level: X-Spam-Status: No, score=-6.153 tagged_above=-999 required=5 tests=[AWL=0.096, 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 eLmjgsN0DQdI for ; Wed, 29 Oct 2008 02:29:05 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 84FFC3A68C0 for ; Wed, 29 Oct 2008 02:29:05 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 473FF20E9E for ; Wed, 29 Oct 2008 10:28:58 +0100 (CET) X-AuditID: c1b4fb3c-b00d2bb0000015b5-f8-49082cd9688f Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C6D2820DD3 for ; Wed, 29 Oct 2008 10:28:57 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 10:28:57 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 10:28:57 +0100 Message-ID: <49082CD8.6010102@ericsson.com> Date: Wed, 29 Oct 2008 10:28:56 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Balazs Lengyel , netconf mailing list References: <490788A1.9030602@ericsson.com> <20081029035424.GD2467@elstar.local> In-Reply-To: <20081029035424.GD2467@elstar.local> X-OriginalArrivalTime: 29 Oct 2008 09:28:57.0428 (UTC) FILETIME=[C4B56140:01C939A8] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] Are capabilities static or dynamic ? 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 Hello, IMHO the notification should carry the full list of capabilities. If someone is interested (subscribed) why should we force him to issue a get? However a notification without much content is usable as well. Sharon could include this in her draft. Balazs Juergen Schoenwaelder wrote: > On Tue, Oct 28, 2008 at 10:48:17PM +0100, Balazs Lengyel wrote: > >> On solution could be to allow capability changes and send a Netconf >> notification about them. > > Does the notification just communicate the capability-change-event and > the manager then has to grab new capabilites from the NETCONF > monitoring data model or is the idea that the capability-change-event > carries all capabilities (or a delta of the capabilities)? > > /js > -- 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 Oct 29 08:00:27 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 39B1D28C3C0; Wed, 29 Oct 2008 08:00:27 -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 9959328C3C5 for ; Wed, 29 Oct 2008 08:00:26 -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 J9fiKxmXZ-1Q for ; Wed, 29 Oct 2008 08:00:22 -0700 (PDT) Received: from mail.edgeware.tv (mail.edgeware.tv [82.99.7.138]) by core3.amsl.com (Postfix) with ESMTP id B2D8428C3C0 for ; Wed, 29 Oct 2008 08:00:22 -0700 (PDT) Received: from [192.168.99.223] (unknown [192.168.99.223]) by picnic4.edgeware.tv (Postfix) with ESMTPSA id F13E451B6096; Tue, 28 Oct 2008 11:56:17 +0100 (CET) Message-ID: <4906EF4E.3060305@edgeware.tv> Date: Tue, 28 Oct 2008 11:54:06 +0100 From: Johan Rydberg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Balazs Lengyel References: <4906E500.2020105@ericsson.com> In-Reply-To: <4906E500.2020105@ericsson.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #73 NETCONF Session 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 Balazs Lengyel skrev: > Hello Mehmet, Bert, > I would like to have our with-defaults draft on the agenda as a proposed > new work item for the WG. > > http://tools.ietf.org/html/draft-bierman-netconf-with-defaults-01 May I ask why the attribute is on the element and not on the operation element (get, copy-config, ..) ? It seems that it is an attribute to the protocol and not to the transport/rpc layer. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Oct 29 08:00:27 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 39B1D28C3C0; Wed, 29 Oct 2008 08:00:27 -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 9959328C3C5 for ; Wed, 29 Oct 2008 08:00:26 -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 J9fiKxmXZ-1Q for ; Wed, 29 Oct 2008 08:00:22 -0700 (PDT) Received: from mail.edgeware.tv (mail.edgeware.tv [82.99.7.138]) by core3.amsl.com (Postfix) with ESMTP id B2D8428C3C0 for ; Wed, 29 Oct 2008 08:00:22 -0700 (PDT) Received: from [192.168.99.223] (unknown [192.168.99.223]) by picnic4.edgeware.tv (Postfix) with ESMTPSA id F13E451B6096; Tue, 28 Oct 2008 11:56:17 +0100 (CET) Message-ID: <4906EF4E.3060305@edgeware.tv> Date: Tue, 28 Oct 2008 11:54:06 +0100 From: Johan Rydberg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Balazs Lengyel References: <4906E500.2020105@ericsson.com> In-Reply-To: <4906E500.2020105@ericsson.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #73 NETCONF Session 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 Balazs Lengyel skrev: > Hello Mehmet, Bert, > I would like to have our with-defaults draft on the agenda as a proposed > new work item for the WG. > > http://tools.ietf.org/html/draft-bierman-netconf-with-defaults-01 May I ask why the attribute is on the element and not on the operation element (get, copy-config, ..) ? It seems that it is an attribute to the protocol and not to the transport/rpc layer. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Oct 30 00:50: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 A57493A6A56; Thu, 30 Oct 2008 00:50: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 566583A6A56 for ; Thu, 30 Oct 2008 00:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 rlgpH1U5UVFv for ; Thu, 30 Oct 2008 00:50:04 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 3040C3A686B for ; Thu, 30 Oct 2008 00:50:03 -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 m9U7o02F018256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Oct 2008 08:50:00 +0100 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 m9U7nwvw000996; Thu, 30 Oct 2008 08:49:59 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 08:49:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 08:49:54 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Looking for an Editor for the 4741bis Draft Thread-Index: Ack6ZBj5TI8xAHclRtOwYgzbFilQhA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 30 Oct 2008 07:49:56.0063 (UTC) FILETIME=[19CAC6F0:01C93A64] Subject: [Netconf] Looking for an Editor for the 4741bis 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 All, as you might have seen on the draft agenda the slot for the 4741bis has no presenter noted. http://www.ietf.org/proceedings/08nov/agenda/netconf.txt We need a volunteer willing to drive the 4741bis document as editor. It would be nice if we can start the discussion and preparation of the 4741bis draft with a person who is capable to push it as early as possible. Therefor we want to cast this position before the NETCONF session at IETF #73. Please let us know by next week if you are interested. Bert & Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Oct 30 00:50: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 A57493A6A56; Thu, 30 Oct 2008 00:50: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 566583A6A56 for ; Thu, 30 Oct 2008 00:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 rlgpH1U5UVFv for ; Thu, 30 Oct 2008 00:50:04 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 3040C3A686B for ; Thu, 30 Oct 2008 00:50:03 -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 m9U7o02F018256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Oct 2008 08:50:00 +0100 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 m9U7nwvw000996; Thu, 30 Oct 2008 08:49:59 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 08:49:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 08:49:54 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Looking for an Editor for the 4741bis Draft Thread-Index: Ack6ZBj5TI8xAHclRtOwYgzbFilQhA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 30 Oct 2008 07:49:56.0063 (UTC) FILETIME=[19CAC6F0:01C93A64] Subject: [Netconf] Looking for an Editor for the 4741bis 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 All, as you might have seen on the draft agenda the slot for the 4741bis has no presenter noted. http://www.ietf.org/proceedings/08nov/agenda/netconf.txt We need a volunteer willing to drive the 4741bis document as editor. It would be nice if we can start the discussion and preparation of the 4741bis draft with a person who is capable to push it as early as possible. Therefor we want to cast this position before the NETCONF session at IETF #73. Please let us know by next week if you are interested. Bert & Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Oct 30 08:15: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 7D66B28B56A; Thu, 30 Oct 2008 08:15: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 7EDCD28B797 for ; Thu, 30 Oct 2008 08:15: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 wkGmjRPvtUu7 for ; Thu, 30 Oct 2008 08:15:05 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 3701A28B23E for ; Thu, 30 Oct 2008 08:15:04 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m9UFF0417492; Thu, 30 Oct 2008 15:15:00 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 11:14:50 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC6DE08E@zcarhxm0.corp.nortel.com> In-Reply-To: <49082CD8.6010102@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Are capabilities static or dynamic ? Thread-Index: Ack5qM9AEf6s4ny2SlKTMLtPvr2ZkwA7YFgw References: <490788A1.9030602@ericsson.com> <20081029035424.GD2467@elstar.local> <49082CD8.6010102@ericsson.com> From: "Mark Scott" To: "Balazs Lengyel" , "netconf mailing list" Subject: Re: [Netconf] Are capabilities static or dynamic ? 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, I am in favour of allowing dynamic capabilities changes. This was a base assumption in including them in the NETCONF monitoring data model. I am also in favour of two levels of notification. Not only for this but for notifications in general. We consider these 'light-weight' (terse) and 'heavy-weight' (detailed) notifications. The former simply indicates a particular instance has been modified and managers decide whether or not to do anything (eg: 'capabilities datamodel: update'). The latter actually sends the delta of the change in the notification (eg: 'capabilities datamodel: Y added'). Individual managers determine which notification type (level of detail) they want by subscription. Mark -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Balazs Lengyel Sent: Wednesday, October 29, 2008 5:29 AM To: Balazs Lengyel; netconf mailing list Subject: Re: [Netconf] Are capabilities static or dynamic ? Hello, IMHO the notification should carry the full list of capabilities. If someone is interested (subscribed) why should we force him to issue a get? However a notification without much content is usable as well. Sharon could include this in her draft. Balazs Juergen Schoenwaelder wrote: > On Tue, Oct 2From netconf-bounces@ietf.org Thu Oct 30 08:15: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 7D66B28B56A; Thu, 30 Oct 2008 08:15: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 7EDCD28B797 for ; Thu, 30 Oct 2008 08:15: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 wkGmjRPvtUu7 for ; Thu, 30 Oct 2008 08:15:05 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 3701A28B23E for ; Thu, 30 Oct 2008 08:15:04 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m9UFF0417492; Thu, 30 Oct 2008 15:15:00 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 11:14:50 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC6DE08E@zcarhxm0.corp.nortel.com> In-Reply-To: <49082CD8.6010102@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Are capabilities static or dynamic ? Thread-Index: Ack5qM9AEf6s4ny2SlKTMLtPvr2ZkwA7YFgw References: <490788A1.9030602@ericsson.com> <20081029035424.GD2467@elstar.local> <49082CD8.6010102@ericsson.com> From: "Mark Scott" To: "Balazs Lengyel" , "netconf mailing list" Subject: Re: [Netconf] Are capabilities static or dynamic ? 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, I am in favour of allowing dynamic capabilities changes. This was a base assumption in including them in the NETCONF monitoring data model. I am also in favour of two levels of notification. Not only for this but for notifications in general. We consider these 'light-weight' (terse) and 'heavy-weight' (detailed) notifications. The former simply indicates a particular instance has been modified and managers decide whether or not to do anything (eg: 'capabilities datamodel: update'). The latter actually sends the delta of the change in the notification (eg: 'capabilities datamodel: Y added'). Individual managers determine which notification type (level of detail) they want by subscription. Mark -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Balazs Lengyel Sent: Wednesday, October 29, 2008 5:29 AM To: Balazs Lengyel; netconf mailing list Subject: Re: [Netconf] Are capabilities static or dynamic ? Hello, IMHO the notification should carry the full list of capabilities. If someone is interested (subscribed) why should we force him to issue a get? However a notification without much content is usable as well. Sharon could include this in her draft. Balazs Juergen Schoenwaelder wrote: > On Tue,8, 2008 at 10:48:17PM +0100, Balazs Lengyel wrote: > >> On solution could be to allow capability changes and send a Netconf >> notification about them. > > Does the notification just communicate the capability-change-event and > the manager then has to grab new capabilites from the NETCONF > monitoring data model or is the idea that the capability-change-event > carries all capabilities (or a delta of the capabilities)? > > /js > -- 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf Oct 28, 2008 at 10:48:17PM +0100, Balazs Lengyel wrote: > >> On solution could be to allow capability changes and send a Netconf >> notification about them. > > Does the notification just communicate the capability-change-event and > the manager then has to grab new capabilites from the NETCONF > monitoring data model or is the idea that the capability-change-event > carries all capabilities (or a delta of the capabilities)? > > /js > -- 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Oct 30 09:29: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 678603A694D; Thu, 30 Oct 2008 09:29: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 6A4EA3A6A2D for ; Thu, 30 Oct 2008 09:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.266, 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 pvDYmml05tLJ for ; Thu, 30 Oct 2008 09:29:08 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 929DF3A694D for ; Thu, 30 Oct 2008 09:29:08 -0700 (PDT) Received: (qmail 77758 invoked from network); 30 Oct 2008 16:28:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 30 Oct 2008 16:28:53 -0000 X-YMail-OSG: h928b0cVM1msUbzBHj.llqVIOYzP5bO3wkSJnIPuH_N2rZKRw6aEwY_r575KkXC4F8udgyQNuO9LYo47p9C0zYnC15G2ed8cPROSfoqibRfGInBjEIUy15wBu0zRSTxrOa0HZvArw04YN3jEXCs9cDaj X-Yahoo-Newman-Property: ymail-3 Message-ID: <4909E0C4.4000202@netconfcentral.com> Date: Thu, 30 Oct 2008 09:28:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Mark Scott References: <490788A1.9030602@ericsson.com> <20081029035424.GD2467@elstar.local> <49082CD8.6010102@ericsson.com> <238C6E77EA42504DA038BAEE6D1C11EC6DE08E@zcarhxm0.corp.nortel.com> In-Reply-To: <238C6E77EA42504DA038BAEE6D1C11EC6DE08E@zcarhxm0.corp.nortel.com> Cc: netconf mailing list Subject: Re: [Netconf] Are capabilities static or dynamic ? 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 Mark Scott wrote: > Hi Balazs, > > I am in favour of allowing dynamic capabilities changes. This was a > base assumption in including them in the NETCONF monitoring data model. > > I am also in favour of two levels of notification. Not only for this > but for notifications in general. > I support any excuse to define some standard NETCONF content. However, it would break the contract of any existing sessions to take away or modify any capabilities each existing session already knows about. Adding new capabilities mid-session is OK, but nothing else. (Operationally, a way to override that rule is probably needed.) > We consider these 'light-weight' (terse) and 'heavy-weight' (detailed) > notifications. The former simply indicates a particular instance has > been modified and managers decide whether or not to do anything (eg: > 'capabilities datamodel: update'). The latter actually sends the delta > of the change in the notification (eg: 'capabilities datamodel: Y > added'). > The subscription already has filters, so the notification content needs to be easily filtered, which means more general fields than eventTime (like eventClass, eventSubClass, and eventSeverity?) I don't think "terse vs. detailed" is a good general filter though. (eventDetailLevel?) But you are describing an extension to the parameters, right? Or do you mean the agent will generate two notifications for each event (terse and detailed) and applications will know to filter one of them out? > Individual managers determine which notification type (level of detail) > they want by subscription. > > Mark Andy > > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Balazs Lengyel > Sent: Wednesday, October 29, 2008 5:29 AM > To: Balazs Lengyel; netconf mailing list > Subject: Re: [Netconf] Are capabilities static or dynamic ? > > Hello, > IMHO the notification should carry the full list of capabilities. If > someone is interested > (subscribed) why should we force him to issue a get? However a > notification without much content is usable as well. > > Sharon could include this in her draft. > > Balazs > > Juergen Schoenwaelder wrote: >> On Tue, Oct 28, 2008 at 10:48:17PM +0100, Balazs Lengyel wrote: >> >>> On solution could be to allow capability changes and send a Netconf >>> notification about them. >> Does the notification just communicate the capability-change-event and > >> the manager then has to grab new capabilites from the NETCONF >> monitoring data model or is the idea that the capability-change-event >> carries all capabilities (or a delta of the capabilities)? >> >> /js >> > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Oct 30 09:29: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 678603A694D; Thu, 30 Oct 2008 09:29: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 6A4EA3A6A2D for ; Thu, 30 Oct 2008 09:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.266, 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 pvDYmml05tLJ for ; Thu, 30 Oct 2008 09:29:08 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 929DF3A694D for ; Thu, 30 Oct 2008 09:29:08 -0700 (PDT) Received: (qmail 77758 invoked from network); 30 Oct 2008 16:28:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.125.157.90 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 30 Oct 2008 16:28:53 -0000 X-YMail-OSG: h928b0cVM1msUbzBHj.llqVIOYzP5bO3wkSJnIPuH_N2rZKRw6aEwY_r575KkXC4F8udgyQNuO9LYo47p9C0zYnC15G2ed8cPROSfoqibRfGInBjEIUy15wBu0zRSTxrOa0HZvArw04YN3jEXCs9cDaj X-Yahoo-Newman-Property: ymail-3 Message-ID: <4909E0C4.4000202@netconfcentral.com> Date: Thu, 30 Oct 2008 09:28:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Mark Scott References: <490788A1.9030602@ericsson.com> <20081029035424.GD2467@elstar.local> <49082CD8.6010102@ericsson.com> <238C6E77EA42504DA038BAEE6D1C11EC6DE08E@zcarhxm0.corp.nortel.com> In-Reply-To: <238C6E77EA42504DA038BAEE6D1C11EC6DE08E@zcarhxm0.corp.nortel.com> Cc: netconf mailing list Subject: Re: [Netconf] Are capabilities static or dynamic ? 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 Mark Scott wrote: > Hi Balazs, > > I am in favour of allowing dynamic capabilities changes. This was a > base assumption in including them in the NETCONF monitoring data model. > > I am also in favour of two levels of notification. Not only for this > but for notifications in general. > I support any excuse to define some standard NETCONF content. However, it would break the contract of any existing sessions to take away or modify any capabilities each existing session already knows about. Adding new capabilities mid-session is OK, but nothing else. (Operationally, a way to override that rule is probably needed.) > We consider these 'light-weight' (terse) and 'heavy-weight' (detailed) > notifications. The former simply indicates a particular instance has > been modified and managers decide whether or not to do anything (eg: > 'capabilities datamodel: update'). The latter actually sends the delta > of the change in the notification (eg: 'capabilities datamodel: Y > added'). > The subscription already has filters, so the notification content needs to be easily filtered, which means more general fields than eventTime (like eventClass, eventSubClass, and eventSeverity?) I don't think "terse vs. detailed" is a good general filter though. (eventDetailLevel?) But you are describing an extension to the parameters, right? Or do you mean the agent will generate two notifications for each event (terse and detailed) and applications will know to filter one of them out? > Individual managers determine which notification type (level of detail) > they want by subscription. > > Mark Andy > > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Balazs Lengyel > Sent: Wednesday, October 29, 2008 5:29 AM > To: Balazs Lengyel; netconf mailing list > Subject: Re: [Netconf] Are capabilities static or dynamic ? > > Hello, > IMHO the notification should carry the full list of capabilities. If > someone is interested > (subscribed) why should we force him to issue a get? However a > notification without much content is usable as well. > > Sharon could include this in her draft. > > Balazs > > Juergen Schoenwaelder wrote: >> On Tue, Oct 28, 2008 at 10:48:17PM +0100, Balazs Lengyel wrote: >> >>> On solution could be to allow capability changes and send a Netconf >>> notification about them. >> Does the notification just communicate the capability-change-event and > >> the manager then has to grab new capabilites from the NETCONF >> monitoring data model or is the idea that the capability-change-event >> carries all capabilities (or a delta of the capabilities)? >> >> /js >> > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Oct 30 17:39: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 CE13C3A6B7A; Thu, 30 Oct 2008 17:39: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 9C8363A6B72 for ; Thu, 30 Oct 2008 17:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LKIgFrUt1qq for ; Thu, 30 Oct 2008 17:39:49 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id A4F7F3A6B71 for ; Thu, 30 Oct 2008 17:39:48 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Thu, 30 Oct 2008 17:39:48 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 17:38:46 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 17:38:46 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 17:38:46 -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 m9V0cjM42437; Thu, 30 Oct 2008 17:38:45 -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 m9V0Y3KS073495; Fri, 31 Oct 2008 00:34:04 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200810310034.m9V0Y3KS073495@idle.juniper.net> To: Andy Bierman In-reply-to: <4909E0C4.4000202@netconfcentral.com> Date: Thu, 30 Oct 2008 20:34:03 -0400 From: Phil Shafer X-OriginalArrivalTime: 31 Oct 2008 00:38:46.0114 (UTC) FILETIME=[08839420:01C93AF1] Cc: netconf mailing list Subject: Re: [Netconf] Are capabilities static or dynamic ? 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 Andy Bierman writes: >However, it would break the contract of any existing sessions >to take away or modify any capabilities each existing >session already knows about. Adding new capabilities >mid-session is OK, but nothing else. (Operationally, a way >to override that rule is probably needed.) Sure, it's painful, but when a user removes a software module or a license key, the abilities of the device will change. It's unavoidable. The options are (a) announce it, or (b) nuke any previous client sessions. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Oct 30 17:39: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 CE13C3A6B7A; Thu, 30 Oct 2008 17:39: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 9C8363A6B72 for ; Thu, 30 Oct 2008 17:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LKIgFrUt1qq for ; Thu, 30 Oct 2008 17:39:49 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id A4F7F3A6B71 for ; Thu, 30 Oct 2008 17:39:48 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Thu, 30 Oct 2008 17:39:48 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 17:38:46 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 17:38:46 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 17:38:46 -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 m9V0cjM42437; Thu, 30 Oct 2008 17:38:45 -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 m9V0Y3KS073495; Fri, 31 Oct 2008 00:34:04 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200810310034.m9V0Y3KS073495@idle.juniper.net> To: Andy Bierman In-reply-to: <4909E0C4.4000202@netconfcentral.com> Date: Thu, 30 Oct 2008 20:34:03 -0400 From: Phil Shafer X-OriginalArrivalTime: 31 Oct 2008 00:38:46.0114 (UTC) FILETIME=[08839420:01C93AF1] Cc: netconf mailing list Subject: Re: [Netconf] Are capabilities static or dynamic ? 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 Andy Bierman writes: >However, it would break the contract of any existing sessions >to take away or modify any capabilities each existing >session already knows about. Adding new capabilities >mid-session is OK, but nothing else. (Operationally, a way >to override that rule is probably needed.) Sure, it's painful, but when a user removes a software module or a license key, the abilities of the device will change. It's unavoidable. The options are (a) announce it, or (b) nuke any previous client sessions. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Oct 30 18:31: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 39A633A6A34; Thu, 30 Oct 2008 18:31: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 9E6783A6A34 for ; Thu, 30 Oct 2008 18:31: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 yUF774ZsQnlz for ; Thu, 30 Oct 2008 18:31:10 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A369B3A67FC for ; Thu, 30 Oct 2008 18:31:10 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m9V1V1s13095; Fri, 31 Oct 2008 01:31:01 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 21:30:50 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC73004A@zcarhxm0.corp.nortel.com> In-Reply-To: <200810310034.m9V0Y3KS073495@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Are capabilities static or dynamic ? Thread-Index: Ack68S5wVWvenzlARjeVw/AxB2MCQAABuhZQ References: <4909E0C4.4000202@netconfcentral.com> <200810310034.m9V0Y3KS073495@idle.juniper.net> From: "Mark Scott" To: "Phil Shafer" , "Andy Bierman" Cc: netconf mailing list Subject: Re: [Netconf] Are capabilities static or dynamic ? 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 would prefer to announce it rather than kill the sessions. Well behaved clients keep their sessions. Others can expect errors if they try to use the capability once it's been revoked. mark -----Original Message----- From: Phil Shafer [mailto:phil@juniper.net] Sent: Thursday, October 30, 2008 8:34 PM To: Andy Bierman Cc: Scott, Mark (CAR:2Y01); netconf mailing list Subject: Re: [Netconf] Are capabilities static or dynamic ? Andy Bierman writes: >However, it would break the contract of any existing sessions to take >away or modify any capabilities each existing session already knows >about. Adding new capabilities mid-session is OK, but nothing else. >(Operationally, a way to override that rule is probably needed.) Sure, it's painful, but when a user removes a software module or a license key, the abilities of the device will change. It's unavoidable. The options are (a) announce it, or (b) nuke any previous client sessions. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Oct 30 18:31: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 39A633A6A34; Thu, 30 Oct 2008 18:31: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 9E6783A6A34 for ; Thu, 30 Oct 2008 18:31: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 yUF774ZsQnlz for ; Thu, 30 Oct 2008 18:31:10 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A369B3A67FC for ; Thu, 30 Oct 2008 18:31:10 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m9V1V1s13095; Fri, 31 Oct 2008 01:31:01 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 21:30:50 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC73004A@zcarhxm0.corp.nortel.com> In-Reply-To: <200810310034.m9V0Y3KS073495@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Are capabilities static or dynamic ? Thread-Index: Ack68S5wVWvenzlARjeVw/AxB2MCQAABuhZQ References: <4909E0C4.4000202@netconfcentral.com> <200810310034.m9V0Y3KS073495@idle.juniper.net> From: "Mark Scott" To: "Phil Shafer" , "Andy Bierman" Cc: netconf mailing list Subject: Re: [Netconf] Are capabilities static or dynamic ? 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 would prefer to announce it rather than kill the sessions. Well behaved clients keep their sessions. Others can expect errors if they try to use the capability once it's been revoked. mark -----Original Message----- From: Phil Shafer [mailto:phil@juniper.net] Sent: Thursday, October 30, 2008 8:34 PM To: Andy Bierman Cc: Scott, Mark (CAR:2Y01); netconf mailing list Subject: Re: [Netconf] Are capabilities static or dynamic ? Andy Bierman writes: >However, it would break the contract of any existing sessions to take >away or modify any capabilities each existing session already knows >about. Adding new capabilities mid-session is OK, but nothing else. >(Operationally, a way to override that rule is probably needed.) Sure, it's painful, but when a user removes a software module or a license key, the abilities of the device will change. It's unavoidable. The options are (a) announce it, or (b) nuke any previous client sessions. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Oct 30 19:14: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 F0D053A6938; Thu, 30 Oct 2008 19:14:27 -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 3F5603A6938 for ; Thu, 30 Oct 2008 19:14:27 -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 82RHtduJJWNJ for ; Thu, 30 Oct 2008 19:14:26 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 32F143A67CC for ; Thu, 30 Oct 2008 19:14:25 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m9V2EFd25323; Fri, 31 Oct 2008 02:14:16 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 22:14:14 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC730078@zcarhxm0.corp.nortel.com> In-Reply-To: <4909E0C4.4000202@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Are capabilities static or dynamic ? Thread-Index: Ack6rJ30OSuJRQcXS9OYwMn4zOVV9wASx2FQ References: <490788A1.9030602@ericsson.com> <20081029035424.GD2467@elstar.local> <49082CD8.6010102@ericsson.com> <238C6E77EA42504DA038BAEE6D1C11EC6DE08E@zcarhxm0.corp.nortel.com> <4909E0C4.4000202@netconfcentral.com> From: "Mark Scott" To: "Andy Bierman" Cc: netconf mailing list Subject: Re: [Netconf] Are capabilities static or dynamic ? 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 writes: > The subscription already has filters, so the notification content needs to be easily > filtered, which means more general fields than eventTime (like eventClass, eventSubClass, > and eventSeverity?) > I don't think "terse vs. detailed" is a good general filter though. > (eventDetailLevel?) I was thinking different eventClass (or subclass) but filtering would also work. The only potential differences I see between the two approaches are in the ability to support multiple eventDetailLevel (or different event detail level types) in the same subscription: With the filtering mechanism a client can only subscribe to one level of eventDetailLevel at the time for a given eventClass (ie. one value to match the filter). Unless filtering were to support multi-value match. Client can create multiple subscriptions though. With the different eventClass a client could subscribe to both terse and detailed events in the same subscription. > But you are describing an extension to the parameters, right? Or do > you mean the agent will generate two notifications for each event (terse and detailed) and > applications will know to filter one of them out? The client would only get what they subscribed to. cheers, mark _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Oct 30 19:14: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 F0D053A6938; Thu, 30 Oct 2008 19:14:27 -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 3F5603A6938 for ; Thu, 30 Oct 2008 19:14:27 -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 82RHtduJJWNJ for ; Thu, 30 Oct 2008 19:14:26 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 32F143A67CC for ; Thu, 30 Oct 2008 19:14:25 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m9V2EFd25323; Fri, 31 Oct 2008 02:14:16 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 22:14:14 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC730078@zcarhxm0.corp.nortel.com> In-Reply-To: <4909E0C4.4000202@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Are capabilities static or dynamic ? Thread-Index: Ack6rJ30OSuJRQcXS9OYwMn4zOVV9wASx2FQ References: <490788A1.9030602@ericsson.com> <20081029035424.GD2467@elstar.local> <49082CD8.6010102@ericsson.com> <238C6E77EA42504DA038BAEE6D1C11EC6DE08E@zcarhxm0.corp.nortel.com> <4909E0C4.4000202@netconfcentral.com> From: "Mark Scott" To: "Andy Bierman" Cc: netconf mailing list Subject: Re: [Netconf] Are capabilities static or dynamic ? 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 writes: > The subscription already has filters, so the notification content needs to be easily > filtered, which means more general fields than eventTime (like eventClass, eventSubClass, > and eventSeverity?) > I don't think "terse vs. detailed" is a good general filter though. > (eventDetailLevel?) I was thinking different eventClass (or subclass) but filtering would also work. The only potential differences I see between the two approaches are in the ability to support multiple eventDetailLevel (or different event detail level types) in the same subscription: With the filtering mechanism a client can only subscribe to one level of eventDetailLevel at the time for a given eventClass (ie. one value to match the filter). Unless filtering were to support multi-value match. Client can create multiple subscriptions though. With the different eventClass a client could subscribe to both terse and detailed events in the same subscription. > But you are describing an extension to the parameters, right? Or do > you mean the agent will generate two notifications for each event (terse and detailed) and > applications will know to filter one of them out? The client would only get what they subscribed to. cheers, mark _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Oct 31 08:54:45 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 D16D23A6C14; Fri, 31 Oct 2008 08:54:45 -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 167D33A6A8C for ; Fri, 31 Oct 2008 08:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.064, 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 sRrSQv99KlkP for ; Fri, 31 Oct 2008 08:54:42 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9A4E33A6979 for ; Fri, 31 Oct 2008 08:54:42 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C93A420FEA for ; Fri, 31 Oct 2008 16:53:31 +0100 (CET) X-AuditID: c1b4fb3c-ab0c8bb0000015b5-54-490b29fbff2b Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B137920E29 for ; Fri, 31 Oct 2008 16:53:31 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Oct 2008 16:53:31 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Oct 2008 16:53:31 +0100 Message-ID: <490B29FB.4080200@ericsson.com> Date: Fri, 31 Oct 2008 16:53:31 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf mailing list X-OriginalArrivalTime: 31 Oct 2008 15:53:31.0594 (UTC) FILETIME=[D2CF32A0:01C93B70] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] [Fwd: New Version Notification for draft-ietf-netconf-partial-lock-04] 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 Hello, I have submitted a new version of the draft. I believe we addressed all comments of the WG last call in this version. IMHO the draft is ready for IESG review, BUT please check that your comments are included! Thanks for all the comments. Balazs -------- Original Message -------- Subject: New Version Notification for draft-ietf-netconf-partial-lock-04 Date: Fri, 31 Oct 2008 08:48:39 -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-04.txt has been successfuly submitted by Balazs Lengyel and posted to the IETF repository. Filename: draft-ietf-netconf-partial-lock Revision: 04 Title: Partial Lock RPC for NETCONF Creation_date: 2008-10-29 WG ID: netconf Number_of_pages: 24 Abstract: The NETCONF protocol defines the lock and unlock RPCs, used to lock entire configuration datastores. In some siFrom netconf-bounces@ietf.org Fri Oct 31 08:54:45 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 D16D23A6C14; Fri, 31 Oct 2008 08:54:45 -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 167D33A6A8C for ; Fri, 31 Oct 2008 08:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.064, 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 sRrSQv99KlkP for ; Fri, 31 Oct 2008 08:54:42 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9A4E33A6979 for ; Fri, 31 Oct 2008 08:54:42 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C93A420FEA for ; Fri, 31 Oct 2008 16:53:31 +0100 (CET) X-AuditID: c1b4fb3c-ab0c8bb0000015b5-54-490b29fbff2b Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B137920E29 for ; Fri, 31 Oct 2008 16:53:31 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Oct 2008 16:53:31 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Oct 2008 16:53:31 +0100 Message-ID: <490B29FB.4080200@ericsson.com> Date: Fri, 31 Oct 2008 16:53:31 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf mailing list X-OriginalArrivalTime: 31 Oct 2008 15:53:31.0594 (UTC) FILETIME=[D2CF32A0:01C93B70] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] [Fwd: New Version Notification for draft-ietf-netconf-partial-lock-04] 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 Hello, I have submitted a new version of the draft. I believe we addressed all comments of the WG last call in this version. IMHO the draft is ready for IESG review, BUT please check that your comments are included! Thanks for all the comments. Balazs -------- Original Message -------- Subject: New Version Notification for draft-ietf-netconf-partial-lock-04 Date: Fri, 31 Oct 2008 08:48:39 -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-04.txt has been successfuly submitted by Balazs Lengyel and posted to the IETF repository. Filename: draft-ietf-netconf-partial-lock Revision: 04 Title: Partial Lock RPC for NETCONF Creation_date: 2008-10-29 WG ID: netconf Number_of_pages: 24 Abstract: The NETCONF protocol defines the lock and unlock RPCs, used to lock entire configuration datastores. In stuations, 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 ome 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 Oct 31 09:00: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 053513A6C2D; Fri, 31 Oct 2008 09:00: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 B69613A6C20; Fri, 31 Oct 2008 09: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: <20081031160001.B69613A6C20@core3.amsl.com> Date: Fri, 31 Oct 2008 09:00:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-partial-lock-04.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-04.txt Pages : 24 Date : 2008-10-31 The NETCONF protocol defines the lock and unlock RPCs, used to 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-04.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-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-31084839.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 Oct 31 09:00: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 053513A6C2D; Fri, 31 Oct 2008 09:00: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 B69613A6C20; Fri, 31 Oct 2008 09: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: <20081031160001.B69613A6C20@core3.amsl.com> Date: Fri, 31 Oct 2008 09:00:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-partial-lock-04.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-04.txt Pages : 24 Date : 2008-10-31 The NETCONF protocol defines the lock and unlock RPCs, used to 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-04.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-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-31084839.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--