From bertietf@bwijnen.net Sun Jan 3 12:16:19 2010 Return-Path: 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 6FCE43A6851 for ; Sun, 3 Jan 2010 12:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.357 X-Spam-Level: ** X-Spam-Status: No, score=2.357 tagged_above=-999 required=5 tests=[FH_DATE_PAST_20XX=10.357, RCVD_IN_DNSWL_HI=-8] 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 7CPRiFJSNxA0 for ; Sun, 3 Jan 2010 12:16:18 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 73F093A6935 for ; Sun, 3 Jan 2010 12:16:16 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NRWrq-00038V-PT; Sun, 03 Jan 2010 21:16:08 +0100 Received: from ayeaye.ripe.net (ayeaye.ripe.net [193.0.1.103]) by herring.ripe.net (Postfix) with ESMTP id BC8842F583; Sun, 3 Jan 2010 21:16:02 +0100 (CET) Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NRWrq-00029b-KJ; Sun, 03 Jan 2010 21:16:02 +0100 Message-ID: <4B40FB04.5050201@bwijnen.net> Date: Sun, 03 Jan 2010 21:16:04 +0100 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: netconf@ietf.org References: <200912281053.nBSAr5Bd012387@boreas.isi.edu> <20091228.134127.196030284.mbj@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd459d5f1f9ac87cb3e4bb82e1e2640c3a6 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd459d5f1f9ac87cb3e4bb82e1e2640c3a6 Subject: [Netconf] WG Concensus call: [Technical Errata Reported] RFC5717 (1978) 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: , X-List-Received-Date: Sun, 03 Jan 2010 20:16:19 -0000 I would think this is WG consensus. It seems pretty straight forward to me too. But I will give everyone a week (so till Jan 11th) to speak up if they disagree. Bert speaking as document-shepherd Romascanu, Dan (Dan) wrote: > I agree with the resolution as well. > > Is this the WG consensus? > > Dan > > > >> -----Original Message----- >> From: netconf-bounces@ietf.org >> [mailto:netconf-bounces@ietf.org] On Behalf Of Martin Bjorklund >> Sent: Monday, December 28, 2009 2:41 PM >> To: bertietf@bwijnen.net >> Cc: netconf@ietf.org >> Subject: Re: [Netconf] [Technical Errata Reported] RFC5717 (1978) >> >> "Bert Wijnen \(IETF\)" wrote: >> >>> Balzs and Martin, >>> >>> it seems to me that Alfred is correct in having found a problem. >>> It also seems that his suggested fix is correct. >>> >>> If you agree, pls confirm on our mailing list, and then we >>> >> (WG chairs) >> >>> will ask our AD to approve the errata and fix. >>> >> I agree, his suggested fix is correct. >> >> (The YANG description should be exactly the same as the XSD >> description as well...) >> >> >> /martin >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > > > From root@core3.amsl.com Thu Jan 7 16:45:01 2010 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 698223A67EF; Thu, 7 Jan 2010 16:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100108004501.698223A67EF@core3.amsl.com> Date: Thu, 7 Jan 2010 16:45:01 -0800 (PST) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-00.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: , X-List-Received-Date: Fri, 08 Jan 2010 00:45:01 -0000 --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 : Using the NETCONF Configuration Protocol over Secure Shell (SSH) Author(s) : M. Wasserman, T. Goddard Filename : draft-ietf-netconf-rfc4742bis-00.txt Pages : 10 Date : 2009-12-28 This document describes a method for invoking and running the NETCONF protocol within a Secure Shell (SSH) session as an SSH subsystem. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 1, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-rfc4742bis-00.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-rfc4742bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-07163044.I-D@ietf.org> --NextPart-- From bertietf@bwijnen.net Fri Jan 8 00:27:39 2010 Return-Path: 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 D00DA3A635F for ; Fri, 8 Jan 2010 00:27:39 -0800 (PST) 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 L5XvJFjNLfUE for ; Fri, 8 Jan 2010 00:27:38 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 69BD73A67E9 for ; Fri, 8 Jan 2010 00:27:37 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NTABi-0008Vs-SK for netconf@ietf.org; Fri, 08 Jan 2010 09:27:24 +0100 Received: from ayeaye.ripe.net (ayeaye.ripe.net [193.0.1.103]) by herring.ripe.net (Postfix) with ESMTP id D419A2F592 for ; Fri, 8 Jan 2010 09:27:18 +0100 (CET) Received: from dog.ripe.net ([193.0.1.217] helo=guest-76.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NTABi-0001iZ-PL for netconf@ietf.org; Fri, 08 Jan 2010 09:27:18 +0100 Message-ID: <4B46EC66.3010908@bwijnen.net> Date: Fri, 08 Jan 2010 09:27:18 +0100 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Netconf Content-Type: multipart/mixed; boundary="------------060600060302020309070405" X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd459aec5f3ddc8f22d436cd9e72ef3bcea X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd459aec5f3ddc8f22d436cd9e72ef3bcea Subject: [Netconf] [Fwd: I-D Action:draft-ietf-netconf-rfc4742bis-00.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: , X-List-Received-Date: Fri, 08 Jan 2010 08:27:39 -0000 This is a multi-part message in MIME format. --------------060600060302020309070405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit WG participants, pls review and comment on this initial version. Sooner is better than later. We as WG chairs will work with Dan to update our milestones as agreed at the last ietf (and confirmed n the mlist). Bert -------- Original Message -------- Subject: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-00.txt Date: Thu, 7 Jan 2010 16:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: netconf@ietf.org 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 : Using the NETCONF Configuration Protocol over Secure Shell (SSH) Author(s) : M. Wasserman, T. Goddard Filename : draft-ietf-netconf-rfc4742bis-00.txt Pages : 10 Date : 2009-12-28 This document describes a method for invoking and running the NETCONF protocol within a Secure Shell (SSH) session as an SSH subsystem. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 1, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-rfc4742bis-00.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. --------------060600060302020309070405 Content-Type: Message/External-body; name="draft-ietf-netconf-rfc4742bis-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-netconf-rfc4742bis-00.txt" Content-Type: text/plain Content-ID: <2010-01-07163044.I-D@ietf.org> --------------060600060302020309070405 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message Part" _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --------------060600060302020309070405-- From bertietf@bwijnen.net Mon Jan 11 02:14:33 2010 Return-Path: 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 021933A68F7 for ; Mon, 11 Jan 2010 02:14:32 -0800 (PST) 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 zHqZ+u0YEJ7Z for ; Mon, 11 Jan 2010 02:14:31 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id A3C8A3A69AC for ; Mon, 11 Jan 2010 02:14:30 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NUHHu-0003YN-Jv for netconf@ietf.org; Mon, 11 Jan 2010 11:14:24 +0100 Received: from ayeaye.ripe.net (ayeaye.ripe.net [193.0.1.103]) by herring.ripe.net (Postfix) with ESMTP id 947F62F583 for ; Mon, 11 Jan 2010 11:14:18 +0100 (CET) Received: from dog.ripe.net ([193.0.1.217] helo=guest-76.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NUHHu-0007a9-HG for netconf@ietf.org; Mon, 11 Jan 2010 11:14:18 +0100 Message-ID: <4B4AF9FA.8010801@bwijnen.net> Date: Mon, 11 Jan 2010 11:14:18 +0100 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: netconf Content-Type: multipart/mixed; boundary="------------080506070203040901030507" X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4c7e77b7b53cf63993535cb2ede7deb73 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4c7e77b7b53cf63993535cb2ede7deb73 Subject: [Netconf] Fwd: Network Automation 2010: Call for Proposals 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: , X-List-Received-Date: Mon, 11 Jan 2010 10:14:33 -0000 This is a multi-part message in MIME format. --------------080506070203040901030507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear WG participants, and specifically the implementers.... Simon pointed us to this call for proposals. We believe that (at least according to the title of the conference) can be relevant for some NETCONF implementers and so they might be interested to present or participate at this commercial event. So we're letting you know. In no way is this an endorsement of the event. Yust a FYI and so it is up to you to evaluate if you (or your company) wants to react. Bert and Mehmet ----------------- copy of the call for Proposals: Network Automation Paris 1st to 4th June, 2010 How to successfully reduce OPEX? Why is automation important for network operations? Why do Carriers expect a lot of progress from this issue? Will they save billion of dollars this way as stated in the arguments of equipment vendors? What are the main technical issues for achieving network automation? Responses will be given during the Network Automation conference to be held in Novotel Convention & Wellness Paris CDG from the 1st to 4th of June 2010. A call for proposals is online at: http://www.upperside.fr/networkautomation2010/networkautomation2010intro.htm If you don't want to receive emails regarding our events, please send us an email to: listmaster@upperside.fr --------------080506070203040901030507 Content-Type: message/rfc822; name="ForwardedMessage.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ForwardedMessage.eml" CONTENT-TRANSFER-ENCODING: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Return-path: Delivery-date: Tue, 22 Dec 2009 15:48:16 +0100 Received: from [2001:620:0:1b:203:baff:febe:9059] (helo=aletsch.switch.ch) by kesch.switch.ch with esmtp (Exim 4.69) (envelope-from ) id 1NN623-0002be-V6 for simon.leinen@switch.ch; Tue, 22 Dec 2009 15:48:15 +0100 Received: from [130.59.138.42] (helo=lagalb.switch.ch) by aletsch.switch.ch with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NN623-0005DS-Q3 for simon.leinen@switch.ch; Tue, 22 Dec 2009 15:48:15 +0100 Received: from [130.59.138.26] (helo=aletsch.switch.ch) by lagalb.switch.ch with esmtp (Exim 4.69) (envelope-from ) id 1NN61x-0007KI-Al for simon.leinen@switch.ch; Tue, 22 Dec 2009 15:48:09 +0100 Received: from [80.12.242.152] (helo=smtp2f.orange.fr) by aletsch.switch.ch with esmtp (Exim 4.69) (envelope-from ) id 1NN61w-00058z-Vb for leinen@switch.ch; Tue, 22 Dec 2009 15:48:09 +0100 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2f18.orange.fr (SMTP Server) with ESMTP id 1DCDB8000A78 for ; Tue, 22 Dec 2009 15:48:08 +0100 (CET) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2f18.orange.fr (SMTP Server) with ESMTP id 11DDE8000B50 for ; Tue, 22 Dec 2009 15:48:08 +0100 (CET) Received: from DK-BUREAU-VST.smtp.orange.fr (LRouen-151-72-18-204.w80-13.abo.wanadoo.fr [80.13.177.204]) by mwinf2f18.orange.fr (SMTP Server) with SMTP id C801C8000A78 for ; Tue, 22 Dec 2009 15:48:07 +0100 (CET) X-ME-UUID: 20091222144807819.C801C8000A78@mwinf2f18.orange.fr Message-ID: Reply-To: "info" X-Mailer: US Network Auto_1_221209 X-Priority: 3 X-SWITCH-SIGNATURE: ddfdcb335899d57c4354ebf665e8c9fc X-SWITCH-MailScanner: Found to be clean X-SWITCH-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.499, required 0, BAYES_00 -2.60, RDNS_NONE 0.10) X-SWITCH-SCANNER: scanned From: Upperside Conferences To: Subject: Network Automation 2010: Call for Proposals! Date: Tue, 22 Dec 2009 15:58:54 +0100 Network Automation=20 Paris 1st to 4th June, 2010 =20 How to successfully reduce OPEX=3F =20 Why is automation important for network operations=3F=20 Why do Carriers expect a lot of progress from this issue=3F Will they save billion of dollars this way as stated in the arguments o= f equipment vendors=3F What are the main technical issues for achieving network automation=3F Responses will be given during the Network Automation conference to be = held in Novotel Convention & Wellness Paris CDG from the 1st to 4th of = June 2010.=20 =20 A call for proposals is online at: http://www.upperside.fr/networkautom= ation2010/networkautomation2010intro.htm If you don't want to receive emails regarding our events, please send u= s an email to: listmaster@upperside.fr --------------080506070203040901030507-- From bertietf@bwijnen.net Mon Jan 11 05:09:18 2010 Return-Path: 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 9CDBC3A69DF for ; Mon, 11 Jan 2010 05:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 zhikDBezoHI7 for ; Mon, 11 Jan 2010 05:09:17 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 4A37D3A67AF for ; Mon, 11 Jan 2010 05:09:16 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NUK15-0004F8-9C for netconf@ietf.org; Mon, 11 Jan 2010 14:09:13 +0100 Received: from ayeaye.ripe.net (ayeaye.ripe.net [193.0.1.103]) by herring.ripe.net (Postfix) with ESMTP id 4218A2F59A for ; Mon, 11 Jan 2010 14:09:07 +0100 (CET) Received: from dog.ripe.net ([193.0.1.217] helo=guest-76.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NUK14-0001uZ-VZ for netconf@ietf.org; Mon, 11 Jan 2010 14:09:07 +0100 Message-ID: <4B4B22F2.3010605@bwijnen.net> Date: Mon, 11 Jan 2010 14:09:06 +0100 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4cc37090990f0ae161434b8e3ad3d7364 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4cc37090990f0ae161434b8e3ad3d7364 Subject: [Netconf] Fwd: Milestone updates for the NETCONF-WG 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: , X-List-Received-Date: Mon, 11 Jan 2010 13:09:18 -0000 FYI, We have updated our milstons. Some were long ovedue. They still are I guess, but we have tagged them with dates that are in the future. Let us try to meet them now! Bert and Mehmet -------- Original Message -------- Subject: RE: [Fwd: Milestone updates for the NETCONF-WG] Date: Mon, 11 Jan 2010 13:46:33 +0100 From: Romascanu, Dan (Dan) To: Bert Wijnen , CC: Ron Bonica , Ersue, Mehmet (NSN - DE/Munich) References: <4B4B1C0E.2020305@ripe.net> Approved by AD. Dan > -----Original Message----- > From: Bert Wijnen [mailto:bwijnen@ripe.net] > Sent: Monday, January 11, 2010 2:40 PM > To: iesg-secretary@ietf.org > Cc: Romascanu, Dan (Dan); Ron Bonica; Ersue, Mehmet (NSN - DE/Munich) > Subject: [Fwd: Milestone updates for the NETCONF-WG] > > > Hi, > > can you please record the following milestone updates for the > NETCONF WG. I guess Dan needs to approve this. > > 1. Mark these 4 milestones as DONE > Dec 2008 - WG Last Call on Fine Grain Locking after IETF72 > Dec 2008 - Send Partial Locking to IESG for consideration > as Proposed Standards > Jan 2009 - Initial WG draft for with-defaults capability > Feb 2009 - Initial WG draft for rfc4741bis > Mar 2009 - WG Last Call on NETCONF Monitoring after IETF73 > > 2. Add these new milestones. They are already covered as work items > in the WG charter, but they did not have a milestone yet: > > DONE - submit first WG draft for rfc4742bis > 1Q 2010 - Send NETCONF monitoring to IESG for approval > as Proposed Standard > 1Q 2010 - WG Last Call for rfc4742bis > 2Q 2010 - Send rfc4742bis to IESG for consideration as > proposed standard. > > 3. Updated milestones for these: > > Apr 2009 - WG Last Call on rfc4741bis > Apr 2009 - WG Last Call on with-defaults > Jun 2009 - rfc4741bis to IESG for considerations as > Proposed Standard > Jun 2009 - with-defaults capability to IESG for > considerations as Proposed Standard > > They change into: > > 1Q 2010 - WG Last Call on rfc4741bis > 1Q 2010 - WG Last Call on with-defaults > 2Q 2010 - rfc4741bis to IESG for considerations as > Proposed Standard > 2Q 2010 - with-defaults capability to IESG for > considerations as Proposed Standard > > > So the complete list of charter milestones should then look > as follows: > Done Working Group formed > Done Submit initial Netconf Protocol draft > Done Submit initial Netconf over (transport-TBD) draft > Done Begin Working Group Last Call for the Netconf > Protocol draft > Done Begin Working Group Last Call for the Netconf > over (transport-TBD) draft > Done Submit final version of the Netconf Protocol > draft to the IESG > Done Submit final version of the Netconf over SOAP > draft to the IESG > Done Submit final version of the Netconf over BEEP > draft to the IESG > Done Submit final version of the Netconf over SSH > draft to the IESG > Done Update charter > Done Submit first version of NETCONF Notifications document > Done Begin WGLC of NETCONF Notifications document > Done Submit final version of NETCONF Notifications document > to IESG for consideration as Proposed Standard > Done -00 draft for NETCONF Monitoring > Done -00 draft for Fine Grain Locking > Done -00 draft for NETCONF over TLS > Done -00 draft for Schema Advertisement > Done Early Review of client authentication approach (for > NETCONF over TLS) with the security > community at IETF 71 > Done WG Last Call on NETCONF Monitoring after IETF72 > Done WG Last Call on NETCONF over TLS after IETF72 > DONE - WG Last Call on Fine Grain Locking after IETF72 > DONE - Send Partial Locking to IESG for consideration > as Proposed Standards > DONE - Initial WG draft for with-defaults capability > DONE - Initial WG draft for rfc4741bis > DONE - WG Last Call on NETCONF Monitoring after IETF73 > DONE - submit first WG draft for rfc4742bis > 1Q 2010 - Send NETCONF monitoring to IESG for approval > as Proposed Standard > 1Q 2010 - WG Last Call for rfc4742bis > 2Q 2010 - Send rfc4742bis to IESG for consideration as > proposed standard. > 1Q 2010 - WG Last Call on rfc4741bis > 1Q 2010 - WG Last Call on with-defaults > 2Q 2010 - rfc4741bis to IESG for considerations as > Proposed Standard > 2Q 2010 - with-defaults capability to IESG for > considerations as Proposed Standard > > > Thanks, > > Bert and Mehmet > > From andyb@iwl.com Tue Jan 12 09:32:49 2010 Return-Path: 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 3D70C3A692C for ; Tue, 12 Jan 2010 09:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.439, 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 ns9vCdnFWLSm for ; Tue, 12 Jan 2010 09:32:48 -0800 (PST) Received: from smtp194.dfw.emailsrvr.com (smtp194.dfw.emailsrvr.com [67.192.241.194]) by core3.amsl.com (Postfix) with ESMTP id 34FDF3A67AB for ; Tue, 12 Jan 2010 09:32:45 -0800 (PST) Received: from relay9.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 47EE013D364E; Tue, 12 Jan 2010 12:32:41 -0500 (EST) Received: by relay9.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 01D7E13D3646; Tue, 12 Jan 2010 12:32:40 -0500 (EST) Message-ID: <4B4CB232.9090003@iwl.com> Date: Tue, 12 Jan 2010 09:32:34 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B1EC950.2010408@netconfcentral.com> <20091209.221452.236221846.mbj@tail-f.com> In-Reply-To: <20091209.221452.236221846.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis, issue 14, capabilities changed error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 17:32:49 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: ... > This is why I proposed the following text in > http://www.ietf.org/mail-archive/web/netconf/current/msg04512.html: > > The capabilities of a NETCONF server may change over time. However, > once a NETCONF server has announced its capabilities in the > message, the capabilities for that session MUST NOT change. A > server MUST reply with a 'capabilities-changed' error if the client > sends a request which is affected by a modified capability. > > And maybe add: > > A server MAY choose to send 'capabilities-changed' as the response > to any request other than if its capabilities has > changed. > > > Provided that 'capabilities-changed' is an error-app-tag, this is > backwards compatible. > > If we want to create a new fancy mechanism to resync modified > capabilities, I agree we can do that in netconf 1.1. > > We need to close all these 4741 open issues. This is the last one (because a new confirmed-commit capability is punted to another release). My concern is the 2nd sentence (MUST NOT change). Here are some use-cases where this is not a feature: 1) load module command A server may support run-time loading of a YANG module and its corresponding instrumentation. The 'MUST not change' CLR makes it impossible for a NETCONF session to change the system capabilities. 2) preserved session utility It is impossible to preserve every open session's particular view of the system. It is also misleading, and may cause the operator to do incorrect things, or be limited to some un-discoverable vendor-specific set of operations. 3) plug in a new HW module The addition of more ports, or an redundant power supply is not enough reason to disrupt all the NETCONF sessions. This is normal operation. The standard SNMP approach to this problem seems to be the best choice here as well -- take steps to inform the client that things have changed, but do not disrupt any management operations. It would be trivial to add another leaf to the ietf-netconf-monitoring module: leaf capability-last-changed-time { description "Contains the date and time that the capabilities of the NETCONF server were last changed."; type yang:date-and-time; mandatory true; config false; } A notification should also be added. This might take longer to complete than a time-stamp, so it may have to wait. This is the one I am using: http://www.netconfcentral.org/modules/yuma-system/2009-12-27#sysCapabilityChange.244 IMO, it is the client's problem to deal with a dynamic system, not the server's problem to pretend the system is static. I still don't know what text to add to 4741bis, so I think I will punt this issue to the March meeting, unless any good suggestions show up on the mailing list. > /martin Andy From mbj@tail-f.com Tue Jan 12 13:46:15 2010 Return-Path: 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 5633D3A690C for ; Tue, 12 Jan 2010 13:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=0.222, 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 vItfkL6JsiyY for ; Tue, 12 Jan 2010 13:46:14 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 302453A690A for ; Tue, 12 Jan 2010 13:46:14 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 6CDA5616009; Tue, 12 Jan 2010 22:46:10 +0100 (CET) Date: Tue, 12 Jan 2010 22:46:09 +0100 (CET) Message-Id: <20100112.224609.176007266.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4B4CB232.9090003@iwl.com> References: <4B1EC950.2010408@netconfcentral.com> <20091209.221452.236221846.mbj@tail-f.com> <4B4CB232.9090003@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis, issue 14, capabilities changed 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: , X-List-Received-Date: Tue, 12 Jan 2010 21:46:15 -0000 Hi, Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > ... > > This is why I proposed the following text in > > http://www.ietf.org/mail-archive/web/netconf/current/msg04512.html: > > > > The capabilities of a NETCONF server may change over time. However, > > once a NETCONF server has announced its capabilities in the > > message, the capabilities for that session MUST NOT change. A > > server MUST reply with a 'capabilities-changed' error if the client > > sends a request which is affected by a modified capability. > > > > And maybe add: > > > > A server MAY choose to send 'capabilities-changed' as the response > > to any request other than if its capabilities has > > changed. > > > > > > Provided that 'capabilities-changed' is an error-app-tag, this is > > backwards compatible. > > > > If we want to create a new fancy mechanism to resync modified > > capabilities, I agree we can do that in netconf 1.1. > > > > > > > We need to close all these 4741 open issues. > This is the last one (because a new confirmed-commit > capability is punted to another release). There are a few other open issues as well. And why is a new confirmed-commit capability punted to another release? IMO the current one is broken and needs to be fixed. But that's a separate thread! > My concern is the 2nd sentence (MUST NOT change). > > Here are some use-cases where this is not a feature: > > 1) load module command > A server may support run-time loading of a YANG module > and its corresponding instrumentation. The 'MUST not change' > CLR makes it impossible for a NETCONF session to change the > system capabilities. Yes, a NETCONF session can change the system capabilities, as long as the current session is not affected. > 2) preserved session utility > It is impossible to preserve every open session's particular > view of the system. It is also misleading, and may cause the > operator to do incorrect things, or be limited to some > un-discoverable vendor-specific set of operations. That's why a server can send the 'capabilities-changed' error for any request on open sessions. > 3) plug in a new HW module > The addition of more ports, or an redundant power supply > is not enough reason to disrupt all the NETCONF sessions. > This is normal operation. Do you agree that if capabilities change, the client needs to somehow be informed, and it needs to get a chance to resync? There are a couple of alternatives: 1. As proposed; send an error, and let the client resync by opening a new session (can be handled by opening a new channel and closing the old one; this is almost as cheap and easy as having an explicit 'resync-capabilites' rpc.) 2. Send an error as above, plus add a new 'resync-capabilites' rpc. Until the session has done resync, it will get the error as in option 1. 3. Send an error as above, and resync with a notification? The problem with this approach has been discussed before - the client needs two sessions, one for the notification and one for rpcs. And it needs to sync between the two. > The standard SNMP approach to this problem seems to > be the best choice here as well -- take steps to inform > the client that things have changed, but do not disrupt > any management operations. With NETCONF and YANG, we have a number of mechanisms to let the client learn what the server can do, so it does not have to do trial and error. The capability list is the contract between the server and client. If the contract can change in random ways at any time, it is worthless. I think option 1 above is simple, and good enough. Option 2 should work, but adds a new rpc, which means a new capability. If it is covered by our charter and the WG think it is necessary, fine. /martin From andyb@iwl.com Tue Jan 12 14:26:58 2010 Return-Path: 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 0E6143A68E0 for ; Tue, 12 Jan 2010 14:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.858 X-Spam-Level: X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[AWL=0.407, 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 oNcHoIzw30Wm for ; Tue, 12 Jan 2010 14:26:57 -0800 (PST) Received: from smtp164.dfw.emailsrvr.com (smtp164.dfw.emailsrvr.com [67.192.241.164]) by core3.amsl.com (Postfix) with ESMTP id EBC0C3A68DD for ; Tue, 12 Jan 2010 14:26:56 -0800 (PST) Received: from relay6.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay6.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 0FA7C30206; Tue, 12 Jan 2010 17:26:54 -0500 (EST) Received: by relay6.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id AB4403011D; Tue, 12 Jan 2010 17:26:53 -0500 (EST) Message-ID: <4B4CF726.7050200@iwl.com> Date: Tue, 12 Jan 2010 14:26:46 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B1EC950.2010408@netconfcentral.com> <20091209.221452.236221846.mbj@tail-f.com> <4B4CB232.9090003@iwl.com> <20100112.224609.176007266.mbj@tail-f.com> In-Reply-To: <20100112.224609.176007266.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis, issue 14, capabilities changed error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 22:26:58 -0000 Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >> ... >>> This is why I proposed the following text in >>> http://www.ietf.org/mail-archive/web/netconf/current/msg04512.html: >>> >>> The capabilities of a NETCONF server may change over time. However, >>> once a NETCONF server has announced its capabilities in the >>> message, the capabilities for that session MUST NOT change. A >>> server MUST reply with a 'capabilities-changed' error if the client >>> sends a request which is affected by a modified capability. >>> >>> And maybe add: >>> >>> A server MAY choose to send 'capabilities-changed' as the response >>> to any request other than if its capabilities has >>> changed. >>> >>> >>> Provided that 'capabilities-changed' is an error-app-tag, this is >>> backwards compatible. >>> >>> If we want to create a new fancy mechanism to resync modified >>> capabilities, I agree we can do that in netconf 1.1. >>> >>> >> >> We need to close all these 4741 open issues. >> This is the last one (because a new confirmed-commit >> capability is punted to another release). > > There are a few other open issues as well. And why is a new > confirmed-commit capability punted to another release? IMO the > current one is broken and needs to be fixed. But that's a separate > thread! > There was not much interest in changing the commit operation in this document. I would not say it is broken. The limitations were understood at the time it was published. >> My concern is the 2nd sentence (MUST NOT change). >> >> Here are some use-cases where this is not a feature: >> >> 1) load module command >> A server may support run-time loading of a YANG module >> and its corresponding instrumentation. The 'MUST not change' >> CLR makes it impossible for a NETCONF session to change the >> system capabilities. > > Yes, a NETCONF session can change the system capabilities, as long as > the current session is not affected. That is impossible for the server to do. Besides, if I load the 'foo' module, it's because I want to start using it. We have a major disconnect between the protocol and reality. The capabilities represent the system capabilities at the time the session was started. It makes no sense at all to talk about freezing them for some server. If the operator removes a redundant power supply, there is no way the server is going to 'fake it' for all the NETCONF sessions that are open. The capabilities can change over time. > >> 2) preserved session utility >> It is impossible to preserve every open session's particular >> view of the system. It is also misleading, and may cause the >> operator to do incorrect things, or be limited to some >> un-discoverable vendor-specific set of operations. > > That's why a server can send the 'capabilities-changed' error for any > request on open sessions. The server could send a capabilities-changed notification and set the time-stamp. This gives the client to figure out what changed and if it matters to that session. > >> 3) plug in a new HW module >> The addition of more ports, or an redundant power supply >> is not enough reason to disrupt all the NETCONF sessions. >> This is normal operation. > > Do you agree that if capabilities change, the client needs to somehow > be informed, and it needs to get a chance to resync? There are a > couple of alternatives: The client needs to poll for changes or listen for notifications. > > 1. As proposed; send an error, and let the client resync by opening > a new session (can be handled by opening a new channel and > closing the old one; this is almost as cheap and easy as having > an explicit 'resync-capabilites' rpc.) > but what is the error exactly? "hey client, you may be doing something wrong! not such if and what it is, but time to end the session." IMO, the server should not assume the client is clueless and will break. The server should just execute the requests, in order. If the capabilities change, and the redundant power supply is gone, then data-model specific content may be affected like the RPC above. If the client tries to use this RPC, then the server can send a definitive error because the hardware is not available. The client can poll for changes, and realize not to try this operation, or just try it and get an error. I don't see any reason to force one way or the other. > 2. Send an error as above, plus add a new 'resync-capabilites' > rpc. Until the session has done resync, it will get the error > as in option 1. > > 3. Send an error as above, and resync with a notification? The > problem with this approach has been discussed before - the > client needs two sessions, one for the notification and one for > rpcs. And it needs to sync between the two. > 4. set a last-changed time-stamp and send a notification. >> The standard SNMP approach to this problem seems to >> be the best choice here as well -- take steps to inform >> the client that things have changed, but do not disrupt >> any management operations. > > With NETCONF and YANG, we have a number of mechanisms to let the > client learn what the server can do, so it does not have to do trial > and error. The capability list is the contract between the server and > client. If the contract can change in random ways at any time, it is > worthless. This notion that the system capabilities at the time the session starts is a static contract is fatally flawed because not all capabilities are the same. They are just generic markers. The contract that says "I implement the RFC 4741 version of NETCONF" is the only one that cannot really change. Adding a module or changing the HW configuration are not capability contracts. They are merely the set of dynamic capabilities at the current time. > > I think option 1 above is simple, and good enough. Option 2 should > work, but adds a new rpc, which means a new capability. If it is > covered by our charter and the WG think it is necessary, fine. > NMS applications are used to 'directed polling' for system changes (notification + polling 'change-marker MIB objects'). We have notifications and a operation, so there is no reason to invent new mechanisms. > > /martin > Andy From mbj@tail-f.com Tue Jan 12 14:53:19 2010 Return-Path: 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 CECD83A6889 for ; Tue, 12 Jan 2010 14:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.839 X-Spam-Level: X-Spam-Status: No, score=-1.839 tagged_above=-999 required=5 tests=[AWL=0.207, 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 jPPuwxeHy34R for ; Tue, 12 Jan 2010 14:53:19 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0E6863A6877 for ; Tue, 12 Jan 2010 14:53:18 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 58976616008; Tue, 12 Jan 2010 23:53:15 +0100 (CET) Date: Tue, 12 Jan 2010 23:53:14 +0100 (CET) Message-Id: <20100112.235314.145115292.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4B4CF726.7050200@iwl.com> References: <4B4CB232.9090003@iwl.com> <20100112.224609.176007266.mbj@tail-f.com> <4B4CF726.7050200@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis, issue 14, capabilities changed 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: , X-List-Received-Date: Tue, 12 Jan 2010 22:53:19 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Do you agree that if capabilities change, the client needs to somehow > > be informed, and it needs to get a chance to resync? There are a > > couple of alternatives: > > The client needs to poll for changes or listen > for notifications. So you do not agree with what I wrote. Does this means that you view the capabilities list not as a contract, but more as a hint for the client? I strongly object to such an interpretation. Why bother at all with keeping track of capabilities if they may change at any time, at any rate, in any way? /martin From andyb@iwl.com Tue Jan 12 15:10:39 2010 Return-Path: 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 778C73A6862 for ; Tue, 12 Jan 2010 15:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=0.380, 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 HdK-mnQfkh6C for ; Tue, 12 Jan 2010 15:10:38 -0800 (PST) Received: from smtp194.dfw.emailsrvr.com (smtp194.dfw.emailsrvr.com [67.192.241.194]) by core3.amsl.com (Postfix) with ESMTP id 5FB913A67F3 for ; Tue, 12 Jan 2010 15:10:38 -0800 (PST) Received: from relay19.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay19.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 6E90527485A5; Tue, 12 Jan 2010 18:10:35 -0500 (EST) Received: by relay19.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 310532748322; Tue, 12 Jan 2010 18:10:35 -0500 (EST) Message-ID: <4B4D0164.4090202@iwl.com> Date: Tue, 12 Jan 2010 15:10:28 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B4CB232.9090003@iwl.com> <20100112.224609.176007266.mbj@tail-f.com> <4B4CF726.7050200@iwl.com> <20100112.235314.145115292.mbj@tail-f.com> In-Reply-To: <20100112.235314.145115292.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis, issue 14, capabilities changed error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 23:10:39 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Do you agree that if capabilities change, the client needs to somehow >>> be informed, and it needs to get a chance to resync? There are a >>> couple of alternatives: >> The client needs to poll for changes or listen >> for notifications. > > So you do not agree with what I wrote. Does this means that you view > the capabilities list not as a contract, but more as a hint for the > client? > > I strongly object to such an interpretation. Why bother at all with > keeping track of capabilities if they may change at any time, at any > rate, in any way? > I think the capabilities need refinement in order to assume a particular capability change breaks the current session. If the client is receiving notifications, then just sending a capability-change event is good enough. The RPC and capabilities-changes error stuff is overkill. I think it is up to the client to decide if the session is usable after a particular capability change. We can say that the base-NETCONF capability MUST NOT change during a session. I don't see any others that represent contracts -- they represent current configuration settings or current system hardware state. If we had a capability-stmt in YANG (like I wanted ;-) then we could have a static vs. dynamic property, and an allowed-to-change vs. must-not-change property. Without that, I do not agree the server MUST do anything wrt/ a capability change. It is data model dependent. > > > /martin > Andy From j.schoenwaelder@jacobs-university.de Wed Jan 13 00:37:06 2010 Return-Path: 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 32C7A3A685A for ; Wed, 13 Jan 2010 00:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[AWL=0.241, 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 UPG0pzYHTpzX for ; Wed, 13 Jan 2010 00:37:05 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 18EA83A67D7 for ; Wed, 13 Jan 2010 00:37:05 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 333DCC0044 for ; Wed, 13 Jan 2010 09:37:02 +0100 (CET) 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 wV1S6eojZSGg; Wed, 13 Jan 2010 09:37:01 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 409F7C002F; Wed, 13 Jan 2010 09:37:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BC49EFCA498; Wed, 13 Jan 2010 09:36:54 +0100 (CET) Date: Wed, 13 Jan 2010 09:36:54 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20100113083654.GA34549@elstar.local> Mail-Followup-To: netconf@ietf.org References: <4B4CB232.9090003@iwl.com> <20100112.224609.176007266.mbj@tail-f.com> <4B4CF726.7050200@iwl.com> <20100112.235314.145115292.mbj@tail-f.com> <4B4D0164.4090202@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B4D0164.4090202@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Netconf] 4741bis, issue 14, capabilities changed error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 08:37:06 -0000 [...] I am in favour of adding an rpc called hello, a client initiated version of the initial hello exchange before the RPC protocol is started. rpc hello { input { container capabilities { leaf-list capability { type inet:uri; } } } output { container capabilities { leaf-list capability { type inet:uri; } } leaf session-id { type session-id-type; } } } This hello RPC allows a client to resync capabilities, also covering the case where client capabilities might have changed dynamically or where the client lost (for whatever reason) the capabilities announced at the beginning of the session. With this hello RPC in place, all we need is a mechanism to let the server notify clients that capabilities have changed. (And I agree with the remark I think by Andy that it is the client which should take a decision whether it is affected by capability change). - If there is a NETCONF notification channel, all that is needed is a notification, like Andy suggested. - So the remaining case is where the client does not listen to NETCONF notifications. One proposed conservative approach is to fail RPCs until the hello RPC has been executed to resynchronize. Another option is to allow further messages between messages - I have not checked whether there is text in 4741 disallowing this. The third option is to wait until we have a working mechanism to send warnings, means NETCONF 1.1. At this point in time, I would be in favour of (a) adding the hello RPC outlined above and (b) adding text discussing the issue and stating that server implementations MAY send capability-changed errors if capabilities have changed and there is no other mechanism to notify the client about the capability change. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andyb@iwl.com Wed Jan 13 01:02:01 2010 Return-Path: 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 5AABF3A6970 for ; Wed, 13 Jan 2010 01:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GY1Pb5AVKqUS for ; Wed, 13 Jan 2010 01:02:00 -0800 (PST) Received: from smtp184.iad.emailsrvr.com (smtp184.iad.emailsrvr.com [207.97.245.184]) by core3.amsl.com (Postfix) with ESMTP id 70AC73A685A for ; Wed, 13 Jan 2010 01:02:00 -0800 (PST) Received: from relay28.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay28.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id AEC8D1B416E for ; Wed, 13 Jan 2010 04:01:57 -0500 (EST) Received: by relay28.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 7A2791B4164 for ; Wed, 13 Jan 2010 04:01:57 -0500 (EST) Message-ID: <4B4D8BFE.1000907@iwl.com> Date: Wed, 13 Jan 2010 01:01:50 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: netconf@ietf.org References: <4B4CB232.9090003@iwl.com> <20100112.224609.176007266.mbj@tail-f.com> <4B4CF726.7050200@iwl.com> <20100112.235314.145115292.mbj@tail-f.com> <4B4D0164.4090202@iwl.com> <20100113083654.GA34549@elstar.local> In-Reply-To: <20100113083654.GA34549@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] 4741bis, issue 14, capabilities changed error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 09:02:01 -0000 Juergen Schoenwaelder wrote: > [...] > > I am in favour of adding an rpc called hello, a client initiated > version of the initial hello exchange before the RPC protocol is > started. > > rpc hello { > input { > container capabilities { > leaf-list capability { > type inet:uri; > } > } > } > output { > container capabilities { > leaf-list capability { > type inet:uri; > } > } > leaf session-id { > type session-id-type; > } > } > } > > This hello RPC allows a client to resync capabilities, also covering > the case where client capabilities might have changed dynamically or > where the client lost (for whatever reason) the capabilities announced > at the beginning of the session. > > With this hello RPC in place, all we need is a mechanism to let the > server notify clients that capabilities have changed. (And I agree > with the remark I think by Andy that it is the client which should > take a decision whether it is affected by capability change). > > - If there is a NETCONF notification channel, all that is needed is a > notification, like Andy suggested. > > - So the remaining case is where the client does not listen to NETCONF > notifications. One proposed conservative approach is to fail RPCs > until the hello RPC has been executed to resynchronize. Another > option is to allow further messages between > messages - I have not checked whether there is text in 4741 > disallowing this. The third option is to wait until we have a > working mechanism to send warnings, means NETCONF 1.1. > > At this point in time, I would be in favour of (a) adding the hello > RPC outlined above and (b) adding text discussing the issue and > stating that server implementations MAY send capability-changed errors > if capabilities have changed and there is no other mechanism to notify > the client about the capability change. > We already have the capabilities in the monitoring module. All that is missing is a last-changed timestamp to make retrieval of the capabilities more efficient. How many different optional mechanisms can one add, each time claiming an N+1th optional mechanism is needed because all N existing solutions are optional? > /js > Andy From j.schoenwaelder@jacobs-university.de Wed Jan 13 01:15:28 2010 Return-Path: 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 9692B3A6A9B for ; Wed, 13 Jan 2010 01:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=0.231, 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 KpFceRrJh3fd for ; Wed, 13 Jan 2010 01:15:27 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 87F5B3A6A7B for ; Wed, 13 Jan 2010 01:15:27 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0C5C1C0028; Wed, 13 Jan 2010 10:15:25 +0100 (CET) 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 cV57489po97x; Wed, 13 Jan 2010 10:15:24 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 29131C0003; Wed, 13 Jan 2010 10:15:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9A57AFCA702; Wed, 13 Jan 2010 10:15:17 +0100 (CET) Date: Wed, 13 Jan 2010 10:15:17 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100113091517.GC34664@elstar.local> Mail-Followup-To: Andy Bierman , "netconf@ietf.org" References: <4B4CB232.9090003@iwl.com> <20100112.224609.176007266.mbj@tail-f.com> <4B4CF726.7050200@iwl.com> <20100112.235314.145115292.mbj@tail-f.com> <4B4D0164.4090202@iwl.com> <20100113083654.GA34549@elstar.local> <4B4D8BFE.1000907@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B4D8BFE.1000907@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] 4741bis, issue 14, capabilities changed error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 09:15:28 -0000 On Wed, Jan 13, 2010 at 10:01:50AM +0100, Andy Bierman wrote: > We already have the capabilities in the monitoring module. > All that is missing is a last-changed timestamp to make > retrieval of the capabilities more efficient. The proposed RPC is not equivalent to a on the monitoring module since it also passes the client capabilities to the server, which I am sure at some point we will find valuable to have. I believe wrapping the initial exchange into an RPC is a very clean and straight forward solution for client initiated synchronization of capabilities. /js PS: I am not a big fan of a polling solution for detecting capability changes. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andyb@iwl.com Wed Jan 13 01:44:59 2010 Return-Path: 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 6D7993A67A3 for ; Wed, 13 Jan 2010 01:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.356, 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 hAa2l-vrqEh8 for ; Wed, 13 Jan 2010 01:44:58 -0800 (PST) Received: from smtp194.dfw.emailsrvr.com (smtp194.dfw.emailsrvr.com [67.192.241.194]) by core3.amsl.com (Postfix) with ESMTP id 64C263A6AA0 for ; Wed, 13 Jan 2010 01:44:52 -0800 (PST) Received: from relay9.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id DF3B613D354F for ; Wed, 13 Jan 2010 04:44:49 -0500 (EST) Received: by relay9.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id B4B2B13D3263 for ; Wed, 13 Jan 2010 04:44:49 -0500 (EST) Message-ID: <4B4D960A.1070800@iwl.com> Date: Wed, 13 Jan 2010 01:44:42 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "netconf@ietf.org" References: <4B4CB232.9090003@iwl.com> <20100112.224609.176007266.mbj@tail-f.com> <4B4CF726.7050200@iwl.com> <20100112.235314.145115292.mbj@tail-f.com> <4B4D0164.4090202@iwl.com> <20100113083654.GA34549@elstar.local> <4B4D8BFE.1000907@iwl.com> <20100113091517.GC34664@elstar.local> In-Reply-To: <20100113091517.GC34664@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] 4741bis, issue 14, capabilities changed error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 09:44:59 -0000 Juergen Schoenwaelder wrote: > On Wed, Jan 13, 2010 at 10:01:50AM +0100, Andy Bierman wrote: > >> We already have the capabilities in the monitoring module. >> All that is missing is a last-changed timestamp to make >> retrieval of the capabilities more efficient. > > The proposed RPC is not equivalent to a on the > monitoring module since it also passes the client capabilities to the > server, which I am sure at some point we will find valuable to have. > I believe wrapping the initial exchange into an RPC is a very > clean and straight forward solution for client initiated synchronization > of capabilities. > > /js > > PS: I am not a big fan of a polling solution for detecting capability > changes. > There is no requirement now for the server to save the client capabilities. The client can remember what it sent in its . The current obviously has just the server capabilities, so this will add code to clients, to deal with a new type of message. So how does a client know it needs to call the RPC? It seems to me you are replacing a poll with a poll. Andy From j.schoenwaelder@jacobs-university.de Wed Jan 13 01:51:22 2010 Return-Path: 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 00D673A68B2 for ; Wed, 13 Jan 2010 01:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=0.221, 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 A9PnlOg3+Con for ; Wed, 13 Jan 2010 01:51:21 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EFF0C3A6895 for ; Wed, 13 Jan 2010 01:51:20 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7BD34C002F; Wed, 13 Jan 2010 10:51:18 +0100 (CET) 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 kl3I9pH2ScYF; Wed, 13 Jan 2010 10:51:17 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F00EC0003; Wed, 13 Jan 2010 10:51:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EFBE3FCA81F; Wed, 13 Jan 2010 10:51:10 +0100 (CET) Date: Wed, 13 Jan 2010 10:51:10 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100113095110.GA34852@elstar.local> Mail-Followup-To: Andy Bierman , "netconf@ietf.org" References: <4B4CB232.9090003@iwl.com> <20100112.224609.176007266.mbj@tail-f.com> <4B4CF726.7050200@iwl.com> <20100112.235314.145115292.mbj@tail-f.com> <4B4D0164.4090202@iwl.com> <20100113083654.GA34549@elstar.local> <4B4D8BFE.1000907@iwl.com> <20100113091517.GC34664@elstar.local> <4B4D960A.1070800@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B4D960A.1070800@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] 4741bis, issue 14, capabilities changed error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 09:51:22 -0000 On Wed, Jan 13, 2010 at 10:44:42AM +0100, Andy Bierman wrote: > There is no requirement now for the server to save > the client capabilities. The client can remember what > it sent in its . The current obviously > has just the server capabilities, so this will add code > to clients, to deal with a new type of message. Take a look at the YANG definition and tell me where you think it does not follow the NETCONF . I am talking about the situation where the client capabilities change and the server should be notified. > So how does a client know it needs to call the RPC? > It seems to me you are replacing a poll with a poll. I am separating the synchronization mechanism from the question how it is triggered. See my original message. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andyb@iwl.com Wed Jan 13 02:47:30 2010 Return-Path: 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 CF20B3A698A for ; Wed, 13 Jan 2010 02:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=0.335, 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 fxnWde6Z2yec for ; Wed, 13 Jan 2010 02:47:30 -0800 (PST) Received: from smtp134.dfw.emailsrvr.com (smtp134.dfw.emailsrvr.com [67.192.241.134]) by core3.amsl.com (Postfix) with ESMTP id 23E313A635F for ; Wed, 13 Jan 2010 02:47:30 -0800 (PST) Received: from relay3.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay3.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 8CFD45D84FA for ; Wed, 13 Jan 2010 05:47:27 -0500 (EST) Received: by relay3.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 5C9D65D8463 for ; Wed, 13 Jan 2010 05:47:27 -0500 (EST) Message-ID: <4B4DA4B7.6030901@iwl.com> Date: Wed, 13 Jan 2010 02:47:19 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "netconf@ietf.org" References: <4B4CB232.9090003@iwl.com> <20100112.224609.176007266.mbj@tail-f.com> <4B4CF726.7050200@iwl.com> <20100112.235314.145115292.mbj@tail-f.com> <4B4D0164.4090202@iwl.com> <20100113083654.GA34549@elstar.local> <4B4D8BFE.1000907@iwl.com> <20100113091517.GC34664@elstar.local> <4B4D960A.1070800@iwl.com> <20100113095110.GA34852@elstar.local> In-Reply-To: <20100113095110.GA34852@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] 4741bis, issue 14, capabilities changed error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 10:47:30 -0000 Juergen Schoenwaelder wrote: > On Wed, Jan 13, 2010 at 10:44:42AM +0100, Andy Bierman wrote: > >> There is no requirement now for the server to save >> the client capabilities. The client can remember what >> it sent in its . The current obviously >> has just the server capabilities, so this will add code >> to clients, to deal with a new type of message. > > Take a look at the YANG definition and tell me where you think it does > not follow the NETCONF . I am talking about the situation where > the client capabilities change and the server should be notified. > There are no description clauses, just some syntax. The only server requirement in the protocol is that the client contain the base 4741 capability. Why would the client capabilities change, and why does that matter to the server? >> So how does a client know it needs to call the RPC? >> It seems to me you are replacing a poll with a poll. > > I am separating the synchronization mechanism from the question how it > is triggered. See my original message. > Sending the more than once is not backward compatible and will break existing clients. I do not see any value in your RPC. We already have this data in the monitoring module. I do not agree that a capability change should alter the current session at all. The server can update a timestamp, change the retrievable capabilities and send out a notification. This has always been good enough for SNMP and I see no reason why it isn't good enough for NETCONF. I do not agree that NETCONF sessions are static, or that they should be static. If a client does not want to poll for system state changes, then it should use notifications. Nobody has actually demonstrated how an arbitrary capability change breaks the client. I agree that the base capability cannot change during a session, but that is the only one. Everything else is just part of normal management of dynamic systems. > /js > Andy From mbj@tail-f.com Wed Jan 13 03:35:53 2010 Return-Path: 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 031653A6917 for ; Wed, 13 Jan 2010 03:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[AWL=0.235, 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 0f0hEgX4BDg1 for ; Wed, 13 Jan 2010 03:35:52 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 23D9E3A6904 for ; Wed, 13 Jan 2010 03:35:52 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 900E5616001; Wed, 13 Jan 2010 12:35:48 +0100 (CET) Date: Wed, 13 Jan 2010 12:35:48 +0100 (CET) Message-Id: <20100113.123548.38411240.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4B4D0164.4090202@iwl.com> References: <4B4CF726.7050200@iwl.com> <20100112.235314.145115292.mbj@tail-f.com> <4B4D0164.4090202@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis, issue 14, capabilities changed 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: , X-List-Received-Date: Wed, 13 Jan 2010 11:35:53 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> Do you agree that if capabilities change, the client needs to somehow > >>> be informed, and it needs to get a chance to resync? There are a > >>> couple of alternatives: > >> The client needs to poll for changes or listen > >> for notifications. > > > > So you do not agree with what I wrote. Does this means that you view > > the capabilities list not as a contract, but more as a hint for the > > client? > > > > I strongly object to such an interpretation. Why bother at all with > > keeping track of capabilities if they may change at any time, at any > > rate, in any way? > > > > I think the capabilities need refinement in order to assume > a particular capability change breaks the current session. I agree. But currently there is no way to tell. Some capability changes might be completely harmless, while others break the contract. Your way of dealing with this (ignore capability changes) is trivial to implement if a capability-changed error is returned. Your client code can automatically resync if it gets a capability-changed error. > The RPC and capabilities-changes error stuff is overkill. I think it is simple to implement, and we get a more robust model. > I think it is up to the client to decide if the session is > usable after a particular capability change. Sure. The server informs the client that a capability has changed by sending the capability-changed error, and the client decides what to do. > We can say that the base-NETCONF capability MUST NOT change > during a session. I don't see any others that represent > contracts -- they represent current configuration > settings or current system hardware state. Suppose the server stops supporting the :notification capability. You won't even know since you won't get the capability-changed notification. No capability in 4741 represents config or system hw state. /martin From mbj@tail-f.com Wed Jan 13 03:44:00 2010 Return-Path: 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 679343A6946 for ; Wed, 13 Jan 2010 03:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.206, 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 KfoqgjZE1Z1h for ; Wed, 13 Jan 2010 03:43:59 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 961A43A6904 for ; Wed, 13 Jan 2010 03:43:59 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id B7D8E616001; Wed, 13 Jan 2010 12:43:56 +0100 (CET) Date: Wed, 13 Jan 2010 12:43:56 +0100 (CET) Message-Id: <20100113.124356.60115605.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4B4DA4B7.6030901@iwl.com> References: <4B4D960A.1070800@iwl.com> <20100113095110.GA34852@elstar.local> <4B4DA4B7.6030901@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis, issue 14, capabilities changed 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: , X-List-Received-Date: Wed, 13 Jan 2010 11:44:00 -0000 Andy Bierman wrote: > >> So how does a client know it needs to call the RPC? It knows that it needs to resync when it gets the capabilities-changed error. > >> It seems to me you are replacing a poll with a poll. > > > > I am separating the synchronization mechanism from the question how it > > is triggered. See my original message. > > > > Sending the more than once is not backward compatible and > will break existing clients. Read Juergen's proposal again. His proposal is backwards compatible. He did not propose that as defined in 4741 should be sent more than once. > I do not see any value in > your RPC. We already have this data in the monitoring module. I agree with Jurgen that if we want to support a way to resync, we should have an explicit operation, not polling some data. The problem with polling some data is that it is one-way. The server does not know that the client has synced. This, of course, is only a problem if we believe that the capability list is more than a hint. /martin From andyb@iwl.com Wed Jan 13 06:36:26 2010 Return-Path: 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 597BD3A67AF for ; Wed, 13 Jan 2010 06:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.317, 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 SLlYUXAKoZwf for ; Wed, 13 Jan 2010 06:36:25 -0800 (PST) Received: from smtp114.dfw.emailsrvr.com (smtp114.dfw.emailsrvr.com [67.192.241.114]) by core3.amsl.com (Postfix) with ESMTP id 84D513A6403 for ; Wed, 13 Jan 2010 06:36:25 -0800 (PST) Received: from relay11.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay11.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id AB6A41800E7; Wed, 13 Jan 2010 09:36:22 -0500 (EST) Received: by relay11.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 6C4591800C6; Wed, 13 Jan 2010 09:36:22 -0500 (EST) Message-ID: <4B4DDA5E.4010006@iwl.com> Date: Wed, 13 Jan 2010 06:36:14 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B4D960A.1070800@iwl.com> <20100113095110.GA34852@elstar.local> <4B4DA4B7.6030901@iwl.com> <20100113.124356.60115605.mbj@tail-f.com> In-Reply-To: <20100113.124356.60115605.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis, issue 14, capabilities changed error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 14:36:26 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >>>> So how does a client know it needs to call the RPC? > > It knows that it needs to resync when it gets the capabilities-changed > error. > I do not agree this is a good idea. If I have a script that does a small number of steps, it isn't going to handle a capabilities-changed and resync. I do not agree that the condition you are describing represents an error and the session needs to be disrupted. There are dozens of potential monitoring objects that one might need to be aware of within the managed server. The server capabilities are just 1 piece of that data. If the client attempts an operation that is no longer supported, then the server has a reason to issue an error. >>>> It seems to me you are replacing a poll with a poll. >>> I am separating the synchronization mechanism from the question how it >>> is triggered. See my original message. >>> >> Sending the more than once is not backward compatible and >> will break existing clients. > > Read Juergen's proposal again. His proposal is backwards compatible. > He did not propose that as defined in 4741 should be sent more > than once. > >> I do not see any value in >> your RPC. We already have this data in the monitoring module. > > I agree with Jurgen that if we want to support a way to resync, we > should have an explicit operation, not polling some data. The problem > with polling some data is that it is one-way. The server does not > know that the client has synced. This, of course, is only a problem > if we believe that the capability list is more than a hint. > I don't agree that a capability resync is useful and needs a new operation added to the protocol. I don't agree that the server should assume all open sessions need to have every operation request rejected with an operation-failed error, as a way of preventing problems due to a capability change. This in itself will cause problems for the client. The client never needed this feature in SNMP. Notifications and polling are sufficient. Client applications that work now will stop working as soon as they get an operation-failed error that never happened before, completely unrelated to anything the client did or didn't send. Without a clear definition of a generic capability, the NETCONF text needs to specify exactly which capability changes cause particular behavior changes in the protocol. > > /martin > Andy From luchuk@snmp.com Tue Jan 19 11:32:13 2010 Return-Path: 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 7A5EB3A6869 for ; Tue, 19 Jan 2010 11:32:13 -0800 (PST) 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 Xpg4m1JDGYpi for ; Tue, 19 Jan 2010 11:32:12 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 8EDB43A685D for ; Tue, 19 Jan 2010 11:32:08 -0800 (PST) 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 OAA10993; Tue, 19 Jan 2010 14:32:04 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id OAA15021; Tue, 19 Jan 2010 14:32:03 -0500 (EST) Message-Id: <201001191932.OAA15021@adminfs.snmp.com> X-Mailer: exmh version 2.6.1 02/18/2003 with nmh-1.0 To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Jan 2010 14:32:03 -0500 From: Alan Luchuk Subject: [Netconf] Clarification of "operation" and other attributes 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: , X-List-Received-Date: Tue, 19 Jan 2010 19:32:13 -0000 Hello, Thanks for helping to clarify my undestanding with the responses to my prev- ious questions about the NETCONF RPC. I have additional ques- tions, and would appreciate further clarification. If these questions are answered in an RFC, draft, or WG mail archives, references would be fine instead of having to answer the questions again. In response to my previous question, Andy Bierman wrote: >Yes, where REPLACE applies only to the values explicitly >contained in the PDU. Any nodes already in the config >(or whatever subtree) remain in the config. > >The replace operation does not fail if the data is not >in the target config (unlike delete). > >PDU: > > > fred > barney > > >target config: > > > wilma > betty > > > >Result of default-operation='merge' (order may be different >on every server for top-level elements) > > > fred > barney > betty > > > >Result of default-operation=replace: > > > fred > barney > > >Result of default-operation=none: > > > wilma > betty > Two things about this example: First, was the element in this example intended to represent a generic container node in the data model, or was it intended to represent the element of the RPC? A colleague and I inter- preted Andy's reply differently, and it affected our understanding of the behavior. Second, because there was no contradicting E-mails on the working group, I assume the behavior in the example above is a WG consensus. I suggest the following wording for the description of the behavior of the "merge" operation: merge: The configuration data identified by the element containing this attribute is merged with the configuration at the cor- responding level in the configuration datastore identified by the target parameter. That is, nodes in the configuration data that DO NOT EXIST in the configuration datastore are added; nodes in the configuration data replace corresponding nodes that EXIST in the configuration datastore. This is the default behavior. Regarding the "delete" operation, does it behave differently for nodes that DO or DO NOT exist in the configuration datastore? That is, does the "delete" operation SUCCEED if the node specified in the configuration data EXISTS in the configuration datastore, and FAIL if the node specified in the configur- ation data DOES NOT EXIST in the configuration datastore? Or does "delete" always quietly succeed (for configuration nodes), such that after a "delete" operation has completed, one can be sure the specified node does NOT EXIST in the configuration datastore? The description of the "create" operation describes its behavior in the two cases where the configuration data specified DOES and DOES NOT exist in the in the configuration datastore. It would be helpful if there was similar text for all four operation attributes: merge, replace, create, and delete. RFC 4741 and bis-01 specifies: Elements in the subtree may contain an "operation" attribute. The attribute identifies the point in the configuration to perform the operation and MAY appear on multiple elements throughout the subtree. What are the rules for handling the "operation" attribute if different operations are specified at different levels in the configuration subtree. For example, what happens in the case of: Ethernet0/0 1500 Which happens: 1) Is everything in the subtree deleted, then the subtree merged; 2) Is the subtree merged, then the subtree deleted; 3) Is an error returned; 4) Is there a precedence order for the operation attributes; 5) Some other behavior; or 6) Is this implementation dependent? What happens if a "delete" (or other) operation is specified on a container element in the configuration data, but one or more of the contained nodes in the configuration datastore are state data, and therefore are not config- urable? Regarding the "continue-on-error" error option, if multiple errors occur during an RPC, does it return a single error, multiple errors, or is this implementation dependent? Thanks in advance for any/all clarification. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From mehmet.ersue@nsn.com Mon Jan 25 09:16:03 2010 Return-Path: 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 E423F3A67E7 for ; Mon, 25 Jan 2010 09:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 2HefqiVJbnib for ; Mon, 25 Jan 2010 09:16:02 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 96B583A6878 for ; Mon, 25 Jan 2010 09:16:02 -0800 (PST) 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 o0PHG6FN024640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 25 Jan 2010 18:16:06 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o0PHG4ck007243 for ; Mon, 25 Jan 2010 18:16:06 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 18:16:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jan 2010 18:15:58 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A643CD513@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: change of plans for NETCONF/YANG test event Thread-Index: AcqbzdV2Ggs4NjjURoelVEMuK0O6OACA435wAAQYvhA= From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 25 Jan 2010 17:16:00.0413 (UTC) FILETIME=[10D64CD0:01CA9DE2] Subject: [Netconf] FW: change of plans for NETCONF/YANG test event 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: , X-List-Received-Date: Mon, 25 Jan 2010 17:16:04 -0000 =20 FYI: There will be no NETCONF/YANG test event in Anaheim before IETF 77. Cheers, Mehmet -----Original Message----- From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Monday, January 25, 2010 4:20 PM To: Chris Wellens; david.partain@ericsson.com; Kessens, David (NSN - US/Atlanta); Bert (IETF) Wijnen; Ersue, Mehmet (NSN - DE/Munich) Cc: rbonica@juniper.net Subject: RE: change of plans for NETCONF/YANG test event Thanks for the update, Chris.=20 David and the other interested WG chairs, I *think* the event was announced on the mail lists of the two WGs. If I am not mistaken, you may want to relay the information about the change of plans, so that people are aware and do not make travel plans based on the assumption the event takes place before Anaheim.=20 Regards, Dan > -----Original Message----- > From: Chris Wellens [mailto:info@iwl.com]=20 > Sent: Saturday, January 23, 2010 3:46 AM > To: david.partain@ericsson.com > Cc: rbonica@juniper.net; Romascanu, Dan (Dan) > Subject: change of plans for NETCONF/YANG test event >=20 > Hi David, >=20 > I just wanted to let you know that the consensus here at=20 > InterWorking Labs is that NETCONF/YANG is not ready yet for=20 > interoperability testing, at least at the scale we were=20 > planning. We believe more content is required, and that=20 > implementors would not be likely to implement test YANG=20 > modules that we define. We need to wait for more standard=20 > modules to be defined and implemented, and then we can go=20 > forward with a test event. >=20 > Therefore, we will *NOT* go forward with a testing event at=20 > the Anaheim IETF meeting. I am copying the relevant Area=20 > Directors so they are informed.=20 >=20 > We look forward to seeing you there and helping to move along=20 > the work in any way that we can. >=20 > Sincerely, >=20 > Chris Wellens > www.iwl.com > +1.831.818.7963 - Cell >=20 From mehmet.ersue@nsn.com Wed Jan 27 08:44:34 2010 Return-Path: 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 94F383A6889 for ; Wed, 27 Jan 2010 08:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 PTd--EdRdegs for ; Wed, 27 Jan 2010 08:44:33 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 7A1A63A6878 for ; Wed, 27 Jan 2010 08:44:33 -0800 (PST) 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 o0RGijT2009838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Jan 2010 17:44:46 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o0RGidwt029648; Wed, 27 Jan 2010 17:44:45 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 17:44:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jan 2010 17:44:36 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64401597@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 77 IETF Meeting Cutoff Dates Thread-Index: AcqfXalrOOgNQxAITW6sFE8muWjUVwAETAZQ References: From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 27 Jan 2010 16:44:39.0166 (UTC) FILETIME=[045A49E0:01CA9F70] Subject: Re: [Netconf] IETF 77 IETF Meeting Cutoff Dates 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: , X-List-Received-Date: Wed, 27 Jan 2010 16:44:34 -0000 Dear NETCONF WG Editors, please consider to submit your drafts on time=20 well before the cut-off date published on IETF=20 77 page. Please initiate also the draft discussion on the=20 maillist as early as possible as a preparation=20 for IETF 77 NETCONF session. Thank you. Mehmet & Bert =20 > -----Original Message----- > From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: Wednesday, January 27, 2010 3:33 PM > To: ops-chairs@ietf.org > Subject: IETF 77 IETF Meeting Cutoff Dates >=20 > OPS WG Chairs, >=20 > Please make sure that you and your WG participants are aware about the > IETF 77 IETF Meeting Cutoff Dates. By now you should have sent BOF > requests, as the deadline for submission was 1/25. Some other=20 > important > dates:=20 >=20 > 2010-02-08 (Monday): Cutoff date for requests to schedule=20 > Working Group > meetings at 17:00 PST (01:00 Tuesday, February 9 UTC). To request a > Working Group session, use the IETF Meeting Session Request Tool.=20 > 2010-02-22 (Monday): Cutoff date for requests to reschedule Working > Group and BOF meetings 17:00 PST (01:00 Tuesday, February 23 UTC).=20 > 2010-02-22 (Monday): Working Group Chair approval for initial document > (Version -00) submissions appreciated by 17:00 PST (01:00 Tuesday, > February 23 UTC).=20 > 2010-02-26 (Friday): Final agenda to be published.=20 > 2010-03-01 (Monday): Internet Draft Cut-off for initial document (-00) > submission by 17:00 PST (01:00 Tuesday, March 2 UTC), upload=20 > using IETF > ID Submission Tool.=20 > 2010-03-08 (Monday): Internet Draft final submission cut-off by 17:00 > PST (01:00 Tuesday, March 9 UTC), upload using IETF ID=20 > Submission Tool. >=20 > All cutoff dates are available at > http://www.ietf.org/meeting/cutoff-dates-2010.html >=20 > Regards, >=20 > Dan >=20