From mbj@tail-f.com Sun Mar 1 12:07:10 2009 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 5E7523A6924 for ; Sun, 1 Mar 2009 12:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.205 X-Spam-Level: X-Spam-Status: No, score=-1.205 tagged_above=-999 required=5 tests=[AWL=-0.648, BAYES_05=-1.11, 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 k0E0IW+JwwMF for ; Sun, 1 Mar 2009 12:07:09 -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 875C63A6BC8 for ; Sun, 1 Mar 2009 12:07:09 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 82CEC76C4ED; Sun, 1 Mar 2009 21:07:33 +0100 (CET) Date: Sun, 01 Mar 2009 21:07:33 +0100 (CET) Message-Id: <20090301.210733.188354424.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49A9733C.8090107@netconfcentral.com> References: <49A58148.4070704@netconfcentral.com> <49A9733C.8090107@netconfcentral.com> X-Mailer: Mew version 6.0.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] comments on netconf-monitoring-03 draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 20:07:10 -0000 Hi, Andy Bierman wrote: > 3 more comments on counters: > > 14) The counter conditions are specific -- that's good, > except inBadRpcs. The words 'parsed correctly' > implies well-formed XML. If so, then another > counter should be added for invalid XML messages received. There is one - inXMLParseErrors. > 15) Is inRpcs == outRpcReplies always true? > If not, why not? (If yes, why do both counters exist?) Good question... I think that if these counters do not have the same value, then that indicates some bug in the agent which made it close the session or something. Should one of them be removed? > 16) Is inBadRpcs == outRpcErrors always true? > If not, why not? (If yes, why do both counters exist?) If you receive a non well-formed XML message, but you did get the element, should you reply with an ? If so, then these counters do not have to be the same. /martin From mbj@tail-f.com Sun Mar 1 12:19:50 2009 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 7C7AE28C1B7 for ; Sun, 1 Mar 2009 12:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.117, 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 T0FRPtudWKjx for ; Sun, 1 Mar 2009 12:19:49 -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 9A29728C155 for ; Sun, 1 Mar 2009 12:19:49 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 668A976C4ED; Sun, 1 Mar 2009 21:20:14 +0100 (CET) Date: Sun, 01 Mar 2009 21:20:14 +0100 (CET) Message-Id: <20090301.212014.207482862.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49A4497A.3080006@netconfcentral.com> References: <200902241855.n1OIthOk041051@idle.juniper.net> <49A4497A.3080006@netconfcentral.com> X-Mailer: Mew version 6.0.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] with-defaults.yang 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, 01 Mar 2009 20:19:50 -0000 Andy Bierman wrote: > Phil Shafer wrote: > > Andy Bierman writes: > >> augment "/nc:copy-config/nc:input" { > >> uses WithDefaults; > >> } > > Does this conflict with the existing NETCONF idea that copy-config > > does a higher-level datastore-oriented copy, rather than one that > > inspects the configuration nodes? I can't find this idea called > > out strongly enough in the RFC to matter, but I recall the idea was > > that copy-config did a copy without regard for the content. Does > > this idea still exist? > > > > AFAIK, the only mandatory copy-config operation is > from to , if :startup is supported. > I think with-defaults applies in that situation. > > I agree with you (in this case and in general) > that 'feature-creep' seems to occur to NETCONF sometimes. > It was never the intent the the target of a > be a standard database, in any other use case except :startup. > Without :url or :startup capabilities, there is nothing > mandatory to support for . I think what you call 'feature-creep' occurs when the specification does not clearly spell out what is supposed to happen. In this case, the XSD allows an inline configuration, which I would assume is the config in XML format. This inline configuration is also shown in some example, so I assume it is not another bug in the XSD. The format of the result of a copy-config to a url is not specified, but on this ML it has been assumed that an XML format is used with e.g. the NETCONF element as document root element. But maybe the intention was that the copy of a db to a file (url) could use any internal format? Regardless of which, this should be clarified in 4741bis. /martin From andy@netconfcentral.com Sun Mar 1 12:24:15 2009 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 87F0328C1CD for ; Sun, 1 Mar 2009 12:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, 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 WmMhFkguz+Fc for ; Sun, 1 Mar 2009 12:24:14 -0800 (PST) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id 2D8C428C0DE for ; Sun, 1 Mar 2009 12:23:54 -0800 (PST) Received: from [209.191.108.97] by n17.bullet.mail.mud.yahoo.com with NNFMP; 01 Mar 2009 20:24:19 -0000 Received: from [68.142.201.243] by t4.bullet.mud.yahoo.com with NNFMP; 01 Mar 2009 20:24:19 -0000 Received: from [127.0.0.1] by omp404.mail.mud.yahoo.com with NNFMP; 01 Mar 2009 20:24:19 -0000 X-Yahoo-Newman-Id: 194576.36358.bm@omp404.mail.mud.yahoo.com Received: (qmail 33082 invoked from network); 1 Mar 2009 20:24:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.240.70 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 1 Mar 2009 20:24:18 -0000 X-YMail-OSG: hB58tXUVM1mV.dcKi6ebCt.kIT88_IYiO1MbW15Na.Z2dpiMLJZVLr0_nrH9e4a7t9At5niC3fXO6AfbJcMLGKRzne6qvENWF57TxcxmutejxDR2TNKTYDJGgrlzozPchdB7s_PVSE7dtAoua2SskP_.YijHe.no0EJSmMTNgsii4djJVFBTuX6qWm_u9eNdDxqOC19ATq1NEAfVOfsSfA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49AAEEEF.1090708@netconfcentral.com> Date: Sun, 01 Mar 2009 12:24:15 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <49A58148.4070704@netconfcentral.com> <49A9733C.8090107@netconfcentral.com> <20090301.210733.188354424.mbj@tail-f.com> In-Reply-To: <20090301.210733.188354424.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] comments on netconf-monitoring-03 draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 20:24:15 -0000 Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> 3 more comments on counters: >> >> 14) The counter conditions are specific -- that's good, >> except inBadRpcs. The words 'parsed correctly' >> implies well-formed XML. If so, then another >> counter should be added for invalid XML messages received. > > There is one - inXMLParseErrors. > I mixed up 2 comments from my notes on this issue. I meant to say there is no catch-all like resources-denied. Is this worth a separate counter, or is inBadRpcs good enough? >> 15) Is inRpcs == outRpcReplies always true? >> If not, why not? (If yes, why do both counters exist?) > > Good question... I think that if these counters do not have the same > value, then that indicates some bug in the agent which made it close > the session or something. Should one of them be removed? > Actually (in my code) when you read the counters, the inRpcs is always 1 more than outRpcReplies, because the for the counters has already been added to inRpcs. >> 16) Is inBadRpcs == outRpcErrors always true? >> If not, why not? (If yes, why do both counters exist?) > > If you receive a non well-formed XML message, but you did get the > element, should you reply with an ? If so, then > these counters do not have to be the same. > If you cannot send an then the session should be dropped. We should not waste counter memory on redundant or easily derivable statistics. That seems to be the case here. > > /martin > > Andy From mehmet.ersue@nsn.com Sun Mar 1 15:09:09 2009 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 B61973A67E2 for ; Sun, 1 Mar 2009 15:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=-0.925, 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 5UOL145zrGcj for ; Sun, 1 Mar 2009 15:09:09 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 9E4D43A6359 for ; Sun, 1 Mar 2009 15:09:08 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n21N9W3o032469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 2 Mar 2009 00:09:32 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n21N9WuN030547 for ; Mon, 2 Mar 2009 00:09:32 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Mar 2009 00:09:31 +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, 2 Mar 2009 00:09:28 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Initial Version I-D Submission Deadline Extended to March 4, 2009 Thread-Index: AcmYSLfXbt+ZfkuNTwKRX2ZgmB9tzACeeQOQ From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 01 Mar 2009 23:09:31.0826 (UTC) FILETIME=[C7819120:01C99AC2] Subject: [Netconf] FW: Initial Version I-D Submission Deadline Extended to March 4, 2009 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, 01 Mar 2009 23:09:09 -0000 =20 FYI > Please note that the date for updated I-D versions has NOT been =20 > extended, and is still March 9, 2009. http://www.ietf.org/meetings/74/cutoff-dates.html Cheers,=20 Mehmet -----Original Message----- From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On Behalf Of ext Alexa Morris Sent: Thursday, February 26, 2009 8:28 PM To: ietf-announce@ietf.org; ietf@ietf.org; wgchairs@ietf.org Subject: Initial Version I-D Submission Deadline Extended to March 4, 2009 The IESG has extended the deadline for initial version (00) =20 submissions of Internet Drafts by 2 days (48 hours). The new deadline =20 is March 4, 2009 at 1700 Pacific (March 5, 2009 at 0100 UTC / GMT) =20 and the extension is for IETF 74 only. The deadline has been extended =20 due to the copyright legend text alternative being recently finalized, =20 approved and implemented. Please note that the date for updated I-D versions has NOT been =20 extended, and is still March 9, 2009. Regards, Alexa ----------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com From Washam.Fan@huaweisymantec.com Sun Mar 1 18:36:53 2009 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 1A8243A6A9D for ; Sun, 1 Mar 2009 18:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.339, 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 HH98esXLfncP for ; Sun, 1 Mar 2009 18:36:52 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 0882C3A689E for ; Sun, 1 Mar 2009 18:36:52 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KFU0011IXY0L150@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Mon, 02 Mar 2009 10:37:15 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KFU00A0DXXZAU00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Mon, 02 Mar 2009 10:37:12 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Mon, 02 Mar 2009 10:37:11 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Mon, 02 Mar 2009 10:37:11 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <49AAEEEF.1090708@netconfcentral.com> References: <49A58148.4070704@netconfcentral.com> <49A9733C.8090107@netconfcentral.com> <20090301.210733.188354424.mbj@tail-f.com> <49AAEEEF.1090708@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] comments on netconf-monitoring-03 draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 02:36:53 -0000 > >> 15) Is inRpcs == outRpcReplies always true? > >> If not, why not? (If yes, why do both counters exist?) > > > > Good question... I think that if these counters do not have the same > > value, then that indicates some bug in the agent which made it close > > the session or something. Should one of them be removed? > > > > Actually (in my code) when you read the counters, > the inRpcs is always 1 more than outRpcReplies, > because the for the counters has already been added > to inRpcs. If requests sent in a row, before all the corresponding responds returned, the inPpcs may be more than 1 greater than outRpcReplies. So if inRpcs is greater than outRpcReplies, we can assume a number of requests is being handled when we retrieve the counters. > >> 16) Is inBadRpcs == outRpcErrors always true? > >> If not, why not? (If yes, why do both counters exist?) Or inBadRpcs + inNotSupportedRpcs == outRpcErrors ? washam > > If you receive a non well-formed XML message, but you did get the > > element, should you reply with an ? If so, then > > these counters do not have to be the same. > > > > If you cannot send an then > the session should be dropped. > > We should not waste counter memory on redundant or > easily derivable statistics. That seems to be the case here. > > > > > /martin > > > > > > Andy > From mbj@tail-f.com Sun Mar 1 23:14:09 2009 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 0187E28C14F for ; Sun, 1 Mar 2009 23:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=0.140, 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 R+WKAskA-I0f for ; Sun, 1 Mar 2009 23:14:08 -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 2EE6B3A6892 for ; Sun, 1 Mar 2009 23:14:08 -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 8EB8276C50A; Mon, 2 Mar 2009 08:14:32 +0100 (CET) Date: Mon, 02 Mar 2009 08:14:32 +0100 (CET) Message-Id: <20090302.081432.100133327.mbj@tail-f.com> To: Washam.Fan@huaweisymantec.com From: Martin Bjorklund In-Reply-To: References: <20090301.210733.188354424.mbj@tail-f.com> <49AAEEEF.1090708@netconfcentral.com> X-Mailer: Mew version 6.0.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] comments on netconf-monitoring-03 draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 07:14:09 -0000 WashamFan wrote: > > >> 16) Is inBadRpcs == outRpcErrors always true? > > >> If not, why not? (If yes, why do both counters exist?) > > Or inBadRpcs + inNotSupportedRpcs == outRpcErrors ? No, for example a perfectly legal will not increment inBadRpcs or inNotSupportedRpcs, but it might still generate an rpc-error if the source config is not valid. Hmm. Re-reading the description of outRpcErrors, it seems the text is not as precise as it could be. E.g. will the counter be incremented if AND is sent? Will it be incremented if inline rpc-errors are sent? I think the conclusion is that this counter probably is not very useful as it is defined. Separate counters for each error-type might be interesting, or at least for error-type transport, rpc, and protocol. /martin From mehmet.ersue@nsn.com Mon Mar 2 06:26:58 2009 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 79EDB28C1DA for ; Mon, 2 Mar 2009 06:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[AWL=-0.823, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORIQSLfB8sTM for ; Mon, 2 Mar 2009 06:26:57 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 0A38328C0FD for ; Mon, 2 Mar 2009 06:26:56 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n22ERGUA018820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Mar 2009 15:27:16 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n22ERFKG011349; Mon, 2 Mar 2009 15:27:16 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Mar 2009 15:27:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99B42.F9EC35A1" Date: Mon, 2 Mar 2009 15:27:11 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Agenda for IETF #74 NETCONF Session Thread-Index: AcmbQvoAww2K+4N3QkyOIAKlDQE82A== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 02 Mar 2009 14:27:15.0041 (UTC) FILETIME=[FBBD6510:01C99B42] Subject: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 14:26:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99B42.F9EC35A1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG,=20 below is the draft agenda for the NETCONF WG session=20 at the IETF #74. Our session will be on Tuesday after=20 the lunch break at 1300-1500. Our main focus in the session will be as usual on open issue=20 discussion but we have a few additional topics. Please send us your comments and requests concerning=20 the agenda.=20 The duration of the slots is not final and subject to change. Presenters please confirm your slot. BTW: As usual we need to organize the scribes and minute=20 takers _before_ the meeting. Please help us to start the=20 session on time and send us a note if you volunteer.=20 Bert & Mehmet=20 ___________________________________________________ ** Draft - 020309 ** NETCONF WG=20 IETF 74, San Francisco, CA, USA TUESDAY, March 24, 2009, 1300-1500=20 WG Chairs: Bert Wijnen Mehmet Ersue Scribes (IF no_volunteers THEN wait_forever)=20 Agenda bashing (2 minutes)=20 WG status review (5 minutes)=20 Chartered items: 1. NETCONF Monitoring Schema - Mark Scott (15 minutes) =20 draft-ietf-netconf-monitoring 2. Partial Lock RPC for NETCONF - Balazs Lengyel (15 minutes)=20 draft-ietf-netconf-partial-lock=20 3. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20 minutes) draft-ietf-netconf-4741bis 4. With-defaults capability for NETCONF - B. Lengyel (20 minutes) draft-bierman-netconf-with-defaults Non-Chartered items: 1. Robust Configuration Management within NETCONF - R. Cole/D. = Romascanu (15 minutes) =20 draft-cole-netconf-robust-config-00 Open mike=20 Generic solution for the message identity issue (10 minutes) Any other topics to discuss?=20 AOB ------_=_NextPart_001_01C99B42.F9EC35A1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Draft Agenda for IETF #74 NETCONF Session

Dear NETCONF WG,

below is the draft agenda for the = NETCONF WG session
at the IETF #74. Our session will be = on Tuesday after
the lunch break at 1300-1500.

Our main focus in the session will be = as usual on open issue
discussion but we have a few = additional topics.
Please send us your comments and = requests concerning
the agenda.

The duration of the slots is not = final and subject to change.
Presenters please confirm your = slot.

BTW: As usual we need to organize the = scribes and minute
takers _before_ the meeting. Please = help us to start the
session on time and send us a note = if you volunteer.

Bert & Mehmet

___________________________________________________

** Draft - 020309 = **

NETCONF WG =
IETF 74, San = Francisco, CA, USA

TUESDAY, March 24, = 2009, 1300-1500

   WG = Chairs:
   Bert = Wijnen <bertietf@bwijnen.net>
   = Mehmet Ersue <mehmet.ersue@nsn.com>

   = Scribes (IF no_volunteers THEN wait_forever)
   = Agenda bashing (2 minutes)
   WG = status review (5 minutes)

   = Chartered items:

      1. NETCONF Monitoring = Schema - Mark Scott (15 minutes) 
          = draft-ietf-netconf-monitoring
      2. Partial Lock RPC for = NETCONF - Balazs Lengyel (15 minutes)
         = draft-ietf-netconf-partial-lock
      3. 4741bis-draft - M. = Bjorklund/J. Sch=F6nw=E4lder (20 minutes)
          = draft-ietf-netconf-4741bis
      4. With-defaults = capability for NETCONF - B. Lengyel (20 minutes)
          = draft-bierman-netconf-with-defaults

   = Non-Chartered items:

      1. Robust Configuration = Management within NETCONF - R. Cole/D. Romascanu (15 minutes)  =
          = draft-cole-netconf-robust-config-00

   Open = mike
      Generic solution for the = message identity issue (10 minutes)
      Any other topics to = discuss?

   = AOB

------_=_NextPart_001_01C99B42.F9EC35A1-- From mehmet.ersue@nsn.com Mon Mar 2 08:14:20 2009 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 DA8753A69C7 for ; Mon, 2 Mar 2009 08:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.338 X-Spam-Level: X-Spam-Status: No, score=-5.338 tagged_above=-999 required=5 tests=[AWL=1.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JS9eiQYcof4w for ; Mon, 2 Mar 2009 08:14:19 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id D85573A6452 for ; Mon, 2 Mar 2009 08:14:15 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n22GEdfY001558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Mar 2009 17:14:39 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n22GEdhh031796; Mon, 2 Mar 2009 17:14:39 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Mar 2009 17:14:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99B51.FB246592" Date: Mon, 2 Mar 2009 17:14:36 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Draft Agenda for IETF #74 NETCONF Session Thread-Index: AcmbQvoAww2K+4N3QkyOIAKlDQE82AADjyYg References: From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 02 Mar 2009 16:14:39.0034 (UTC) FILETIME=[FCA8B1A0:01C99B51] Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 16:14:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99B51.FB246592 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All, =20 please find an update of the NETCONF session agenda. =20 PS: The duration of the slots is subject to change.=20 Presenters please confirm your slot.=20 =20 Mehmet=20 ________________________________________ =20 ** Draft - 020309 ** =20 NETCONF WG=20 IETF 74, San Francisco, CA, USA =20 TUESDAY, March 24, 2009, 1300-1500=20 =20 WG Chairs: Bert Wijnen Mehmet Ersue =20 Scribes (IF no_volunteers THEN wait_forever)=20 Agenda bashing (2 minutes)=20 WG status review (5 minutes)=20 =20 Chartered items: =20 1. Partial Lock RPC for NETCONF - Balazs Lengyel (5 minutes)=20 draft-ietf-netconf-partial-lock=20 2. NETCONF Monitoring Schema - Mark Scott (15 minutes) =20 draft-ietf-netconf-monitoring 3. With-defaults capability for NETCONF - A. Bierman/B. Lengyel = (20 minutes) draft-ietf-netconf-with-defaults 4. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20 minutes) draft-ietf-netconf-4741bis =20 Non-Chartered items: =20 1. Generic solution for the message integrity issue (10 minutes) 2. Robust Configuration Management within NETCONF - R. Cole/D. = Romascanu (15 minutes) =20 draft-cole-netconf-robust-config-00 =20 Open mike=20 Any other topics to discuss?=20 =20 AOB ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On = Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) Sent: Monday, March 02, 2009 3:27 PM To: Netconf Subject: [Netconf] Draft Agenda for IETF #74 NETCONF Session =09 =09 Dear NETCONF WG,=20 below is the draft agenda for the NETCONF WG session=20 at the IETF #74. Our session will be on Tuesday after=20 the lunch break at 1300-1500.=20 Our main focus in the session will be as usual on open issue=20 discussion but we have a few additional topics.=20 Please send us your comments and requests concerning=20 the agenda.=20 The duration of the slots is not final and subject to change.=20 Presenters please confirm your slot.=20 BTW: As usual we need to organize the scribes and minute=20 takers _before_ the meeting. Please help us to start the=20 session on time and send us a note if you volunteer.=20 Bert & Mehmet=20 ___________________________________________________=20 ** Draft - 020309 **=20 NETCONF WG=20 IETF 74, San Francisco, CA, USA=20 TUESDAY, March 24, 2009, 1300-1500=20 WG Chairs:=20 Bert Wijnen =20 Mehmet Ersue =20 Scribes (IF no_volunteers THEN wait_forever)=20 Agenda bashing (2 minutes)=20 WG status review (5 minutes)=20 Chartered items:=20 1. NETCONF Monitoring Schema - Mark Scott (15 minutes) =20 draft-ietf-netconf-monitoring=20 2. Partial Lock RPC for NETCONF - Balazs Lengyel (15 minutes)=20 draft-ietf-netconf-partial-lock=20 3. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20 minutes)=20 draft-ietf-netconf-4741bis=20 4. With-defaults capability for NETCONF - B. Lengyel (20 minutes) = draft-bierman-netconf-with-defaults=20 Non-Chartered items:=20 1. Robust Configuration Management within NETCONF - R. Cole/D. = Romascanu (15 minutes) =20 draft-cole-netconf-robust-config-00=20 Open mike=20 Generic solution for the message identity issue (10 minutes)=20 Any other topics to discuss?=20 AOB=20 ------_=_NextPart_001_01C99B51.FB246592 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Draft Agenda for IETF #74 NETCONF Session
Dear All,
 
please find an update of the NETCONF session=20 agenda.
 
PS: The duration of = the slots is=20 subject = to=20 change.
Presenters = please confirm=20 your slot.
 
Mehmet =
________________________________________
 
**=20 Draft - 020309 **
 
NETCONF WG
IETF 74, San Francisco, CA, = USA
 
TUESDAY, March 24, 2009, 1300-1500
 
   WG Chairs:
   Bert Wijnen <bertietf@bwijnen.net>
&nbs= p; =20 Mehmet Ersue <mehmet.ersue@nsn.com><= /SPAN>
 
   Scribes (IF no_volunteers THEN wait_forever)=20
   Agenda bashing (2 minutes)
   WG status = review (5=20 minutes)
 
   Chartered items:
 
      1. Partial Lock RPC for NETCONF = - Balazs=20 Lengyel (5 minutes)
         = draft-ietf-netconf-partial-lock
      2. = NETCONF=20 Monitoring Schema - Mark Scott (15 minutes) =20
         =20 draft-ietf-netconf-monitoring
      3. = With-defaults=20 capability for NETCONF - A. Bierman/B. Lengyel (20=20 minutes)
         =20 draft-ietf-netconf-with-defaults
      4.=20 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20=20 minutes)
         =20 draft-ietf-netconf-4741bis
 
   Non-Chartered items:
 
      1. Generic solution for the = message=20 integrity issue (10 minutes)
      2. Robust = Configuration Management within NETCONF - R. Cole/D. Romascanu (15=20 minutes)  =
         =20 draft-cole-netconf-robust-config-00
 
   Open mike
      Any = other=20 topics to discuss?
 
   AOB

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, = Mehmet (NSN -=20 DE/Munich)
Sent: Monday, March 02, 2009 3:27 = PM
To:=20 Netconf
Subject: [Netconf] Draft Agenda for IETF #74 NETCONF = Session


Dear NETCONF WG,

below is the draft agenda for the = NETCONF WG=20 session
at the IETF #74. Our = session will=20 be on Tuesday after
the lunch = break at=20 1300-1500.

Our main focus in the session will be = as usual on=20 open issue
discussion but we = have a few=20 additional topics.
Please = send us your=20 comments and requests concerning
the=20 agenda.

The duration of the slots is not = final and=20 subject to change.
Presenters = please=20 confirm your slot.

BTW: As usual we need to organize the = scribes and=20 minute
takers _before_ the = meeting.=20 Please help us to start the
session on=20 time and send us a note if you volunteer.

Bert & Mehmet

___________________________________________________

** Draft - 020309 = **=20

NETCONF WG =
IETF 74, San Francisco, CA,=20 USA

TUESDAY, March 24, = 2009, 1300-1500=20

   WG=20 Chairs:
  =20 Bert Wijnen <bertietf@bwijnen.net>
   Mehmet Ersue=20 <mehmet.ersue@nsn.com>

   Scribes = (IF=20 no_volunteers THEN wait_forever)
   Agenda bashing (2 minutes)=20
   WG=20 status review (5 minutes)

   = Chartered=20 items:

      1.=20 NETCONF Monitoring Schema - Mark Scott (15 minutes) =20
         =20 draft-ietf-netconf-monitoring
      2. Partial Lock = RPC for=20 NETCONF - Balazs Lengyel (15 minutes)
        =20 draft-ietf-netconf-partial-lock
      3. = 4741bis-draft - M.=20 Bjorklund/J. Sch=F6nw=E4lder (20 minutes)
         =20 draft-ietf-netconf-4741bis
      4. With-defaults capability = for NETCONF=20 - B. Lengyel (20 minutes)
         =20 draft-bierman-netconf-with-defaults

   = Non-Chartered=20 items:

      1.=20 Robust Configuration Management within NETCONF - R. Cole/D. Romascanu = (15=20 minutes) 
         =20 draft-cole-netconf-robust-config-00

   Open = mike=20
      Generic solution for the = message=20 identity issue (10 minutes)
      Any other topics to discuss?=20

   = AOB=20

------_=_NextPart_001_01C99B51.FB246592-- From andy@netconfcentral.com Mon Mar 2 08:30:12 2009 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 091F128C23A for ; Mon, 2 Mar 2009 08:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 Y6QFhNv4mK2u for ; Mon, 2 Mar 2009 08:30:11 -0800 (PST) Received: from n19.bullet.mail.mud.yahoo.com (n19.bullet.mail.mud.yahoo.com [68.142.206.146]) by core3.amsl.com (Postfix) with SMTP id DC5D428C235 for ; Mon, 2 Mar 2009 08:30:10 -0800 (PST) Received: from [209.191.108.96] by n19.bullet.mail.mud.yahoo.com with NNFMP; 02 Mar 2009 16:30:37 -0000 Received: from [68.142.201.251] by t3.bullet.mud.yahoo.com with NNFMP; 02 Mar 2009 16:30:37 -0000 Received: from [127.0.0.1] by omp412.mail.mud.yahoo.com with NNFMP; 02 Mar 2009 16:30:37 -0000 X-Yahoo-Newman-Id: 16640.91267.bm@omp412.mail.mud.yahoo.com Received: (qmail 61427 invoked from network); 2 Mar 2009 16:30:36 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.240.70 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 2 Mar 2009 16:30:35 -0000 X-YMail-OSG: aJGCZwMVM1mFh49M7zUOYtGyaAQVX08AEE1VqY.y2oRhtKrttjvOQspTP_CMf7A6IwrvyUJJNYi5E1x79nQtQu91vJ.lKvUY.aa7X8uwBluVTvKS.syNj3KGHcmqk.4p9k2rD9emdBXAdQbQ4kbpNR1dvqK2Lv5aZRG7tCfg2tsgQtJsZrYCg5_N X-Yahoo-Newman-Property: ymail-3 Message-ID: <49AC09AA.4030406@netconfcentral.com> Date: Mon, 02 Mar 2009 08:30:34 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Netconf Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 16:30:12 -0000 Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear All, > > please find an update of the NETCONF session agenda. > > PS: The duration of the slots is subject to change. > Presenters please confirm your slot. > I requested a short time slot to discuss draft-bierman-netconf-module-00.txt. In general, the WG needs to deal with the emergence of YANG and DSDL, and the pervasiveness of XSD. How will the NETCONF protocol operations be augmented to support with-defaults or any other extension in the future? The WG should have a plan going forward to deal with all 3 formats. It appears that the WG is going to continue to use XSD for normative syntax, YANG for non-normative syntax, and unclear what role DSDL has at all. > Mehmet Andy > ________________________________________ > > ** Draft - 020309 ** > > NETCONF WG > IETF 74, San Francisco, CA, USA > > TUESDAY, March 24, 2009, 1300-1500 > > WG Chairs: > Bert Wijnen > > Mehmet Ersue > > > Scribes (IF no_volunteers THEN wait_forever) > Agenda bashing (2 minutes) > WG status review (5 minutes) > > Chartered items: > > 1. Partial Lock RPC for NETCONF - Balazs Lengyel (5 minutes) > draft-ietf-netconf-partial-lock > 2. NETCONF Monitoring Schema - Mark Scott (15 minutes) > draft-ietf-netconf-monitoring > 3. With-defaults capability for NETCONF - A. Bierman/B. Lengyel > (20 minutes) > draft-ietf-netconf-with-defaults > 4. 4741bis-draft - M. Bjorklund/J. Schönwälder (20 minutes) > draft-ietf-netconf-4741bis > > Non-Chartered items: > > 1. Generic solution for the message integrity issue (10 minutes) > 2. Robust Configuration Management within NETCONF - R. Cole/D. > Romascanu (15 minutes) > draft-cole-netconf-robust-config-00 > > Open mike > Any other topics to discuss? > > AOB > > ------------------------------------------------------------------------ > *From:* netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] > *On Behalf Of *ext Ersue, Mehmet (NSN - DE/Munich) > *Sent:* Monday, March 02, 2009 3:27 PM > *To:* Netconf > *Subject:* [Netconf] Draft Agenda for IETF #74 NETCONF Session > > > Dear NETCONF WG, > > below is the draft agenda for the NETCONF WG session > at the IETF #74. Our session will be on Tuesday after > the lunch break at 1300-1500. > > Our main focus in the session will be as usual on open issue > discussion but we have a few additional topics. > Please send us your comments and requests concerning > the agenda. > > The duration of the slots is not final and subject to change. > Presenters please confirm your slot. > > BTW: As usual we need to organize the scribes and minute > takers _before_ the meeting. Please help us to start the > session on time and send us a note if you volunteer. > > Bert & Mehmet > > ___________________________________________________ > > ** Draft - 020309 ** > > NETCONF WG > IETF 74, San Francisco, CA, USA > > TUESDAY, March 24, 2009, 1300-1500 > > WG Chairs: > Bert Wijnen > Mehmet Ersue > > Scribes (IF no_volunteers THEN wait_forever) > Agenda bashing (2 minutes) > WG status review (5 minutes) > > Chartered items: > > 1. NETCONF Monitoring Schema - Mark Scott (15 minutes) > draft-ietf-netconf-monitoring > 2. Partial Lock RPC for NETCONF - Balazs Lengyel (15 minutes) > draft-ietf-netconf-partial-lock > 3. 4741bis-draft - M. Bjorklund/J. Schönwälder (20 minutes) > draft-ietf-netconf-4741bis > 4. With-defaults capability for NETCONF - B. Lengyel (20 minutes) > draft-bierman-netconf-with-defaults > > Non-Chartered items: > > 1. Robust Configuration Management within NETCONF - R. Cole/D. > Romascanu (15 minutes) > draft-cole-netconf-robust-config-00 > > Open mike > Generic solution for the message identity issue (10 minutes) > Any other topics to discuss? > > AOB > > > ------------------------------------------------------------------------ > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From bertietf@bwijnen.net Mon Mar 2 08:58:43 2009 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 1E4413A6A71 for ; Mon, 2 Mar 2009 08:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.979 X-Spam-Level: X-Spam-Status: No, score=0.979 tagged_above=-999 required=5 tests=[AWL=-1.179, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaWTlwq9en96 for ; Mon, 2 Mar 2009 08:58:41 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 932173A6452 for ; Mon, 2 Mar 2009 08:58:41 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1LeBTu-0003Vs-7E for netconf@ietf.org; Mon, 02 Mar 2009 17:59:06 +0100 Message-ID: <918C52D1081240F8850E2750CE90A645@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Mon, 2 Mar 2009 17:58:37 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_22DF_01C99B60.82D6A300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: [Netconf] document writeup for draft-ietf-netconf-partial-lock-07.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: Mon, 02 Mar 2009 16:58:43 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_22DF_01C99B60.82D6A300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WG participants, one of the questions I need to answer as=20 document shepherd is: Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? So can those who have implementations and those who plan implementations = within the next year tell me about it so that I can report. If you want = to report confidential, pls send emial directly to me clainming you want it = treated as conmfidential and I will only "count" and not reveal your name. Bert Wijnen document shepherd for draft-ietf-netconf-partial-lock ------=_NextPart_000_22DF_01C99B60.82D6A300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
WG participants, one of the questions I need to = answer as=20
document shepherd is:
         =20 Document=20 Quality
          &n= bsp; =20 Are there existing implementations of the protocol? Have=20 a
           &n= bsp;=20 significant number of vendors indicated their plan=20 to
           &= nbsp;=20 implement the specification?
 
So can those who have implementations and those who = plan=20 implementations
within the next year tell me about it so that I can = report. If=20 you want to report
confidential, pls send emial directly to me = clainming you want=20 it treated
as conmfidential and I will only "count" and not = reveal your=20 name.
 
Bert Wijnen
document shepherd for=20 draft-ietf-netconf-partial-lock
------=_NextPart_000_22DF_01C99B60.82D6A300-- From lhotka@cesnet.cz Mon Mar 2 09:04:03 2009 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 465D63A6C1E for ; Mon, 2 Mar 2009 09:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 V1yyQXPXZ1GS for ; Mon, 2 Mar 2009 09:04:02 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C474928C28C for ; Mon, 2 Mar 2009 09:03:46 -0800 (PST) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 54C87D800C8; Mon, 2 Mar 2009 18:04:12 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49AC09AA.4030406@netconfcentral.com> References: <49AC09AA.4030406@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 02 Mar 2009 18:04:12 +0100 Message-Id: <1236013452.6428.54.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: Netconf Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 17:04:03 -0000 Andy Bierman píše v Po 02. 03. 2009 v 08:30 -0800: > I requested a short time slot to discuss > draft-bierman-netconf-module-00.txt. > In general, the WG needs to deal with the emergence > of YANG and DSDL, and the pervasiveness of XSD. I don't agree that XSD is pervasive, in the XML world the discussion about XSD versus RELAX NG is essentially over - in favor of the latter. Also, both XSD and RNG are designed to express only grammar and datatype constraints, so Schematron will be needed for all kinds of semantic rules. Here I see a clear advantage of DSDL as a coordinated set of standards. > > How will the NETCONF protocol operations be augmented to > support with-defaults or any other extension in the future? > The WG should have a plan going forward to deal with all 3 formats. > It appears that the WG is going to continue to use XSD > for normative syntax, YANG for non-normative syntax, and > unclear what role DSDL has at all. > Data modeling: It may be argued that XSD is better than RNG for this purpose, but we have YANG. Validation of XML instance data: XSD by itself is no match for DSDL. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Mon Mar 2 09:38:00 2009 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 C1DEB3A68F9 for ; Mon, 2 Mar 2009 09:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.300, 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 y7K-f7k53SAq for ; Mon, 2 Mar 2009 09:38:00 -0800 (PST) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id BEEAD3A6AE7 for ; Mon, 2 Mar 2009 09:37:59 -0800 (PST) Received: (qmail 77671 invoked from network); 2 Mar 2009 17:38:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.1 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 2 Mar 2009 17:38:25 -0000 X-YMail-OSG: KZfC4ewVM1ktyp6mPOeA4gBSR0zoiRjrpoE8uIR3TODa4pbT5DlVxq8dZewlXQLrxL4eagVCmImcp5O.2u0Ibeto_KcbFq8X36YyD7Y99mR24js8m1GTOX71kdk3dzuHyM7o6Dj6zAUBuU0464.82vns X-Yahoo-Newman-Property: ymail-3 Message-ID: <49AC1990.3040602@netconfcentral.com> Date: Mon, 02 Mar 2009 09:38:24 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Netconf] comments on draft-zhang-netconf-subtree-00 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, 02 Mar 2009 17:38:00 -0000 Hi, I just read this draft that was recently published. It seems the NETCONF WG will revisit the question: subtree or XPath? The WG decided when RFC 4741 was published that XPath was the future, and it would not be a good idea to reinvent XPath, in the form of complex subtree filtering. Although this advanced subtree filtering solution is simpler than XPath 1.0, it is also much more limited in capabilities. XPath is also an established standard outside of NETCONF, which is quite important. IMO, the better long term plan is to make :xpath mandatory. The fact that data retrieval is not the core function of NETCONF was one of the significant factors when deciding :xpath filtering should be optional. However, XPath is now used in the 'instance-identifier' built-in type, and partial-locking. Access control will almost certainly be instance-identifier based (plus optional full XPath) as well. Most importantly, the limitations of subtree filtering have a significant impact on data model design. It doesn't work on nested containers or lists, unless the filtering criteria is within direct children of the desired 'table entry' node. This fatal flaw forces data to be 'flattened' into a 2-d table, losing all the advantages of NETCONF/YANG to mirror native structures in the agent. E.g., try to construct a subtree filter to retrieve just the configuration entry in the netconf-state data model. You can't. Here is the XPath to do it: /netconf/configurations/configuration[name/candidate] IMO, subtree filtering should be deprecated, not developed further. Andy From andy@netconfcentral.com Mon Mar 2 09:48:53 2009 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 9776928C238 for ; Mon, 2 Mar 2009 09:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.150, 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 qgZIuEExJkwn for ; Mon, 2 Mar 2009 09:48:52 -0800 (PST) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 9ADBC28C293 for ; Mon, 2 Mar 2009 09:48:32 -0800 (PST) Received: (qmail 88801 invoked from network); 2 Mar 2009 17:48:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.1 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 2 Mar 2009 17:48:58 -0000 X-YMail-OSG: CkErnDwVM1lTUe_TcMJs4zNKQbWp.GsZnPReZvRW9yXIcNJnBySIFjxBQE6uyRrYcNfN0RREjHHnowbx3ZYJzwNGv39c8jiMs_wCLH07g_D.utpLW.PcEDmhaC1LZP_4XhRXSgZ4Q.TpaM88oPSgtR5J X-Yahoo-Newman-Property: ymail-3 Message-ID: <49AC1C09.7090709@netconfcentral.com> Date: Mon, 02 Mar 2009 09:48:57 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ladislav Lhotka References: <49AC09AA.4030406@netconfcentral.com> <1236013452.6428.54.camel@missotis> In-Reply-To: <1236013452.6428.54.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Netconf Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 17:48:53 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Po 02. 03. 2009 v 08:30 -0800: > >> I requested a short time slot to discuss >> draft-bierman-netconf-module-00.txt. >> In general, the WG needs to deal with the emergence >> of YANG and DSDL, and the pervasiveness of XSD. > > I don't agree that XSD is pervasive, in the XML world the discussion > about XSD versus RELAX NG is essentially over - in favor of the latter. > Also, both XSD and RNG are designed to express only grammar and datatype > constraints, so Schematron will be needed for all kinds of semantic > rules. Here I see a clear advantage of DSDL as a coordinated set of > standards. > >> How will the NETCONF protocol operations be augmented to >> support with-defaults or any other extension in the future? >> The WG should have a plan going forward to deal with all 3 formats. >> It appears that the WG is going to continue to use XSD >> for normative syntax, YANG for non-normative syntax, and >> unclear what role DSDL has at all. >> > > Data modeling: It may be argued that XSD is better than RNG for this > purpose, but we have YANG. > > Validation of XML instance data: XSD by itself is no match for DSDL. > I am not debating that RNG has better validation features than XSD, or whether the "XML world" prefers RNG over XSD. I am not taking a position one way or the other on that. (DSDL is more than RNG, BTW.) I am pointing out that in the OPS-NM area of the IETF, XSD is still quite prevalent. It also appears from my ad-hoc selection of I-Ds to read off the IETF-announce list, that XSD is still the language used to define XML syntax for protocols (operations and data). Either none of these people got the memo on the evils of XSD, or XSD suites their needs, they already know XSD, and see no reason to change right now. It seems to me that the IETF needs to recognize that simply mandating use of DSDL (by writing some charter text) is not going to work. I'm waiting to hear Plan B. > Lada > > > Andy From lhotka@cesnet.cz Mon Mar 2 11:01:12 2009 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 28A643A6867 for ; Mon, 2 Mar 2009 11:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 D7i4L1EjzEkF for ; Mon, 2 Mar 2009 11:01:11 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 363F43A6858 for ; Mon, 2 Mar 2009 11:01:11 -0800 (PST) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id F2FDCD800F1 for ; Mon, 2 Mar 2009 20:01:36 +0100 (CET) From: Ladislav Lhotka To: NETCONF WG Content-Type: text/plain; charset=UTF-8 Organization: CESNET Date: Mon, 02 Mar 2009 20:01:36 +0100 Message-Id: <1236020496.6935.4.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: [Netconf] [Fwd: New Version Notification for draft-lhotka-netconf-relaxng-00] 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, 02 Mar 2009 19:01:12 -0000 Hi, this is my contribution to the discussion about schemas in NETCONF. It's not a mere translation of the existing XSD schema but rather a modular set of schemas allowing for much stricter validation. Lada -------- Forwarded message -------- Od: IETF I-D Submission Tool Komu: lhotka@cesnet.cz Předmět: New Version Notification for draft-lhotka-netconf-relaxng-00 Datum: Mon, 2 Mar 2009 09:58:00 -0800 (PST) A new version of I-D, draft-lhotka-netconf-relaxng-00.txt has been successfuly submitted by Ladislav Lhotka and posted to the IETF repository. Filename: draft-lhotka-netconf-relaxng Revision: 00 Title: Modular RELAX NG Schema of NETCONF RPC and Protocol Operations Creation_date: 2009-03-02 WG ID: Independent Submission Number_of_pages: 24 Abstract: This memo presents a schema for NETCONF RPC and protocol operations expressed in RELAX NG (compact syntax). The schema is modular and cleanly separates the server and client part of the NETCONF vocabulary and also the schema extensions provided by optional capabilities. The modular structure improves readability but also enables selecting certain modules and assembling them into a grammar that can be used for validation of NETCONF protocol data units. The IETF Secretariat. -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mehmet.ersue@nsn.com Mon Mar 2 11:30:38 2009 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 2AE313A6C35 for ; Mon, 2 Mar 2009 11:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.453 X-Spam-Level: X-Spam-Status: No, score=-5.453 tagged_above=-999 required=5 tests=[AWL=1.145, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3trBHMq6visI for ; Mon, 2 Mar 2009 11:30:37 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id A9C313A6836 for ; Mon, 2 Mar 2009 11:30:36 -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 n22JV0D2031528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Mar 2009 20:31:00 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n22JUwmG018947; Mon, 2 Mar 2009 20:31:00 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Mar 2009 20:28:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99B6D.1BF96450" Date: Mon, 2 Mar 2009 20:28:47 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Preparing for an update of Monitoring draft WAS:FW: [Netconf] comments on netconf-monitoring-03 draft Thread-Index: AcmbBoz32kXcNUpuQeynFc5Xi17wawAZM+Bg From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 02 Mar 2009 19:28:48.0692 (UTC) FILETIME=[1C656F40:01C99B6D] Subject: [Netconf] Preparing for an update of Monitoring draft WAS:FW: comments on netconf-monitoring-03 draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 19:30:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99B6D.1BF96450 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Dear NETCONF WG, the WGLC for NETCONF Monitoring draft ended on Feb 18 but we have a useful discussion ongoing on the maillist. I think the current discussion is helpful to get the document=20 stable.=20 Mark is preparing an update for the monitoting draft for=20 submission by the . Please bring in your comments and discussion points by Thursday, March 5, EOB, so that the I-D editor has sufficient=20 time to address them in the document before cut-off date=20 on March 9. Mehmet -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Martin Bjorklund Sent: Monday, March 02, 2009 8:15 AM To: Washam.Fan@huaweisymantec.com Cc: netconf@ietf.org Subject: Re: [Netconf] comments on netconf-monitoring-03 draft WashamFan wrote: > > >> 16) Is inBadRpcs =3D=3D outRpcErrors always true? > > >> If not, why not? (If yes, why do both counters exist?) >=20 > Or inBadRpcs + inNotSupportedRpcs =3D=3D outRpcErrors ? No, for example a perfectly legal will not increment inBadRpcs or inNotSupportedRpcs, but it might still generate an rpc-error if the source config is not valid. Hmm. Re-reading the description of outRpcErrors, it seems the text is not as precise as it could be. E.g. will the counter be incremented if AND is sent? Will it be incremented if inline rpc-errors are sent? I think the conclusion is that this counter probably is not very useful as it is defined. Separate counters for each error-type might be interesting, or at least for error-type transport, rpc, and protocol. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------_=_NextPart_001_01C99B6D.1BF96450 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Preparing for an update of Monitoring draft WAS:FW: [Netconf] = comments on netconf-monitoring-03 draft

 
Dear NETCONF = WG,

the WGLC for = NETCONF Monitoring draft ended on Feb 18
but we have a = useful discussion ongoing on the maillist.
I think the = current discussion is helpful to get the document
stable. =

Mark is preparing = an update for the monitoting draft for
submission by the = .

Please bring in = your comments and discussion points by
Thursday, March 5, = EOB, so that the I-D editor has sufficient
time to address = them in the document before cut-off date
on March = 9.

Mehmet

-----Original = Message-----
From: = netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Martin = Bjorklund
Sent: Monday, March = 02, 2009 8:15 AM
To: = Washam.Fan@huaweisymantec.com
Cc: = netconf@ietf.org
Subject: Re: = [Netconf] comments on netconf-monitoring-03 draft

WashamFan = <Washam.Fan@huaweisymantec.com> wrote:
> >  = >> 16) Is inBadRpcs =3D=3D outRpcErrors always true?
> >  = >>      If not, why not?  (If yes, = why do both counters exist?)
>
> Or inBadRpcs + = inNotSupportedRpcs =3D=3D outRpcErrors ?

No, for example a = perfectly legal <validate> will not increment
inBadRpcs or = inNotSupportedRpcs, but it might still generate an
rpc-error if the = source config is not valid.

Hmm.  Re-reading = the description of outRpcErrors, it seems the text is
not as precise as it = could be.  E.g. will the counter be incremented
if <data> AND = <rpc-error> is sent?  Will it be incremented if = inline
rpc-errors are = sent?

I think the = conclusion is that this counter probably is not very
useful as it is = defined.  Separate counters for each error-type might
be interesting, or = at least for error-type transport, rpc, and
protocol.



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

------_=_NextPart_001_01C99B6D.1BF96450-- From mbj@tail-f.com Mon Mar 2 11:36:07 2009 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 A29EF3A6AE7 for ; Mon, 2 Mar 2009 11:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.113, 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 OAfd7XXcskK3 for ; Mon, 2 Mar 2009 11:36:07 -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 CF3BC3A6836 for ; Mon, 2 Mar 2009 11:36:06 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 32B7E76C50A; Mon, 2 Mar 2009 20:36:32 +0100 (CET) Date: Mon, 02 Mar 2009 20:36:31 +0100 (CET) Message-Id: <20090302.203631.21206369.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49AC09AA.4030406@netconfcentral.com> References: <49AC09AA.4030406@netconfcentral.com> X-Mailer: Mew version 6.0.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] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 19:36:07 -0000 Andy Bierman wrote: > In general, the WG needs to deal with the emergence > of YANG and DSDL, and the pervasiveness of XSD. > > How will the NETCONF protocol operations be augmented to > support with-defaults or any other extension in the future? > The WG should have a plan going forward to deal with all 3 formats. > It appears that the WG is going to continue to use XSD > for normative syntax, YANG for non-normative syntax, and > unclear what role DSDL has at all. I think we have no other options right now - XSD must be normative, but hopefully YANG will be normative for future extensions. The DSDL schemas fall out of the YANG modules. I also think that the XSD in 4741 tries to be somewhat extensible, but it's not extensible enough to handle all our current capabilities. I think a solution to this could be that we state - in text - that the XSD defines the 4741 schema only, and new capabilities are free to extend this in any way they like. The alternative of making the XSD open enough (to handle at least all current capabilities) would make it very complex, and we might not even succeed. /martin From lhotka@cesnet.cz Mon Mar 2 11:53:47 2009 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 E194328C1DC for ; Mon, 2 Mar 2009 11:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.97 X-Spam-Level: X-Spam-Status: No, score=-0.97 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 AEC1i2sdxWCW for ; Mon, 2 Mar 2009 11:53:47 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 0AC533A69E9 for ; Mon, 2 Mar 2009 11:53:47 -0800 (PST) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 02D32D800C7; Mon, 2 Mar 2009 20:54:12 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20090302.203631.21206369.mbj@tail-f.com> References: <49AC09AA.4030406@netconfcentral.com> <20090302.203631.21206369.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 02 Mar 2009 20:54:12 +0100 Message-Id: <1236023652.11851.6.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 19:53:48 -0000 Martin Bjorklund píše v Po 02. 03. 2009 v 20:36 +0100: > Andy Bierman wrote: > > In general, the WG needs to deal with the emergence > > of YANG and DSDL, and the pervasiveness of XSD. > > > > How will the NETCONF protocol operations be augmented to > > support with-defaults or any other extension in the future? > > The WG should have a plan going forward to deal with all 3 formats. > > It appears that the WG is going to continue to use XSD > > for normative syntax, YANG for non-normative syntax, and > > unclear what role DSDL has at all. > > I think we have no other options right now - XSD must be normative, > but hopefully YANG will be normative for future extensions. The DSDL > schemas fall out of the YANG modules. IMO, the NETCONF protocol and RPC vocabulary is outside the scope of YANG. For example, YANG doesn't allow to model XML attributes. > > I also think that the XSD in 4741 tries to be somewhat extensible, but > it's not extensible enough to handle all our current capabilities. > > I think a solution to this could be that we state - in text - that the > XSD defines the 4741 schema only, and new capabilities are free to > extend this in any way they like. > > The alternative of making the XSD open enough (to handle at least all > current capabilities) would make it very complex, and we might not > even succeed. The schemas in draft-lhotka-netconf-relaxng-00 do exactly that. Lada > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Mon Mar 2 12:06:10 2009 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 2048728C25C for ; Mon, 2 Mar 2009 12:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.100, 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 SS9lfEgse36e for ; Mon, 2 Mar 2009 12:06:09 -0800 (PST) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 690003A6820 for ; Mon, 2 Mar 2009 12:06:09 -0800 (PST) Received: (qmail 78140 invoked from network); 2 Mar 2009 20:06:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.1 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 2 Mar 2009 20:06:35 -0000 X-YMail-OSG: U5i.N_YVM1lt1Wm8SmwUB8yD16ci2hmhxv9X2X6Gf1ToF3fJJGDgVD2OQV9rk0RM_P.j4l4aKF5a36.GqmAOwDohTTxyEZMxllYC7GIoMtVEWYR5XkG5eZSxAP0rwrcAI9hc7HDFrz1lRVsfGZPVJ0lEJ4y5LimTEJFJzkN6k1JE6Lgbxa.l.pJjG96zia0tF9l_wVT2uPiXlWjoLJL_.A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49AC3C4A.1000802@netconfcentral.com> Date: Mon, 02 Mar 2009 12:06:34 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <49AC09AA.4030406@netconfcentral.com> <20090302.203631.21206369.mbj@tail-f.com> In-Reply-To: <20090302.203631.21206369.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 20:06:10 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> In general, the WG needs to deal with the emergence >> of YANG and DSDL, and the pervasiveness of XSD. >> >> How will the NETCONF protocol operations be augmented to >> support with-defaults or any other extension in the future? >> The WG should have a plan going forward to deal with all 3 formats. >> It appears that the WG is going to continue to use XSD >> for normative syntax, YANG for non-normative syntax, and >> unclear what role DSDL has at all. > > I think we have no other options right now - XSD must be normative, > but hopefully YANG will be normative for future extensions. The DSDL > schemas fall out of the YANG modules. > this is good; is this the official OPS-NM area policy, a NETCONF/NETMOD policy, just a NETMOD policy, or just wish-full thinking? > I also think that the XSD in 4741 tries to be somewhat extensible, but > it's not extensible enough to handle all our current capabilities. > > I think a solution to this could be that we state - in text - that the > XSD defines the 4741 schema only, and new capabilities are free to > extend this in any way they like. > > The alternative of making the XSD open enough (to handle at least all > current capabilities) would make it very complex, and we might not > even succeed. > > One obvious solution to the 'role of DSDL' question is to start including non-normative DSDL in addition to all the non-normative YANG, for all NETCONF/NETMOD documents. However, this assumes there is enough expertise to write these modules, and to review them. Simply trusting the pyang conversion of YANG to DSDL might be good enough for now, but not in the long run. But nobody is going to learn DSDL if they never see it. At this point, YANG and DSDL are both merely implementation choices, and XSD is not. Although I favor the YANG implementation choice, I think DSDL and YANG should both be included in all NETCONF/NETMOD documents. > > Andy From lhotka@cesnet.cz Mon Mar 2 12:37:03 2009 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 025743A69E8 for ; Mon, 2 Mar 2009 12:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.984 X-Spam-Level: X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 GYJlO2i9KoWG for ; Mon, 2 Mar 2009 12:37:02 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3D2DA3A6977 for ; Mon, 2 Mar 2009 12:37:02 -0800 (PST) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id DDD71D800D1; Mon, 2 Mar 2009 21:37:27 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49AC3C4A.1000802@netconfcentral.com> References: <49AC09AA.4030406@netconfcentral.com> <20090302.203631.21206369.mbj@tail-f.com> <49AC3C4A.1000802@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Mon, 02 Mar 2009 21:37:27 +0100 Message-Id: <1236026247.13403.17.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 20:37:03 -0000 Andy Bierman píše v Po 02. 03. 2009 v 12:06 -0800: > However, this assumes there is enough expertise to write > these modules, and to review them. Simply trusting the As much as I like DSDL, it won't IMO have much sense to include it as non-normative, perhaps except special cases like datatype libraries. Hancrafted schemas may be in conflict with the normative YANG module and those automatically generated will be too long and not very readable for anything but trivial modules. Someone wanting to do validation should be able take the YANG module and translate it automatically to the validation schemas. This is possible now for RELAX NG and will be soon for Schematron and DSRL. > pyang conversion of YANG to DSDL might be good enough > for now, but not in the long run. But nobody is going > to learn DSDL if they never see it. > > At this point, YANG and DSDL are both merely implementation > choices, and XSD is not. Although I favor the YANG > implementation choice, I think DSDL and YANG should both > be included in all NETCONF/NETMOD documents. I think DSDL should be ultimately used as normative for NETCONF and YANG for NETMOD. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Mon Mar 2 12:52:12 2009 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 44E713A6A6F for ; Mon, 2 Mar 2009 12:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvhAYa1WyhaQ for ; Mon, 2 Mar 2009 12:52:11 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id B224E3A68F7 for ; Mon, 2 Mar 2009 12:52:10 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSaxHFOB+oIl6/QiU1zOssa+Ld2JcUwcN@postini.com; Mon, 02 Mar 2009 12:52:38 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 2 Mar 2009 12:50:25 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Mar 2009 12:50:25 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Mar 2009 12:50:24 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Mar 2009 12:50:23 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n22KoNM41386; Mon, 2 Mar 2009 12:50:23 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n22Khg51090383; Mon, 2 Mar 2009 20:43:42 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200903022043.n22Khg51090383@idle.juniper.net> To: Andy Bierman In-Reply-To: <49AC1990.3040602@netconfcentral.com> Date: Mon, 2 Mar 2009 15:43:42 -0500 From: Phil Shafer X-OriginalArrivalTime: 02 Mar 2009 20:50:23.0819 (UTC) FILETIME=[821E89B0:01C99B78] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] comments on draft-zhang-netconf-subtree-00 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, 02 Mar 2009 20:52:12 -0000 Andy Bierman writes: >IMO, the better long term plan is to make :xpath mandatory. Sure and IMO, an even better long term plan is to make :candidate mandatory. Or a plan to make :junos manditory. ;^) Seriously, the point of NETCONF is that we have flexibility and expressiveness. Devices are not all forced into one grand universal model and are not forced to lie when we tell clients that we are something we aren't. Thanks, Phil From andy@netconfcentral.com Mon Mar 2 13:10:49 2009 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 69B6428C276 for ; Mon, 2 Mar 2009 13:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.075, 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 26aKF7copv27 for ; Mon, 2 Mar 2009 13:10:48 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id CC87328C268 for ; Mon, 2 Mar 2009 13:10:48 -0800 (PST) Received: (qmail 55130 invoked from network); 2 Mar 2009 21:11:15 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.1 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 2 Mar 2009 21:11:14 -0000 X-YMail-OSG: c06zgYIVM1nRFaUggRD616K4upEDy.0.phBqUae9PmhDFD6bK_V02O8m8pcasuPbOHsDICC7D.unqe4EgakfJAvY0_kebdAViTDbT495ONcSrVVhKVb1fkRFyBgfSr4SnRBm95MUUUM_PHhL8QAeDZlx X-Yahoo-Newman-Property: ymail-3 Message-ID: <49AC4B71.80302@netconfcentral.com> Date: Mon, 02 Mar 2009 13:11:13 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Phil Shafer References: <200903022043.n22Khg51090383@idle.juniper.net> In-Reply-To: <200903022043.n22Khg51090383@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] comments on draft-zhang-netconf-subtree-00 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, 02 Mar 2009 21:10:49 -0000 Phil Shafer wrote: > Andy Bierman writes: >> IMO, the better long term plan is to make :xpath mandatory. > > Sure and IMO, an even better long term plan is to make :candidate > mandatory. Or a plan to make :junos manditory. ;^) > > Seriously, the point of NETCONF is that we have flexibility and > expressiveness. Devices are not all forced into one grand universal > model and are not forced to lie when we tell clients that we are > something we aren't. > Not sure what these comments are supposed to mean. XPath is the standard path language for XML. It is far superior to subtree filtering. It is also widely deployed. Reinventing the features of XPath in a NETCONF-only solution seems like a low priority item which goes against the whole "use off-the-shelf XML tools" goal. Let alone the whole "Not Invented Here" thing. I don't see what :candidate or :junos has to do with this issue. > Thanks, > Phil > > Andy From andy@netconfcentral.com Mon Mar 2 13:25:56 2009 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 3977328C2A8 for ; Mon, 2 Mar 2009 13:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, 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 NBqi21X+zxfN for ; Mon, 2 Mar 2009 13:25:55 -0800 (PST) Received: from n7.bullet.mud.yahoo.com (n7.bullet.mud.yahoo.com [216.252.100.58]) by core3.amsl.com (Postfix) with SMTP id B83C028C29D for ; Mon, 2 Mar 2009 13:25:54 -0800 (PST) Received: from [68.142.194.244] by n7.bullet.mud.yahoo.com with NNFMP; 02 Mar 2009 21:26:21 -0000 Received: from [68.142.201.241] by t2.bullet.mud.yahoo.com with NNFMP; 02 Mar 2009 21:26:21 -0000 Received: from [127.0.0.1] by omp402.mail.mud.yahoo.com with NNFMP; 02 Mar 2009 21:26:21 -0000 X-Yahoo-Newman-Id: 122596.85032.bm@omp402.mail.mud.yahoo.com Received: (qmail 52416 invoked from network); 2 Mar 2009 21:26:20 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.1 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 2 Mar 2009 21:26:20 -0000 X-YMail-OSG: 8PRA6wkVM1n9raldVMLoiWy.T60US6lpZ4LMa5rDt0yAgnMeN_85zarT3gMdjp8VF.MAmKP1x6y0_NRhnKNG6JX7KBfLjeWd6jQ1n0rFUhhSWKhOGMfdeVlWJa2lmFSfapk1bNrwab9YGvjWB50OyA5X X-Yahoo-Newman-Property: ymail-3 Message-ID: <49AC4EFA.3040407@netconfcentral.com> Date: Mon, 02 Mar 2009 13:26:18 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ladislav Lhotka References: <49AC09AA.4030406@netconfcentral.com> <20090302.203631.21206369.mbj@tail-f.com> <49AC3C4A.1000802@netconfcentral.com> <1236026247.13403.17.camel@missotis> In-Reply-To: <1236026247.13403.17.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 21:25:56 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Po 02. 03. 2009 v 12:06 -0800: > >> However, this assumes there is enough expertise to write >> these modules, and to review them. Simply trusting the > > As much as I like DSDL, it won't IMO have much sense to include it as > non-normative, perhaps except special cases like datatype libraries. > Hancrafted schemas may be in conflict with the normative YANG module and > those automatically generated will be too long and not very readable for > anything but trivial modules. Someone wanting to do validation should be > able take the YANG module and translate it automatically to the > validation schemas. This is possible now for RELAX NG and will be soon > for Schematron and DSRL. > >> pyang conversion of YANG to DSDL might be good enough >> for now, but not in the long run. But nobody is going >> to learn DSDL if they never see it. >> >> At this point, YANG and DSDL are both merely implementation >> choices, and XSD is not. Although I favor the YANG >> implementation choice, I think DSDL and YANG should both >> be included in all NETCONF/NETMOD documents. > > I think DSDL should be ultimately used as normative for NETCONF and YANG > for NETMOD. > I don't see how that could ever happen unless DSDL works its way into the skill sets of the IETF community. Going from no DSDL anywhere to only DSDL everywhere (for normative XML) is not realistic. > Lada > Andy From phil@juniper.net Mon Mar 2 14:35:28 2009 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 662903A69E9 for ; Mon, 2 Mar 2009 14:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbmVzUYKH1UD for ; Mon, 2 Mar 2009 14:35:27 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id D624D3A6A1C for ; Mon, 2 Mar 2009 14:35:26 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSaxfSb+Z7H4QmGbAAOUgUZ5QbPVFLIpD@postini.com; Mon, 02 Mar 2009 14:35:54 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 2 Mar 2009 14:35:11 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Mar 2009 14:35:11 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Mar 2009 14:35:11 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 14:35:10 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n22MZ9M95569; Mon, 2 Mar 2009 14:35:10 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n22MSTNY091464; Mon, 2 Mar 2009 22:28:29 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200903022228.n22MSTNY091464@idle.juniper.net> To: Andy Bierman In-Reply-To: <49AC4B71.80302@netconfcentral.com> Date: Mon, 2 Mar 2009 17:28:28 -0500 From: Phil Shafer X-OriginalArrivalTime: 02 Mar 2009 22:35:10.0420 (UTC) FILETIME=[2539B940:01C99B87] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] comments on draft-zhang-netconf-subtree-00 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, 02 Mar 2009 22:35:28 -0000 Andy Bierman writes: >Not sure what these comments are supposed to mean. Sorry for not being clear. My point was that while you view xpath as better, this isn't a universal view. If I like :candidate, that doesn't mean that everyone will. Trying to force the rest of the world into your favorite pattern is not good. >XPath is the standard path language for XML. >It is far superior to subtree filtering. This is a blanket statement. I find subtree far superior for my needs. We can debate this, but changing 4741 to make :xpath mandatory because you like it is a non-starter imho. >It is also widely deployed. My guess is that subtree filter is more widely deployed, but I'll admit it's just a guess. Juniper's been shipping it since 2001. Thanks, Phil From andy@netconfcentral.com Mon Mar 2 14:54:38 2009 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 A15BA28C2B2 for ; Mon, 2 Mar 2009 14:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.022, 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 jAyCVG9vnmI0 for ; Mon, 2 Mar 2009 14:54:37 -0800 (PST) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id E335B28C2AB for ; Mon, 2 Mar 2009 14:54:37 -0800 (PST) Received: (qmail 55120 invoked from network); 2 Mar 2009 22:55:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.1 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 2 Mar 2009 22:55:04 -0000 X-YMail-OSG: kxOuitMVM1n7iPvWUk0WFpRXdhM_QUHGfOObodHLAbj6yHGOdD4qT8ARx_VzjJDOyHhE7S.NtyB5sQfeZg4eQC4dcQyYhRWpEP.eCBYjZKJ2zNzhnBcL4qbCYKmDNh18NUsHV2LYBlzvRKRsHyD1d.lo X-Yahoo-Newman-Property: ymail-3 Message-ID: <49AC63C6.8080700@netconfcentral.com> Date: Mon, 02 Mar 2009 14:55:02 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Phil Shafer References: <200903022228.n22MSTNY091464@idle.juniper.net> In-Reply-To: <200903022228.n22MSTNY091464@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] comments on draft-zhang-netconf-subtree-00 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, 02 Mar 2009 22:54:38 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Not sure what these comments are supposed to mean. > > Sorry for not being clear. My point was that while you view xpath > as better, this isn't a universal view. If I like :candidate, that > doesn't mean that everyone will. Trying to force the rest of the > world into your favorite pattern is not good. > >> XPath is the standard path language for XML. >> It is far superior to subtree filtering. > > This is a blanket statement. I find subtree far superior for my > needs. We can debate this, but changing 4741 to make :xpath mandatory > because you like it is a non-starter imho. > I never said I wanted to make :xpath mandatory now. It was the intent of the WG (at the time) to revisit the :xpath issue in the future to see if it was universal enough to be mandatory. I agree with you that it should remain optional for the foreseeable future. It is fine to leave subtree filtering alone and work on more important things, like the current charter. New work on NETCONF-only solutions to solved problems like XML instance document filtering is not a good use of resources. >> It is also widely deployed. > > My guess is that subtree filter is more widely deployed, > but I'll admit it's just a guess. Juniper's been shipping > it since 2001. > XPath is used outside of NETCONF, and I bet XSLT usage dwarfs NETCONF usage by a huge margin. > Thanks, > Phil > > Andy From mehmet.ersue@nsn.com Tue Mar 3 07:09:54 2009 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 9B21528C114 for ; Tue, 3 Mar 2009 07:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=-0.877, 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 l8NkanmNOnp2 for ; Tue, 3 Mar 2009 07:09:53 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 161153A6835 for ; Tue, 3 Mar 2009 07:09:52 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n23FAIdh002587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Mar 2009 16:10:18 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n23FAIt1026699; Tue, 3 Mar 2009 16:10:18 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 16:10:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Mar 2009 16:10:16 +0100 Message-ID: In-Reply-To: <49AC09AA.4030406@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Draft Agenda for IETF #74 NETCONF Session Thread-Index: AcmbVDpk5MjWYGBJRyOG1dhFVb26agAmQvYg References: <49AC09AA.4030406@netconfcentral.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" X-OriginalArrivalTime: 03 Mar 2009 15:10:17.0453 (UTC) FILETIME=[2963F1D0:01C99C12] Cc: Netconf Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 15:09:54 -0000 Hi Andy, I don't have any issues to have a slot for the I-D=20 draft-bierman-netmod-netconf-module-00.txt. As far as I can see the draft defines the NETCONF=20 model in YANG. The questions you are raising below=20 are not discussed in the document in detail. I think we should have some more discussion on=20 the document content to measure the interest of=20 the WG. Though IMO we should avoid a new discussion on=20 "which language is better". I think we had already=20 sufficient discussion on this during NETMOD=20 preparation with some conclusion. Mehmet =20 > -----Original Message----- > From: ext Andy Bierman [mailto:andy@netconfcentral.com]=20 > Sent: Monday, March 02, 2009 5:31 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: Netconf > Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session >=20 > Ersue, Mehmet (NSN - DE/Munich) wrote: > > Dear All, > > =20 > > please find an update of the NETCONF session agenda. > > =20 > > PS: The duration of the slots is subject to change. > > Presenters please confirm your slot. > > =20 >=20 >=20 > I requested a short time slot to discuss > draft-bierman-netconf-module-00.txt. > In general, the WG needs to deal with the emergence > of YANG and DSDL, and the pervasiveness of XSD. >=20 > How will the NETCONF protocol operations be augmented to > support with-defaults or any other extension in the future? > The WG should have a plan going forward to deal with all 3 formats. > It appears that the WG is going to continue to use XSD > for normative syntax, YANG for non-normative syntax, and > unclear what role DSDL has at all. >=20 >=20 >=20 > > Mehmet >=20 > Andy >=20 > > ________________________________________ > > =20 > > ** Draft - 020309 ** > > =20 > > NETCONF WG > > IETF 74, San Francisco, CA, USA > > =20 > > TUESDAY, March 24, 2009, 1300-1500 > > =20 > > WG Chairs: > > Bert Wijnen > > > Mehmet Ersue > > > =20 > > Scribes (IF no_volunteers THEN wait_forever) > > Agenda bashing (2 minutes) > > WG status review (5 minutes) > > =20 > > Chartered items: > > =20 > > 1. Partial Lock RPC for NETCONF - Balazs Lengyel (5 minutes) > > draft-ietf-netconf-partial-lock > > 2. NETCONF Monitoring Schema - Mark Scott (15 minutes)=20 > > draft-ietf-netconf-monitoring > > 3. With-defaults capability for NETCONF - A.=20 > Bierman/B. Lengyel=20 > > (20 minutes) > > draft-ietf-netconf-with-defaults > > 4. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20 = minutes) > > draft-ietf-netconf-4741bis > > =20 > > Non-Chartered items: > > =20 > > 1. Generic solution for the message integrity issue=20 > (10 minutes) > > 2. Robust Configuration Management within NETCONF -=20 > R. Cole/D.=20 > > Romascanu (15 minutes)=20 > > draft-cole-netconf-robust-config-00 > > =20 > > Open mike > > Any other topics to discuss? > > =20 > > AOB > >=20 > > =20 > -------------------------------------------------------------- > ---------- > > *From:* netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] > > *On Behalf Of *ext Ersue, Mehmet (NSN - DE/Munich) > > *Sent:* Monday, March 02, 2009 3:27 PM > > *To:* Netconf > > *Subject:* [Netconf] Draft Agenda for IETF #74 NETCONF Session > >=20 > >=20 > > Dear NETCONF WG, > >=20 > > below is the draft agenda for the NETCONF WG session > > at the IETF #74. Our session will be on Tuesday after > > the lunch break at 1300-1500. > >=20 > > Our main focus in the session will be as usual on open issue > > discussion but we have a few additional topics. > > Please send us your comments and requests concerning > > the agenda. > >=20 > > The duration of the slots is not final and subject to change. > > Presenters please confirm your slot. > >=20 > > BTW: As usual we need to organize the scribes and minute > > takers _before_ the meeting. Please help us to start the > > session on time and send us a note if you volunteer. > >=20 > > Bert & Mehmet > >=20 > > ___________________________________________________ > >=20 > > ** Draft - 020309 ** > >=20 > > NETCONF WG > > IETF 74, San Francisco, CA, USA > >=20 > > TUESDAY, March 24, 2009, 1300-1500 > >=20 > > WG Chairs: > > Bert Wijnen > > Mehmet Ersue > >=20 > > Scribes (IF no_volunteers THEN wait_forever) > > Agenda bashing (2 minutes) > > WG status review (5 minutes) > >=20 > > Chartered items: > >=20 > > 1. NETCONF Monitoring Schema - Mark Scott (15 minutes)=20 > > draft-ietf-netconf-monitoring > > 2. Partial Lock RPC for NETCONF - Balazs Lengyel=20 > (15 minutes) > > draft-ietf-netconf-partial-lock > > 3. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder=20 > (20 minutes) > > draft-ietf-netconf-4741bis > > 4. With-defaults capability for NETCONF - B.=20 > Lengyel (20 minutes) > > draft-bierman-netconf-with-defaults > >=20 > > Non-Chartered items: > >=20 > > 1. Robust Configuration Management within NETCONF=20 > - R. Cole/D. > > Romascanu (15 minutes)=20 > > draft-cole-netconf-robust-config-00 > >=20 > > Open mike > > Generic solution for the message identity issue=20 > (10 minutes) > > Any other topics to discuss? > >=20 > > AOB > >=20 > >=20 > >=20 > -------------------------------------------------------------- > ---------- > >=20 > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf >=20 >=20 >=20 >=20 From mehmet.ersue@nsn.com Tue Mar 3 07:11:31 2009 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 869A728C125 for ; Tue, 3 Mar 2009 07:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.413 X-Spam-Level: X-Spam-Status: No, score=-5.413 tagged_above=-999 required=5 tests=[AWL=1.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgNXUrw0w0zI for ; Tue, 3 Mar 2009 07:11:30 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 5F38E3A68B2 for ; Tue, 3 Mar 2009 07:11:30 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n23FBsjG002206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Mar 2009 16:11:54 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n23FBsHh031746; Tue, 3 Mar 2009 16:11:54 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 16:11:54 +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: Tue, 3 Mar 2009 16:11:53 +0100 Message-ID: In-Reply-To: <49AC4EFA.3040407@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Draft Agenda for IETF #74 NETCONF Session Thread-Index: AcmbfZkr8r+rYDquRRyamcmMVvqaggAc6N0A References: <49AC09AA.4030406@netconfcentral.com> <20090302.203631.21206369.mbj@tail-f.com> <49AC3C4A.1000802@netconfcentral.com><1236026247.13403.17.camel@missotis> <49AC4EFA.3040407@netconfcentral.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" , "Ladislav Lhotka" X-OriginalArrivalTime: 03 Mar 2009 15:11:54.0027 (UTC) FILETIME=[62F3F7B0:01C99C12] Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 15:11:31 -0000 Andy Bierman wrote: > Ladislav Lhotka wrote: > >=20 > >> pyang conversion of YANG to DSDL might be good enough > >> for now, but not in the long run. But nobody is going > >> to learn DSDL if they never see it. > >> > >> At this point, YANG and DSDL are both merely implementation > >> choices, and XSD is not. Although I favor the YANG > >> implementation choice, I think DSDL and YANG should both > >> be included in all NETCONF/NETMOD documents. Would this mean we will have 3 models with different=20 languages in each document? I'm not in favor of trying=20 to get 3 models consistent and matching to each other. We had already issues with two languages in one document. > > I think DSDL should be ultimately used as normative for=20 > NETCONF and YANG > > for NETMOD. > >=20 >=20 > I don't see how that could ever happen unless DSDL > works its way into the skill sets of the IETF community. >=20 > Going from no DSDL anywhere to only DSDL everywhere > (for normative XML) is not realistic. IIRC we decided in different meetings to keep XSD as=20 normative until YANG v1.0 gets published. This is a=20 policy I can support. Although DSDL seems to be beneficial for validation I personally see many advantages for having one=20 modeling language for NETCONF and NETMOD documents. IMO we need such a strategy to increase=20 the acceptance of our documents outside of IETF. Cheers, Mehmet From dromasca@avaya.com Tue Mar 3 07:44:37 2009 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 4D7703A6822 for ; Tue, 3 Mar 2009 07:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 TYhwf13hpvjz for ; Tue, 3 Mar 2009 07:44:36 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 76ED53A680F for ; Tue, 3 Mar 2009 07:44:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,296,1233550800"; d="scan'208";a="163372974" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Mar 2009 10:45:03 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Mar 2009 10:45:02 -0500 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: Tue, 3 Mar 2009 16:44:50 +0100 Message-ID: In-Reply-To: <49AC3C4A.1000802@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Draft Agenda for IETF #74 NETCONF Session Thread-Index: Acmbcmap44+2/q+ERbKmxthu3qjhPQAo0Q/w References: <49AC09AA.4030406@netconfcentral.com><20090302.203631.21206369.mbj@tail-f.com> <49AC3C4A.1000802@netconfcentral.com> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , "Martin Bjorklund" Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 15:44:37 -0000 =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > > I think we have no other options right now - XSD must be normative,=20 > > but hopefully YANG will be normative for future extensions.=20 > The DSDL=20 > > schemas fall out of the YANG modules. > >=20 >=20 > this is good; is this the official OPS-NM area policy, a=20 > NETCONF/NETMOD policy, just a NETMOD policy, or just=20 > wish-full thinking? Not a policy, but this is what we had in mind by the time NETMOD charter was discussed and approved. For this reason we included in the NETMOD charter 'standard mapping rules from YANG to the DSDL data modeling framework (ISO/IEC 19757) with additional annotations to preserve semantics'.=20 At this point in time however, only XSD is normative and MUST be used. If people want to include DSDL and YANG in NETCONF/NETMOD documents. for extensions they can do it, but this is optional by now.=20 Dan From dromasca@avaya.com Tue Mar 3 07:46:55 2009 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 DF4423A680F for ; Tue, 3 Mar 2009 07:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 LJfsgH5M-Pql for ; Tue, 3 Mar 2009 07:46:55 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 11D8D3A67BD for ; Tue, 3 Mar 2009 07:46:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,296,1233550800"; d="scan'208";a="163373529" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Mar 2009 10:47:21 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 Mar 2009 10:47:21 -0500 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: Tue, 3 Mar 2009 16:47:13 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Draft Agenda for IETF #74 NETCONF Session Thread-Index: AcmbfZkr8r+rYDquRRyamcmMVvqaggAc6N0AAAl9bzA= References: <49AC09AA.4030406@netconfcentral.com> <20090302.203631.21206369.mbj@tail-f.com> <49AC3C4A.1000802@netconfcentral.com><1236026247.13403.17.camel@missotis><49AC4EFA.3040407@netconfcentral.com> From: "Romascanu, Dan (Dan)" To: "Ersue, Mehmet (NSN - DE/Munich)" , "ext Andy Bierman" , "Ladislav Lhotka" Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 15:46:56 -0000 =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet=20 > IIRC we decided in different meetings to keep XSD as=20 > normative until YANG v1.0 gets published. This is a policy I=20 > can support. >=20 No other 'policy' is possible at this moment.=20 Does anybody disagree?=20 Dan From andy@netconfcentral.com Tue Mar 3 08:07:17 2009 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 C00543A68B2 for ; Tue, 3 Mar 2009 08:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.015, 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 7GxZUK+GgpQc for ; Tue, 3 Mar 2009 08:07:17 -0800 (PST) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 1C8773A68C2 for ; Tue, 3 Mar 2009 08:07:16 -0800 (PST) Received: (qmail 67863 invoked from network); 3 Mar 2009 16:07:44 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.1 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 3 Mar 2009 16:07:44 -0000 X-YMail-OSG: c7hzNqwVM1k.lakdkuGewiJltVYCA4G0rPlKVOYIGXWJ86bzYFuLqQJybe6XIHvm0hf0pcs9R.hTTkRRlQmEGoROt2or4TzFjS4eWGD5gt32XbpPxoVk7uk1rb0BIwQWhTTyDQb4C3NhI3W2sKwF8vxn X-Yahoo-Newman-Property: ymail-3 Message-ID: <49AD55CE.5010503@netconfcentral.com> Date: Tue, 03 Mar 2009 08:07:42 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <49AC09AA.4030406@netconfcentral.com> <20090302.203631.21206369.mbj@tail-f.com> <49AC3C4A.1000802@netconfcentral.com><1236026247.13403.17.camel@missotis> <49AC4EFA.3040407@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:07:17 -0000 Ersue, Mehmet (NSN - DE/Munich) wrote: > Andy Bierman wrote: >> Ladislav Lhotka wrote: >>>> pyang conversion of YANG to DSDL might be good enough >>>> for now, but not in the long run. But nobody is going >>>> to learn DSDL if they never see it. >>>> >>>> At this point, YANG and DSDL are both merely implementation >>>> choices, and XSD is not. Although I favor the YANG >>>> implementation choice, I think DSDL and YANG should both >>>> be included in all NETCONF/NETMOD documents. > > Would this mean we will have 3 models with different > languages in each document? I'm not in favor of trying > to get 3 models consistent and matching to each other. > We had already issues with two languages in one document. > >>> I think DSDL should be ultimately used as normative for >> NETCONF and YANG >>> for NETMOD. >>> >> I don't see how that could ever happen unless DSDL >> works its way into the skill sets of the IETF community. >> >> Going from no DSDL anywhere to only DSDL everywhere >> (for normative XML) is not realistic. > > IIRC we decided in different meetings to keep XSD as > normative until YANG v1.0 gets published. This is a > policy I can support. > > Although DSDL seems to be beneficial for validation > I personally see many advantages for having one > modeling language for NETCONF and NETMOD > documents. IMO we need such a strategy to increase > the acceptance of our documents outside of IETF. > So what is the role of DSDL in NETCONF? None? It is just an unrelated charter item of the NETMOD WG to produce YANG 2 DSDL mappings? > Cheers, > Mehmet > > Andy From andy@netconfcentral.com Tue Mar 3 08:12:31 2009 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 C1B7D3A684F for ; Tue, 3 Mar 2009 08:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 3+T3md+8rnBP for ; Tue, 3 Mar 2009 08:12:30 -0800 (PST) Received: from n10.bullet.mail.mud.yahoo.com (n10.bullet.mail.mud.yahoo.com [209.191.125.208]) by core3.amsl.com (Postfix) with SMTP id 8BF893A67BD for ; Tue, 3 Mar 2009 08:12:30 -0800 (PST) Received: from [68.142.194.244] by n10.bullet.mail.mud.yahoo.com with NNFMP; 03 Mar 2009 16:12:57 -0000 Received: from [68.142.201.66] by t2.bullet.mud.yahoo.com with NNFMP; 03 Mar 2009 16:12:57 -0000 Received: from [127.0.0.1] by omp418.mail.mud.yahoo.com with NNFMP; 03 Mar 2009 16:12:57 -0000 X-Yahoo-Newman-Id: 494880.81463.bm@omp418.mail.mud.yahoo.com Received: (qmail 86868 invoked from network); 3 Mar 2009 16:12:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.1 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 3 Mar 2009 16:12:56 -0000 X-YMail-OSG: kFzpzPAVM1mNU3BohGneoKOYfhrr6ebDXPJZfZ7rswj8NNdnJNKTGu7JSLbHU2qV1cdyTeIpnc1vZvkQSOcxCjT77U3Skfq_f9_uBBcz962T0ZlVsW.2DtHW5Q59XNuUNQ0xoOSc47oCiu1Iq2n224JDRmBr5tUM5JgWPDtXre4C6tMuv481HXzH X-Yahoo-Newman-Property: ymail-3 Message-ID: <49AD5706.6030505@netconfcentral.com> Date: Tue, 03 Mar 2009 08:12:54 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <49AC09AA.4030406@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Netconf Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:12:31 -0000 Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Andy, > > I don't have any issues to have a slot for the I-D > draft-bierman-netmod-netconf-module-00.txt. > > As far as I can see the draft defines the NETCONF > model in YANG. The questions you are raising below > are not discussed in the document in detail. > > I think we should have some more discussion on > the document content to measure the interest of > the WG. > > Though IMO we should avoid a new discussion on > "which language is better". I think we had already > sufficient discussion on this during NETMOD > preparation with some conclusion. > I assume the with-defaults draft will be remain on the agenda, so the issue of how to publish the updated syntax will come up. What are your thoughts on this subject? How do the WG co-Chairs think the issues related to augmentation of the NETCONF protocol should be solved? > Mehmet > Andy > >> -----Original Message----- >> From: ext Andy Bierman [mailto:andy@netconfcentral.com] >> Sent: Monday, March 02, 2009 5:31 PM >> To: Ersue, Mehmet (NSN - DE/Munich) >> Cc: Netconf >> Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session >> >> Ersue, Mehmet (NSN - DE/Munich) wrote: >>> Dear All, >>> >>> please find an update of the NETCONF session agenda. >>> >>> PS: The duration of the slots is subject to change. >>> Presenters please confirm your slot. >>> >> >> I requested a short time slot to discuss >> draft-bierman-netconf-module-00.txt. >> In general, the WG needs to deal with the emergence >> of YANG and DSDL, and the pervasiveness of XSD. >> >> How will the NETCONF protocol operations be augmented to >> support with-defaults or any other extension in the future? >> The WG should have a plan going forward to deal with all 3 formats. >> It appears that the WG is going to continue to use XSD >> for normative syntax, YANG for non-normative syntax, and >> unclear what role DSDL has at all. >> >> >> >>> Mehmet >> Andy >> >>> ________________________________________ >>> >>> ** Draft - 020309 ** >>> >>> NETCONF WG >>> IETF 74, San Francisco, CA, USA >>> >>> TUESDAY, March 24, 2009, 1300-1500 >>> >>> WG Chairs: >>> Bert Wijnen > >>> Mehmet Ersue > >>> >>> Scribes (IF no_volunteers THEN wait_forever) >>> Agenda bashing (2 minutes) >>> WG status review (5 minutes) >>> >>> Chartered items: >>> >>> 1. Partial Lock RPC for NETCONF - Balazs Lengyel (5 minutes) >>> draft-ietf-netconf-partial-lock >>> 2. NETCONF Monitoring Schema - Mark Scott (15 minutes) >>> draft-ietf-netconf-monitoring >>> 3. With-defaults capability for NETCONF - A. >> Bierman/B. Lengyel >>> (20 minutes) >>> draft-ietf-netconf-with-defaults >>> 4. 4741bis-draft - M. Bjorklund/J. Schönwälder (20 minutes) >>> draft-ietf-netconf-4741bis >>> >>> Non-Chartered items: >>> >>> 1. Generic solution for the message integrity issue >> (10 minutes) >>> 2. Robust Configuration Management within NETCONF - >> R. Cole/D. >>> Romascanu (15 minutes) >>> draft-cole-netconf-robust-config-00 >>> >>> Open mike >>> Any other topics to discuss? >>> >>> AOB >>> >>> >> -------------------------------------------------------------- >> ---------- >>> *From:* netconf-bounces@ietf.org >> [mailto:netconf-bounces@ietf.org] >>> *On Behalf Of *ext Ersue, Mehmet (NSN - DE/Munich) >>> *Sent:* Monday, March 02, 2009 3:27 PM >>> *To:* Netconf >>> *Subject:* [Netconf] Draft Agenda for IETF #74 NETCONF Session >>> >>> >>> Dear NETCONF WG, >>> >>> below is the draft agenda for the NETCONF WG session >>> at the IETF #74. Our session will be on Tuesday after >>> the lunch break at 1300-1500. >>> >>> Our main focus in the session will be as usual on open issue >>> discussion but we have a few additional topics. >>> Please send us your comments and requests concerning >>> the agenda. >>> >>> The duration of the slots is not final and subject to change. >>> Presenters please confirm your slot. >>> >>> BTW: As usual we need to organize the scribes and minute >>> takers _before_ the meeting. Please help us to start the >>> session on time and send us a note if you volunteer. >>> >>> Bert & Mehmet >>> >>> ___________________________________________________ >>> >>> ** Draft - 020309 ** >>> >>> NETCONF WG >>> IETF 74, San Francisco, CA, USA >>> >>> TUESDAY, March 24, 2009, 1300-1500 >>> >>> WG Chairs: >>> Bert Wijnen >>> Mehmet Ersue >>> >>> Scribes (IF no_volunteers THEN wait_forever) >>> Agenda bashing (2 minutes) >>> WG status review (5 minutes) >>> >>> Chartered items: >>> >>> 1. NETCONF Monitoring Schema - Mark Scott (15 minutes) >>> draft-ietf-netconf-monitoring >>> 2. Partial Lock RPC for NETCONF - Balazs Lengyel >> (15 minutes) >>> draft-ietf-netconf-partial-lock >>> 3. 4741bis-draft - M. Bjorklund/J. Schönwälder >> (20 minutes) >>> draft-ietf-netconf-4741bis >>> 4. With-defaults capability for NETCONF - B. >> Lengyel (20 minutes) >>> draft-bierman-netconf-with-defaults >>> >>> Non-Chartered items: >>> >>> 1. Robust Configuration Management within NETCONF >> - R. Cole/D. >>> Romascanu (15 minutes) >>> draft-cole-netconf-robust-config-00 >>> >>> Open mike >>> Generic solution for the message identity issue >> (10 minutes) >>> Any other topics to discuss? >>> >>> AOB >>> >>> >>> >> -------------------------------------------------------------- >> ---------- >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> >> >> > > From bertietf@bwijnen.net Tue Mar 3 08:25:50 2009 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 55CC528C1AC for ; Tue, 3 Mar 2009 08:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2k8Ho4ftFlZ for ; Tue, 3 Mar 2009 08:25:49 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 562EE3A67E1 for ; Tue, 3 Mar 2009 08:25:49 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1LeXRd-000385-DW; Tue, 03 Mar 2009 17:26:13 +0100 Message-ID: <16825FC5D9C74BC88D1A2CA2254E2A7B@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Andy Bierman" , "Ersue, Mehmet \(NSN - DE/Munich\)" References: <49AC09AA.4030406@netconfcentral.com> <20090302.203631.21206369.mbj@tail-f.com> <49AC3C4A.1000802@netconfcentral.com><1236026247.13403.17.camel@missotis><49AC4EFA.3040407@netconfcentral.com> <49AD55CE.5010503@netconfcentral.com> In-Reply-To: <49AD55CE.5010503@netconfcentral.com> Date: Tue, 3 Mar 2009 17:25:35 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_042A_01C99C25.0FE579F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:25:50 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_042A_01C99C25.0FE579F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The role of DSDL in NETCONF is non-existent I think. Bert ----- Original Message -----=20 From: Andy Bierman=20 To: Ersue, Mehmet (NSN - DE/Munich)=20 Cc: netconf@ietf.org=20 Sent: Tuesday, March 03, 2009 5:07 PM Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session Ersue, Mehmet (NSN - DE/Munich) wrote: > Andy Bierman wrote: >> Ladislav Lhotka wrote: >>>> pyang conversion of YANG to DSDL might be good enough >>>> for now, but not in the long run. But nobody is going >>>> to learn DSDL if they never see it. >>>> >>>> At this point, YANG and DSDL are both merely implementation >>>> choices, and XSD is not. Although I favor the YANG >>>> implementation choice, I think DSDL and YANG should both >>>> be included in all NETCONF/NETMOD documents. >=20 > Would this mean we will have 3 models with different=20 > languages in each document? I'm not in favor of trying=20 > to get 3 models consistent and matching to each other. > We had already issues with two languages in one document. >=20 >>> I think DSDL should be ultimately used as normative for=20 >> NETCONF and YANG >>> for NETMOD. >>> >> I don't see how that could ever happen unless DSDL >> works its way into the skill sets of the IETF community. >> >> Going from no DSDL anywhere to only DSDL everywhere >> (for normative XML) is not realistic. >=20 > IIRC we decided in different meetings to keep XSD as=20 > normative until YANG v1.0 gets published. This is a=20 > policy I can support. >=20 > Although DSDL seems to be beneficial for validation > I personally see many advantages for having one=20 > modeling language for NETCONF and NETMOD > documents. IMO we need such a strategy to increase=20 > the acceptance of our documents outside of IETF. >=20 So what is the role of DSDL in NETCONF? None? It is just an unrelated charter item of the NETMOD WG to produce YANG 2 DSDL mappings? > Cheers, > Mehmet >=20 >=20 Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_042A_01C99C25.0FE579F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The role of DSDL in NETCONF is non-existent I=20 think.
 
Bert
----- Original Message -----
From:=20 Andy=20 Bierman
Sent: Tuesday, March 03, 2009 = 5:07=20 PM
Subject: Re: [Netconf] Draft = Agenda for=20 IETF #74 NETCONF Session

Ersue, Mehmet (NSN - DE/Munich) wrote:
> Andy = Bierman=20 wrote:
>> Ladislav Lhotka wrote:
>>>> pyang = conversion=20 of YANG to DSDL might be good enough
>>>> for now, but = not in=20 the long run.  But nobody is going
>>>> to learn = DSDL if=20 they never see it.
>>>>
>>>> At this = point, YANG=20 and DSDL are both merely implementation
>>>> choices, = and XSD=20 is not.  Although I favor the YANG
>>>> = implementation=20 choice, I think DSDL and YANG should both
>>>> be = included in=20 all NETCONF/NETMOD documents.
>
> Would this mean we will = have 3=20 models with different
> languages in each document? I'm not in = favor of=20 trying
> to get 3 models consistent and matching to each = other.
>=20 We had already issues with two languages in one document.
>=20
>>> I think DSDL should be ultimately used as normative = for=20
>> NETCONF and YANG
>>> for=20 NETMOD.
>>>
>> I don't see how that could ever = happen=20 unless DSDL
>> works its way into the skill sets of the IETF=20 community.
>>
>> Going from no DSDL anywhere to only = DSDL=20 everywhere
>> (for normative XML) is not realistic.
> =
>=20 IIRC we decided in different meetings to keep XSD as
> = normative until=20 YANG v1.0 gets published. This is a
> policy I can = support.
>=20
> Although DSDL seems to be beneficial for validation
> I = personally see many advantages for having one
> modeling = language for=20 NETCONF and NETMOD
> documents. IMO we need such a strategy to = increase=20
> the acceptance of our documents outside of IETF.
>=20


So what is the role of DSDL in NETCONF?  None?
It = is just=20 an unrelated charter item of the NETMOD WG
to produce YANG 2 DSDL=20 mappings?



> Cheers,
> Mehmet
>
>=20 =

Andy

_______________________________________________
Ne= tconf=20 mailing list
Netconf@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netconf
------=_NextPart_000_042A_01C99C25.0FE579F0-- From bertietf@bwijnen.net Tue Mar 3 08:25:50 2009 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 6331C3A67E1 for ; Tue, 3 Mar 2009 08:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.27 X-Spam-Level: X-Spam-Status: No, score=-0.27 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeBqa-8T7eld for ; Tue, 3 Mar 2009 08:25:49 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 5D0F83A6835 for ; Tue, 3 Mar 2009 08:25:48 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1LeXRc-000385-HJ; Tue, 03 Mar 2009 17:26:12 +0100 Message-ID: <1F32D314B61840BBB997628DED4995F7@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Andy Bierman" , "Ersue, Mehmet \(NSN - DE/Munich\)" References: <49AC09AA.4030406@netconfcentral.com> <49AD5706.6030505@netconfcentral.com> In-Reply-To: <49AD5706.6030505@netconfcentral.com> Date: Tue, 3 Mar 2009 17:24:54 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0423_01C99C24.F7842C80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: Netconf Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:25:50 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0423_01C99C24.F7842C80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would think that any "updated syntax" would be in XSD. Unfortunately... I am not sure how you do that in XSD. Write a complete new XSD? If so, then so be it (that is my personal view). However... if any of those updates/extensions to NetConf will get published AFTER we have YANG as PS (which we expect in=20 September, right?) then we would do YANG I would think.=20 Again, personal opinion. Bert ----- Original Message -----=20 From: Andy Bierman=20 To: Ersue, Mehmet (NSN - DE/Munich)=20 Cc: Netconf=20 Sent: Tuesday, March 03, 2009 5:12 PM Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Andy, >=20 > I don't have any issues to have a slot for the I-D=20 > draft-bierman-netmod-netconf-module-00.txt. >=20 > As far as I can see the draft defines the NETCONF=20 > model in YANG. The questions you are raising below=20 > are not discussed in the document in detail. >=20 > I think we should have some more discussion on=20 > the document content to measure the interest of=20 > the WG. >=20 > Though IMO we should avoid a new discussion on=20 > "which language is better". I think we had already=20 > sufficient discussion on this during NETMOD=20 > preparation with some conclusion. >=20 I assume the with-defaults draft will be remain on the agenda, so the issue of how to publish the updated syntax will come up. What are your thoughts on this subject? How do the WG co-Chairs think the issues related to augmentation of the NETCONF protocol should be solved? > Mehmet > =20 Andy >=20 >> -----Original Message----- >> From: ext Andy Bierman [mailto:andy@netconfcentral.com]=20 >> Sent: Monday, March 02, 2009 5:31 PM >> To: Ersue, Mehmet (NSN - DE/Munich) >> Cc: Netconf >> Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session >> >> Ersue, Mehmet (NSN - DE/Munich) wrote: >>> Dear All, >>> =20 >>> please find an update of the NETCONF session agenda. >>> =20 >>> PS: The duration of the slots is subject to change. >>> Presenters please confirm your slot. >>> =20 >> >> I requested a short time slot to discuss >> draft-bierman-netconf-module-00.txt. >> In general, the WG needs to deal with the emergence >> of YANG and DSDL, and the pervasiveness of XSD. >> >> How will the NETCONF protocol operations be augmented to >> support with-defaults or any other extension in the future? >> The WG should have a plan going forward to deal with all 3 formats. >> It appears that the WG is going to continue to use XSD >> for normative syntax, YANG for non-normative syntax, and >> unclear what role DSDL has at all. >> >> >> >>> Mehmet >> Andy >> >>> ________________________________________ >>> =20 >>> ** Draft - 020309 ** >>> =20 >>> NETCONF WG >>> IETF 74, San Francisco, CA, USA >>> =20 >>> TUESDAY, March 24, 2009, 1300-1500 >>> =20 >>> WG Chairs: >>> Bert Wijnen > >>> Mehmet Ersue > >>> =20 >>> Scribes (IF no_volunteers THEN wait_forever) >>> Agenda bashing (2 minutes) >>> WG status review (5 minutes) >>> =20 >>> Chartered items: >>> =20 >>> 1. Partial Lock RPC for NETCONF - Balazs Lengyel (5 minutes) >>> draft-ietf-netconf-partial-lock >>> 2. NETCONF Monitoring Schema - Mark Scott (15 minutes)=20 >>> draft-ietf-netconf-monitoring >>> 3. With-defaults capability for NETCONF - A.=20 >> Bierman/B. Lengyel=20 >>> (20 minutes) >>> draft-ietf-netconf-with-defaults >>> 4. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20 = minutes) >>> draft-ietf-netconf-4741bis >>> =20 >>> Non-Chartered items: >>> =20 >>> 1. Generic solution for the message integrity issue=20 >> (10 minutes) >>> 2. Robust Configuration Management within NETCONF -=20 >> R. Cole/D.=20 >>> Romascanu (15 minutes)=20 >>> draft-cole-netconf-robust-config-00 >>> =20 >>> Open mike >>> Any other topics to discuss? >>> =20 >>> AOB >>> >>> =20 >> -------------------------------------------------------------- >> ---------- >>> *From:* netconf-bounces@ietf.org=20 >> [mailto:netconf-bounces@ietf.org] >>> *On Behalf Of *ext Ersue, Mehmet (NSN - DE/Munich) >>> *Sent:* Monday, March 02, 2009 3:27 PM >>> *To:* Netconf >>> *Subject:* [Netconf] Draft Agenda for IETF #74 NETCONF Session >>> >>> >>> Dear NETCONF WG, >>> >>> below is the draft agenda for the NETCONF WG session >>> at the IETF #74. Our session will be on Tuesday after >>> the lunch break at 1300-1500. >>> >>> Our main focus in the session will be as usual on open issue >>> discussion but we have a few additional topics. >>> Please send us your comments and requests concerning >>> the agenda. >>> >>> The duration of the slots is not final and subject to change. >>> Presenters please confirm your slot. >>> >>> BTW: As usual we need to organize the scribes and minute >>> takers _before_ the meeting. Please help us to start the >>> session on time and send us a note if you volunteer. >>> >>> Bert & Mehmet >>> >>> ___________________________________________________ >>> >>> ** Draft - 020309 ** >>> >>> NETCONF WG >>> IETF 74, San Francisco, CA, USA >>> >>> TUESDAY, March 24, 2009, 1300-1500 >>> >>> WG Chairs: >>> Bert Wijnen >>> Mehmet Ersue >>> >>> Scribes (IF no_volunteers THEN wait_forever) >>> Agenda bashing (2 minutes) >>> WG status review (5 minutes) >>> >>> Chartered items: >>> >>> 1. NETCONF Monitoring Schema - Mark Scott (15 minutes)=20 >>> draft-ietf-netconf-monitoring >>> 2. Partial Lock RPC for NETCONF - Balazs Lengyel=20 >> (15 minutes) >>> draft-ietf-netconf-partial-lock >>> 3. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder=20 >> (20 minutes) >>> draft-ietf-netconf-4741bis >>> 4. With-defaults capability for NETCONF - B.=20 >> Lengyel (20 minutes) >>> draft-bierman-netconf-with-defaults >>> >>> Non-Chartered items: >>> >>> 1. Robust Configuration Management within NETCONF=20 >> - R. Cole/D. >>> Romascanu (15 minutes)=20 >>> draft-cole-netconf-robust-config-00 >>> >>> Open mike >>> Generic solution for the message identity issue=20 >> (10 minutes) >>> Any other topics to discuss? >>> >>> AOB >>> >>> >>> >> -------------------------------------------------------------- >> ---------- >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> >> >> >=20 >=20 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_0423_01C99C24.F7842C80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I would think that any "updated syntax" would be in=20 XSD.
Unfortunately... I am not sure how you do that in=20 XSD.
Write a complete new XSD? If so, then so be = it
(that is my personal view).
 
However... if any of those updates/extensions to = NetConf will=20 get
published AFTER we have YANG as PS (which we expect = in=20
September, right?) then we = would do YANG I=20 would think.
Again, personal opinion.
 
Bert
----- Original Message -----
From:=20 Andy=20 Bierman
Cc: Netconf
Sent: Tuesday, March 03, 2009 = 5:12=20 PM
Subject: Re: [Netconf] Draft = Agenda for=20 IETF #74 NETCONF Session

Ersue, Mehmet (NSN - DE/Munich) wrote:
> Hi = Andy,
>=20
> I don't have any issues to have a slot for the I-D
>=20 draft-bierman-netmod-netconf-module-00.txt.
>
> As far as = I can=20 see the draft defines the NETCONF
> model in YANG. The = questions you=20 are raising below
> are not discussed in the document in=20 detail.
>
> I think we should have some more discussion = on=20
> the document content to measure the interest of
> the=20 WG.
>
> Though IMO we should avoid a new discussion on =
>=20 "which language is better". I think we had already
> sufficient = discussion on this during NETMOD
> preparation with some=20 conclusion.
>

I assume the with-defaults draft will be = remain on=20 the agenda,
so the issue of how to publish the updated syntax will = come=20 up.
What are your thoughts on this subject?
How do the WG = co-Chairs=20 think the issues related to
augmentation of the NETCONF protocol = should be=20 solved?


> Mehmet
> 

Andy

>=20
>> -----Original Message-----
>> From: ext Andy = Bierman=20 [mailto:andy@netconfcentral.com]
>> Sent: Monday, March 02, = 2009=20 5:31 PM
>> To: Ersue, Mehmet (NSN - DE/Munich)
>> = Cc:=20 Netconf
>> Subject: Re: [Netconf] Draft Agenda for IETF #74 = NETCONF=20 Session
>>
>> Ersue, Mehmet (NSN - DE/Munich)=20 wrote:
>>> Dear All,
>>>  =
>>> please=20 find an update of the NETCONF session agenda.
>>> =20
>>> PS: The duration of the slots is subject to=20 change.
>>> Presenters please confirm your=20 slot.
>>> 
>>
>> I requested a = short time=20 slot to discuss
>> = draft-bierman-netconf-module-00.txt.
>>=20 In general, the WG needs to deal with the emergence
>> of = YANG and=20 DSDL, and the pervasiveness of XSD.
>>
>> How will = the=20 NETCONF protocol operations be augmented to
>> support = with-defaults=20 or any other extension in the future?
>> The WG should have a = plan=20 going forward to deal with all 3 formats.
>> It appears that = the WG=20 is going to continue to use XSD
>> for normative syntax, YANG = for=20 non-normative syntax, and
>> unclear what role DSDL has at=20 all.
>>
>>
>>
>>> = Mehmet
>>=20 Andy
>>
>>>=20 ________________________________________
>>> =20
>>> ** Draft - 020309 **
>>>  =
>>>=20 NETCONF WG
>>> IETF 74, San Francisco, CA,=20 USA
>>> 
>>> TUESDAY, March 24, 2009,=20 1300-1500
>>> 
>>>    WG=20 Chairs:
>>>    Bert Wijnen <bertietf@bwijnen.net <mailto:bertietf@bwijnen.net>&= gt;
>>>   =20 Mehmet Ersue <mehmet.ersue@nsn.com <mailto:mehmet.ersue@nsn.com>&= gt;
>>> =20
>>>    Scribes (IF no_volunteers THEN=20 wait_forever)
>>>    Agenda bashing (2=20 minutes)
>>>    WG status review (5=20 minutes)
>>> 
>>>    = Chartered=20 items:
>>> =20
>>>       1. Partial Lock = RPC for=20 NETCONF - Balazs Lengyel (5=20 = minutes)
>>>        &= nbsp;=20 = draft-ietf-netconf-partial-lock
>>>    &n= bsp; =20 2. NETCONF Monitoring Schema - Mark Scott (15 minutes)=20 =
>>>         &nb= sp;=20 = draft-ietf-netconf-monitoring
>>>    &nbs= p; =20 3. With-defaults capability for NETCONF - A.
>> Bierman/B. = Lengyel=20
>>> (20=20 = minutes)
>>>        &= nbsp; =20 = draft-ietf-netconf-with-defaults
>>>    &= nbsp; =20 4. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20=20 = minutes)
>>>        &= nbsp; =20 draft-ietf-netconf-4741bis
>>> =20
>>>    Non-Chartered = items:
>>> =20
>>>       1. Generic = solution for=20 the message integrity issue
>> (10=20 minutes)
>>>       2. Robust = Configuration Management within NETCONF -
>> R. Cole/D.=20
>>> Romascanu (15 minutes)=20 =
>>>         &nb= sp;=20 draft-cole-netconf-robust-config-00
>>> =20
>>>    Open=20 mike
>>>       Any other = topics to=20 discuss?
>>> 
>>>   =20 AOB
>>>
>>>     =
>>=20 = --------------------------------------------------------------
>>= ;=20 ----------
>>>     *From:* netconf-bounces@ietf.org=20
>>=20 = [mailto:netconf-bounces@ietf.org]
>>>    = *On=20 Behalf Of *ext Ersue, Mehmet (NSN -=20 DE/Munich)
>>>     *Sent:* Monday, = March 02,=20 2009 3:27 PM
>>>     *To:*=20 Netconf
>>>     *Subject:* [Netconf] = Draft=20 Agenda for IETF #74 NETCONF=20 = Session
>>>
>>>
>>>   =  =20 Dear NETCONF = WG,
>>>
>>>     below=20 is the draft agenda for the NETCONF WG=20 session
>>>     at the IETF #74. Our = session=20 will be on Tuesday after
>>>     the = lunch=20 break at = 1300-1500.
>>>
>>>    =20 Our main focus in the session will be as usual on open=20 issue
>>>     discussion but we have a = few=20 additional topics.
>>>     Please send = us your=20 comments and requests = concerning
>>>     the=20 agenda.
>>>
>>>     The = duration=20 of the slots is not final and subject to=20 change.
>>>     Presenters please = confirm your=20 slot.
>>>
>>>     BTW: As = usual we=20 need to organize the scribes and=20 minute
>>>     takers _before_ the = meeting.=20 Please help us to start the
>>>     = session on=20 time and send us a note if you=20 volunteer.
>>>
>>>     = Bert &=20 Mehmet
>>>
>>>    =20 = ___________________________________________________
>>>
&g= t;>>    =20 ** Draft - 020309 = **
>>>
>>>    =20 NETCONF WG
>>>     IETF 74, San = Francisco, CA,=20 USA
>>>
>>>     TUESDAY, = March 24,=20 2009,=20 = 1300-1500
>>>
>>>     &n= bsp; =20 WG Chairs:
>>>        = Bert=20 Wijnen <bertietf@bwijnen.net>
>= >>       =20 Mehmet Ersue <mehmet.ersue@nsn.com>
>= >>
>>>       =20 Scribes (IF no_volunteers THEN=20 = wait_forever)
>>>        = Agenda=20 bashing (2 = minutes)
>>>       =20 WG status review (5=20 = minutes)
>>>
>>>     &nb= sp; =20 Chartered=20 = items:
>>>
>>>      = ;    =20 1. NETCONF Monitoring Schema - Mark Scott (15 minutes)=20 =
>>>         &nb= sp;    =20 = draft-ietf-netconf-monitoring
>>>    &nbs= p;     =20 2. Partial Lock RPC for NETCONF - Balazs Lengyel
>> (15=20 = minutes)
>>>        &= nbsp;    =20 = draft-ietf-netconf-partial-lock
>>>    &n= bsp;     =20 3. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder
>> (20=20 = minutes)
>>>        &= nbsp;     =20 = draft-ietf-netconf-4741bis
>>>     &= nbsp;    =20 4. With-defaults capability for NETCONF - B.
>> Lengyel (20=20 = minutes)
>>>        &= nbsp;     =20 = draft-bierman-netconf-with-defaults
>>>
>>> =       =20 Non-Chartered=20 = items:
>>>
>>>      = ;    =20 1. Robust Configuration Management within NETCONF
>> - R.=20 Cole/D.
>>>     Romascanu (15 minutes) = =
>>>         &nb= sp;    =20 = draft-cole-netconf-robust-config-00
>>>
>>> =       =20 Open=20 = mike
>>>         = ; =20 Generic solution for the message identity issue
>> (10=20 = minutes)
>>>        &= nbsp; =20 Any other topics to=20 = discuss?
>>>
>>>     &nb= sp; =20 AOB
>>>
>>>
>>>
>>=20 = --------------------------------------------------------------
>>= ;=20 ----------
>>>=20 _______________________________________________
>>> = Netconf=20 mailing list
>>> Netconf@ietf.org
>>> = https://www.ietf.o= rg/mailman/listinfo/netconf
>>
>>
>>
&g= t;=20
>=20 =



_______________________________________________
Netcon= f=20 mailing list
Netconf@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netconf
------=_NextPart_000_0423_01C99C24.F7842C80-- From dromasca@avaya.com Tue Mar 3 08:34:17 2009 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 50A4B28C298 for ; Tue, 3 Mar 2009 08:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2qsZdMoMu4N for ; Tue, 3 Mar 2009 08:34:15 -0800 (PST) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 35AD028C232 for ; Tue, 3 Mar 2009 08:34:15 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,296,1233550800"; d="scan'208,217";a="154064869" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 03 Mar 2009 11:34:32 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 Mar 2009 11:34:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99C1D.E1E1524E" Date: Tue, 3 Mar 2009 17:34:10 +0100 Message-ID: In-Reply-To: <1F32D314B61840BBB997628DED4995F7@BertLaptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Draft Agenda for IETF #74 NETCONF Session Thread-Index: AcmcHM02iVVSLh2gQV2GFbE1A91FxQAAIJ0A References: <49AC09AA.4030406@netconfcentral.com><49AD5706.6030505@netconfcentral.com> <1F32D314B61840BBB997628DED4995F7@BertLaptop> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , "Andy Bierman" , "Ersue, Mehmet (NSN - DE/Munich)" Cc: Netconf Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:34:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99C1D.E1E1524E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So, what is the exact proposal? =20 1. do YANG only betting on YANG timing with the risks of following a = work-in-progress syntax, and of getting stuck because of the normative = dependencies?=20 2. do both XSD and YANG, maybe in separate sections, with YANG staying = informative if YANG gets delayed?=20 =20 Dan =20 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On = Behalf Of Bert Wijnen (IETF) Sent: Tuesday, March 03, 2009 6:25 PM To: Andy Bierman; Ersue, Mehmet (NSN - DE/Munich) Cc: Netconf Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session I would think that any "updated syntax" would be in XSD. Unfortunately... I am not sure how you do that in XSD. Write a complete new XSD? If so, then so be it (that is my personal view). =20 However... if any of those updates/extensions to NetConf will get published AFTER we have YANG as PS (which we expect in=20 September, right?) then we would do YANG I would think.=20 Again, personal opinion. =20 Bert ----- Original Message -----=20 From: Andy Bierman =20 To: Ersue, Mehmet (NSN - DE/Munich) =20 Cc: Netconf =20 Sent: Tuesday, March 03, 2009 5:12 PM Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Andy, >=20 > I don't have any issues to have a slot for the I-D=20 > draft-bierman-netmod-netconf-module-00.txt. >=20 > As far as I can see the draft defines the NETCONF=20 > model in YANG. The questions you are raising below=20 > are not discussed in the document in detail. >=20 > I think we should have some more discussion on=20 > the document content to measure the interest of=20 > the WG. >=20 > Though IMO we should avoid a new discussion on=20 > "which language is better". I think we had already=20 > sufficient discussion on this during NETMOD=20 > preparation with some conclusion. >=20 =09 I assume the with-defaults draft will be remain on the agenda, so the issue of how to publish the updated syntax will come up. What are your thoughts on this subject? How do the WG co-Chairs think the issues related to augmentation of the NETCONF protocol should be solved? =09 =09 > Mehmet > =20 =09 Andy =09 >=20 >> -----Original Message----- >> From: ext Andy Bierman [mailto:andy@netconfcentral.com]=20 >> Sent: Monday, March 02, 2009 5:31 PM >> To: Ersue, Mehmet (NSN - DE/Munich) >> Cc: Netconf >> Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session >> >> Ersue, Mehmet (NSN - DE/Munich) wrote: >>> Dear All, >>> =20 >>> please find an update of the NETCONF session agenda. >>> =20 >>> PS: The duration of the slots is subject to change. >>> Presenters please confirm your slot. >>> =20 >> >> I requested a short time slot to discuss >> draft-bierman-netconf-module-00.txt. >> In general, the WG needs to deal with the emergence >> of YANG and DSDL, and the pervasiveness of XSD. >> >> How will the NETCONF protocol operations be augmented to >> support with-defaults or any other extension in the future? >> The WG should have a plan going forward to deal with all 3 formats. >> It appears that the WG is going to continue to use XSD >> for normative syntax, YANG for non-normative syntax, and >> unclear what role DSDL has at all. >> >> >> >>> Mehmet >> Andy >> >>> ________________________________________ >>> =20 >>> ** Draft - 020309 ** >>> =20 >>> NETCONF WG >>> IETF 74, San Francisco, CA, USA >>> =20 >>> TUESDAY, March 24, 2009, 1300-1500 >>> =20 >>> WG Chairs: >>> Bert Wijnen > >>> Mehmet Ersue > >>> =20 >>> Scribes (IF no_volunteers THEN wait_forever) >>> Agenda bashing (2 minutes) >>> WG status review (5 minutes) >>> =20 >>> Chartered items: >>> =20 >>> 1. Partial Lock RPC for NETCONF - Balazs Lengyel (5 minutes) >>> draft-ietf-netconf-partial-lock >>> 2. NETCONF Monitoring Schema - Mark Scott (15 minutes)=20 >>> draft-ietf-netconf-monitoring >>> 3. With-defaults capability for NETCONF - A.=20 >> Bierman/B. Lengyel=20 >>> (20 minutes) >>> draft-ietf-netconf-with-defaults >>> 4. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20 = minutes) >>> draft-ietf-netconf-4741bis >>> =20 >>> Non-Chartered items: >>> =20 >>> 1. Generic solution for the message integrity issue=20 >> (10 minutes) >>> 2. Robust Configuration Management within NETCONF -=20 >> R. Cole/D.=20 >>> Romascanu (15 minutes)=20 >>> draft-cole-netconf-robust-config-00 >>> =20 >>> Open mike >>> Any other topics to discuss? >>> =20 >>> AOB >>> >>> =20 >> -------------------------------------------------------------- >> ---------- >>> *From:* netconf-bounces@ietf.org=20 >> [mailto:netconf-bounces@ietf.org] >>> *On Behalf Of *ext Ersue, Mehmet (NSN - DE/Munich) >>> *Sent:* Monday, March 02, 2009 3:27 PM >>> *To:* Netconf >>> *Subject:* [Netconf] Draft Agenda for IETF #74 NETCONF Session >>> >>> >>> Dear NETCONF WG, >>> >>> below is the draft agenda for the NETCONF WG session >>> at the IETF #74. Our session will be on Tuesday after >>> the lunch break at 1300-1500. >>> >>> Our main focus in the session will be as usual on open issue >>> discussion but we have a few additional topics. >>> Please send us your comments and requests concerning >>> the agenda. >>> >>> The duration of the slots is not final and subject to change. >>> Presenters please confirm your slot. >>> >>> BTW: As usual we need to organize the scribes and minute >>> takers _before_ the meeting. Please help us to start the >>> session on time and send us a note if you volunteer. >>> >>> Bert & Mehmet >>> >>> ___________________________________________________ >>> >>> ** Draft - 020309 ** >>> >>> NETCONF WG >>> IETF 74, San Francisco, CA, USA >>> >>> TUESDAY, March 24, 2009, 1300-1500 >>> >>> WG Chairs: >>> Bert Wijnen >>> Mehmet Ersue >>> >>> Scribes (IF no_volunteers THEN wait_forever) >>> Agenda bashing (2 minutes) >>> WG status review (5 minutes) >>> >>> Chartered items: >>> >>> 1. NETCONF Monitoring Schema - Mark Scott (15 minutes)=20 >>> draft-ietf-netconf-monitoring >>> 2. Partial Lock RPC for NETCONF - Balazs Lengyel=20 >> (15 minutes) >>> draft-ietf-netconf-partial-lock >>> 3. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder=20 >> (20 minutes) >>> draft-ietf-netconf-4741bis >>> 4. With-defaults capability for NETCONF - B.=20 >> Lengyel (20 minutes) >>> draft-bierman-netconf-with-defaults >>> >>> Non-Chartered items: >>> >>> 1. Robust Configuration Management within NETCONF=20 >> - R. Cole/D. >>> Romascanu (15 minutes)=20 >>> draft-cole-netconf-robust-config-00 >>> >>> Open mike >>> Generic solution for the message identity issue=20 >> (10 minutes) >>> Any other topics to discuss? >>> >>> AOB >>> >>> >>> >> -------------------------------------------------------------- >> ---------- >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> >> >> >=20 >=20 =09 =09 =09 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf =09 ------_=_NextPart_001_01C99C1D.E1E1524E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
So, what is the exact=20 proposal?
 
1. do YANG only betting on YANG timing with the = risks of=20 following a work-in-progress syntax, and of getting stuck because of the = normative dependencies?
2. do both XSD and YANG, = maybe in separate=20 sections, with YANG staying informative if YANG gets delayed?=20
 
Dan
 
From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen=20 (IETF)
Sent: Tuesday, March 03, 2009 6:25 PM
To: = Andy=20 Bierman; Ersue, Mehmet (NSN - DE/Munich)
Cc:=20 Netconf
Subject: Re: [Netconf] Draft Agenda for IETF #74 = NETCONF=20 Session

I would think that any "updated syntax" would be = in=20 XSD.
Unfortunately... I am not sure how you do that in=20 XSD.
Write a complete new XSD? If so, then so be = it
(that is my personal view).
 
However... if any of those updates/extensions to = NetConf=20 will get
published AFTER we have YANG as PS (which we = expect in=20
September, right?) then we = would do YANG=20 I would think.
Again, personal opinion.
 
Bert
----- Original Message -----
From:=20 Andy=20 Bierman
Cc: Netconf
Sent: Tuesday, March 03, 2009 = 5:12=20 PM
Subject: Re: [Netconf] Draft = Agenda for=20 IETF #74 NETCONF Session

Ersue, Mehmet (NSN - DE/Munich) wrote:
> Hi=20 Andy,
>
> I don't have any issues to have a slot for = the I-D=20
> draft-bierman-netmod-netconf-module-00.txt.
> =
> As far=20 as I can see the draft defines the NETCONF
> model in YANG. = The=20 questions you are raising below
> are not discussed in the = document=20 in detail.
>
> I think we should have some more = discussion on=20
> the document content to measure the interest of
> = the=20 WG.
>
> Though IMO we should avoid a new discussion on =
>=20 "which language is better". I think we had already
> = sufficient=20 discussion on this during NETMOD
> preparation with some=20 conclusion.
>

I assume the with-defaults draft will be = remain=20 on the agenda,
so the issue of how to publish the updated syntax = will=20 come up.
What are your thoughts on this subject?
How do the WG = co-Chairs think the issues related to
augmentation of the NETCONF = protocol should be solved?


> Mehmet
> =20

Andy

>
>> -----Original = Message-----
>>=20 From: ext Andy Bierman [mailto:andy@netconfcentral.com]
>> = Sent:=20 Monday, March 02, 2009 5:31 PM
>> To: Ersue, Mehmet (NSN -=20 DE/Munich)
>> Cc: Netconf
>> Subject: Re: = [Netconf] Draft=20 Agenda for IETF #74 NETCONF Session
>>
>> Ersue, = Mehmet=20 (NSN - DE/Munich) wrote:
>>> Dear = All,
>>> =20
>>> please find an update of the NETCONF session=20 agenda.
>>> 
>>> PS: The duration of = the slots=20 is subject to change.
>>> Presenters please confirm your = slot.
>>> 
>>
>> I requested a = short=20 time slot to discuss
>>=20 draft-bierman-netconf-module-00.txt.
>> In general, the WG = needs to=20 deal with the emergence
>> of YANG and DSDL, and the = pervasiveness=20 of XSD.
>>
>> How will the NETCONF protocol = operations be=20 augmented to
>> support with-defaults or any other = extension in the=20 future?
>> The WG should have a plan going forward to deal = with all=20 3 formats.
>> It appears that the WG is going to continue = to use=20 XSD
>> for normative syntax, YANG for non-normative syntax, = and
>> unclear what role DSDL has at=20 all.
>>
>>
>>
>>> = Mehmet
>>=20 Andy
>>
>>>=20 ________________________________________
>>> =20
>>> ** Draft - 020309 **
>>>  =
>>>=20 NETCONF WG
>>> IETF 74, San Francisco, CA,=20 USA
>>> 
>>> TUESDAY, March 24, 2009,=20 1300-1500
>>> 
>>>    = WG=20 Chairs:
>>>    Bert Wijnen <bertietf@bwijnen.net <mailto:bertietf@bwijnen.net>&= gt;
>>>   =20 Mehmet Ersue <mehmet.ersue@nsn.com <mailto:mehmet.ersue@nsn.com>&= gt;
>>> =20
>>>    Scribes (IF no_volunteers THEN=20 wait_forever)
>>>    Agenda bashing (2=20 minutes)
>>>    WG status review (5=20 minutes)
>>> 
>>>    = Chartered=20 items:
>>> =20
>>>       1. Partial Lock = RPC for=20 NETCONF - Balazs Lengyel (5=20 = minutes)
>>>        &= nbsp;=20 = draft-ietf-netconf-partial-lock
>>>    &n= bsp; =20 2. NETCONF Monitoring Schema - Mark Scott (15 minutes)=20 =
>>>         &nb= sp;=20 = draft-ietf-netconf-monitoring
>>>    &nbs= p; =20 3. With-defaults capability for NETCONF - A.
>> Bierman/B. = Lengyel=20
>>> (20=20 = minutes)
>>>        &= nbsp; =20 = draft-ietf-netconf-with-defaults
>>>    &= nbsp; =20 4. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20=20 = minutes)
>>>        &= nbsp; =20 draft-ietf-netconf-4741bis
>>> =20
>>>    Non-Chartered=20 items:
>>> =20
>>>       1. Generic = solution for=20 the message integrity issue
>> (10=20 minutes)
>>>       2. = Robust=20 Configuration Management within NETCONF -
>> R. Cole/D.=20
>>> Romascanu (15 minutes)=20 =
>>>         &nb= sp;=20 draft-cole-netconf-robust-config-00
>>> =20
>>>    Open=20 mike
>>>       Any other = topics to=20 discuss?
>>> 
>>>   =20 AOB
>>>
>>>     =
>>=20 = --------------------------------------------------------------
>>= ;=20 ----------
>>>     *From:* netconf-bounces@ietf.org=20
>>=20 = [mailto:netconf-bounces@ietf.org]
>>>    = =20 *On Behalf Of *ext Ersue, Mehmet (NSN -=20 DE/Munich)
>>>     *Sent:* Monday, = March 02,=20 2009 3:27 PM
>>>     *To:*=20 Netconf
>>>     *Subject:* [Netconf] = Draft=20 Agenda for IETF #74 NETCONF=20 = Session
>>>
>>>
>>>   =  =20 Dear NETCONF = WG,
>>>
>>>    =20 below is the draft agenda for the NETCONF WG=20 session
>>>     at the IETF #74. Our = session=20 will be on Tuesday after
>>>     the = lunch=20 break at = 1300-1500.
>>>
>>>    =20 Our main focus in the session will be as usual on open=20 issue
>>>     discussion but we have = a few=20 additional topics.
>>>     Please = send us=20 your comments and requests=20 concerning
>>>     the=20 agenda.
>>>
>>>     The = duration=20 of the slots is not final and subject to=20 change.
>>>     Presenters please = confirm=20 your slot.
>>>
>>>     = BTW: As=20 usual we need to organize the scribes and=20 minute
>>>     takers _before_ the = meeting.=20 Please help us to start the
>>>     = session=20 on time and send us a note if you=20 volunteer.
>>>
>>>     = Bert=20 & Mehmet
>>>
>>>     = = ___________________________________________________
>>>
&g= t;>>    =20 ** Draft - 020309 = **
>>>
>>>    =20 NETCONF WG
>>>     IETF 74, San = Francisco,=20 CA, USA
>>>
>>>     = TUESDAY,=20 March 24, 2009,=20 = 1300-1500
>>>
>>>     &n= bsp; =20 WG Chairs:
>>>        = Bert=20 Wijnen <bertietf@bwijnen.net>
>= >>       =20 Mehmet Ersue <mehmet.ersue@nsn.com>
>= >>
>>>       =20 Scribes (IF no_volunteers THEN=20 = wait_forever)
>>>       =20 Agenda bashing (2=20 minutes)
>>>        = WG status=20 review (5=20 = minutes)
>>>
>>>     &nb= sp; =20 Chartered=20 = items:
>>>
>>>      = ;    =20 1. NETCONF Monitoring Schema - Mark Scott (15 minutes)=20 =
>>>         &nb= sp;    =20 = draft-ietf-netconf-monitoring
>>>    &nbs= p;     =20 2. Partial Lock RPC for NETCONF - Balazs Lengyel
>> (15=20 = minutes)
>>>        &= nbsp;    =20 = draft-ietf-netconf-partial-lock
>>>    &n= bsp;     =20 3. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder
>> (20=20 = minutes)
>>>        &= nbsp;     =20 = draft-ietf-netconf-4741bis
>>>     &= nbsp;    =20 4. With-defaults capability for NETCONF - B.
>> Lengyel = (20=20 = minutes)
>>>        &= nbsp;     =20 = draft-bierman-netconf-with-defaults
>>>
>>> =       =20 Non-Chartered=20 = items:
>>>
>>>      = ;    =20 1. Robust Configuration Management within NETCONF
>> - R.=20 Cole/D.
>>>     Romascanu (15 = minutes)=20 =
>>>         &nb= sp;    =20 = draft-cole-netconf-robust-config-00
>>>
>>> =       =20 Open=20 = mike
>>>         = ; =20 Generic solution for the message identity issue
>> (10=20 = minutes)
>>>        &= nbsp; =20 Any other topics to=20 = discuss?
>>>
>>>     &nb= sp; =20 AOB
>>>
>>>
>>>
>>=20 = --------------------------------------------------------------
>>= ;=20 ----------
>>>=20 _______________________________________________
>>> = Netconf=20 mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.o= rg/mailman/listinfo/netconf
>>
>>
>>
&g= t;=20
>=20 =



_______________________________________________
Netcon= f=20 mailing list
Netconf@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netconf
------_=_NextPart_001_01C99C1D.E1E1524E-- From andy@netconfcentral.com Tue Mar 3 08:38:11 2009 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 01CCA3A67E1 for ; Tue, 3 Mar 2009 08:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 qEjf2q+Zjw9E for ; Tue, 3 Mar 2009 08:38:09 -0800 (PST) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 593F73A69EC for ; Tue, 3 Mar 2009 08:37:59 -0800 (PST) Received: (qmail 93002 invoked from network); 3 Mar 2009 16:38:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.1 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 3 Mar 2009 16:38:26 -0000 X-YMail-OSG: ykOm1R8VM1lnK7Sz.e4L19Mej8c0k9itHkaj2dPk4.f0Fudy6TGI5bTbGfifCvTtuXAomR2gNfQxPROt_MFPEqKXWat0g76C9RPbwDPNpKMHSRm15Mfns05lC6cAZC0oESkmMsQyTdmICdOBzz57mfFR00RkdA_ZCYrWRrmFfS2GBz9kMeZd6sNX X-Yahoo-Newman-Property: ymail-3 Message-ID: <49AD5D00.4020909@netconfcentral.com> Date: Tue, 03 Mar 2009 08:38:24 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <49AC09AA.4030406@netconfcentral.com> <49AD5706.6030505@netconfcentral.com> <1F32D314B61840BBB997628DED4995F7@BertLaptop> In-Reply-To: <1F32D314B61840BBB997628DED4995F7@BertLaptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Netconf Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:38:11 -0000 Bert Wijnen (IETF) wrote: > I would think that any "updated syntax" would be in XSD. > Unfortunately... I am not sure how you do that in XSD. > Write a complete new XSD? If so, then so be it > (that is my personal view). > The current XSD would need to be edited, but of course this makes 'with-defaults' part of 4741-bis, not a separate document. Not a show-stopper of course, but not what the WG wanted to do. XSD has awful 'augment' capabilities. You have to know in advance exactly what you are going to need to augment, and plan for it in advance. Or you take the pyang and yangdump approach and put 'augment points', in the form of abstract elements, everywhere an augment could ever be used. Neither solution is very satisfactory. The sooner we can use YANG instead of XSD, the better. > However... if any of those updates/extensions to NetConf will get > published AFTER we have YANG as PS (which we expect in > September, right?) then we would do YANG I would think. > Again, personal opinion. > I would think other documents at PS could do that, but not a DS or Full Standard RFC. (Not a big problem. We have no YANG module RFCs at all, so they will have to start out at PS anyway.) > Bert Andy > > ----- Original Message ----- > *From:* Andy Bierman > *To:* Ersue, Mehmet (NSN - DE/Munich) > *Cc:* Netconf > *Sent:* Tuesday, March 03, 2009 5:12 PM > *Subject:* Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session > > Ersue, Mehmet (NSN - DE/Munich) wrote: > > Hi Andy, > > > > I don't have any issues to have a slot for the I-D > > draft-bierman-netmod-netconf-module-00.txt. > > > > As far as I can see the draft defines the NETCONF > > model in YANG. The questions you are raising below > > are not discussed in the document in detail. > > > > I think we should have some more discussion on > > the document content to measure the interest of > > the WG. > > > > Though IMO we should avoid a new discussion on > > "which language is better". I think we had already > > sufficient discussion on this during NETMOD > > preparation with some conclusion. > > > > I assume the with-defaults draft will be remain on the agenda, > so the issue of how to publish the updated syntax will come up. > What are your thoughts on this subject? > How do the WG co-Chairs think the issues related to > augmentation of the NETCONF protocol should be solved? > > > > Mehmet > > > > Andy > > > > >> -----Original Message----- > >> From: ext Andy Bierman [mailto:andy@netconfcentral.com] > >> Sent: Monday, March 02, 2009 5:31 PM > >> To: Ersue, Mehmet (NSN - DE/Munich) > >> Cc: Netconf > >> Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session > >> > >> Ersue, Mehmet (NSN - DE/Munich) wrote: > >>> Dear All, > >>> > >>> please find an update of the NETCONF session agenda. > >>> > >>> PS: The duration of the slots is subject to change. > >>> Presenters please confirm your slot. > >>> > >> > >> I requested a short time slot to discuss > >> draft-bierman-netconf-module-00.txt. > >> In general, the WG needs to deal with the emergence > >> of YANG and DSDL, and the pervasiveness of XSD. > >> > >> How will the NETCONF protocol operations be augmented to > >> support with-defaults or any other extension in the future? > >> The WG should have a plan going forward to deal with all 3 formats. > >> It appears that the WG is going to continue to use XSD > >> for normative syntax, YANG for non-normative syntax, and > >> unclear what role DSDL has at all. > >> > >> > >> > >>> Mehmet > >> Andy > >> > >>> ________________________________________ > >>> > >>> ** Draft - 020309 ** > >>> > >>> NETCONF WG > >>> IETF 74, San Francisco, CA, USA > >>> > >>> TUESDAY, March 24, 2009, 1300-1500 > >>> > >>> WG Chairs: > >>> Bert Wijnen > > >>> Mehmet Ersue > > >>> > >>> Scribes (IF no_volunteers THEN wait_forever) > >>> Agenda bashing (2 minutes) > >>> WG status review (5 minutes) > >>> > >>> Chartered items: > >>> > >>> 1. Partial Lock RPC for NETCONF - Balazs Lengyel (5 minutes) > >>> draft-ietf-netconf-partial-lock > >>> 2. NETCONF Monitoring Schema - Mark Scott (15 minutes) > >>> draft-ietf-netconf-monitoring > >>> 3. With-defaults capability for NETCONF - A. > >> Bierman/B. Lengyel > >>> (20 minutes) > >>> draft-ietf-netconf-with-defaults > >>> 4. 4741bis-draft - M. Bjorklund/J. Schönwälder (20 minutes) > >>> draft-ietf-netconf-4741bis > >>> > >>> Non-Chartered items: > >>> > >>> 1. Generic solution for the message integrity issue > >> (10 minutes) > >>> 2. Robust Configuration Management within NETCONF - > >> R. Cole/D. > >>> Romascanu (15 minutes) > >>> draft-cole-netconf-robust-config-00 > >>> > >>> Open mike > >>> Any other topics to discuss? > >>> > >>> AOB > >>> > >>> > >> -------------------------------------------------------------- > >> ---------- > >>> *From:* netconf-bounces@ietf.org > > >> [mailto:netconf-bounces@ietf.org] > >>> *On Behalf Of *ext Ersue, Mehmet (NSN - DE/Munich) > >>> *Sent:* Monday, March 02, 2009 3:27 PM > >>> *To:* Netconf > >>> *Subject:* [Netconf] Draft Agenda for IETF #74 NETCONF Session > >>> > >>> > >>> Dear NETCONF WG, > >>> > >>> below is the draft agenda for the NETCONF WG session > >>> at the IETF #74. Our session will be on Tuesday after > >>> the lunch break at 1300-1500. > >>> > >>> Our main focus in the session will be as usual on open issue > >>> discussion but we have a few additional topics. > >>> Please send us your comments and requests concerning > >>> the agenda. > >>> > >>> The duration of the slots is not final and subject to change. > >>> Presenters please confirm your slot. > >>> > >>> BTW: As usual we need to organize the scribes and minute > >>> takers _before_ the meeting. Please help us to start the > >>> session on time and send us a note if you volunteer. > >>> > >>> Bert & Mehmet > >>> > >>> ___________________________________________________ > >>> > >>> ** Draft - 020309 ** > >>> > >>> NETCONF WG > >>> IETF 74, San Francisco, CA, USA > >>> > >>> TUESDAY, March 24, 2009, 1300-1500 > >>> > >>> WG Chairs: > >>> Bert Wijnen > > >>> Mehmet Ersue > > >>> > >>> Scribes (IF no_volunteers THEN wait_forever) > >>> Agenda bashing (2 minutes) > >>> WG status review (5 minutes) > >>> > >>> Chartered items: > >>> > >>> 1. NETCONF Monitoring Schema - Mark Scott (15 minutes) > >>> draft-ietf-netconf-monitoring > >>> 2. Partial Lock RPC for NETCONF - Balazs Lengyel > >> (15 minutes) > >>> draft-ietf-netconf-partial-lock > >>> 3. 4741bis-draft - M. Bjorklund/J. Schönwälder > >> (20 minutes) > >>> draft-ietf-netconf-4741bis > >>> 4. With-defaults capability for NETCONF - B. > >> Lengyel (20 minutes) > >>> draft-bierman-netconf-with-defaults > >>> > >>> Non-Chartered items: > >>> > >>> 1. Robust Configuration Management within NETCONF > >> - R. Cole/D. > >>> Romascanu (15 minutes) > >>> draft-cole-netconf-robust-config-00 > >>> > >>> Open mike > >>> Generic solution for the message identity issue > >> (10 minutes) > >>> Any other topics to discuss? > >>> > >>> AOB > >>> > >>> > >>> > >> -------------------------------------------------------------- > >> ---------- > >>> _______________________________________________ > >>> Netconf mailing list > >>> Netconf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netconf > >> > >> > >> > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From bertietf@bwijnen.net Tue Mar 3 08:56:21 2009 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 47CFE3A6917 for ; Tue, 3 Mar 2009 08:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.278 X-Spam-Level: X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20Z6Eed0aL+c for ; Tue, 3 Mar 2009 08:56:19 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 100B43A679C for ; Tue, 3 Mar 2009 08:56:18 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1LeXv9-0003D4-62; Tue, 03 Mar 2009 17:56:43 +0100 Message-ID: <2EB3EB4A47F34C949484A8F8529BE3C0@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Romascanu, Dan \(Dan\)" , "Andy Bierman" , "Ersue, Mehmet \(NSN - DE/Munich\)" References: <49AC09AA.4030406@netconfcentral.com><49AD5706.6030505@netconfcentral.com> <1F32D314B61840BBB997628DED4995F7@BertLaptop> In-Reply-To: Date: Tue, 3 Mar 2009 17:55:08 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0459_01C99C29.30ABFDE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: Netconf Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:56:21 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0459_01C99C29.30ABFDE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For now... if people want to do XSD only, then I am fine with that. If they want to do YANG in addition (separate section, non-normative for = now),=20 I am fine with that. Bert ----- Original Message -----=20 From: Romascanu, Dan (Dan)=20 To: Bert Wijnen (IETF) ; Andy Bierman ; Ersue, Mehmet (NSN - = DE/Munich)=20 Cc: Netconf=20 Sent: Tuesday, March 03, 2009 5:34 PM Subject: RE: [Netconf] Draft Agenda for IETF #74 NETCONF Session So, what is the exact proposal? 1. do YANG only betting on YANG timing with the risks of following a = work-in-progress syntax, and of getting stuck because of the normative = dependencies?=20 2. do both XSD and YANG, maybe in separate sections, with YANG staying = informative if YANG gets delayed?=20 Dan -------------------------------------------------------------------------= ----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On = Behalf Of Bert Wijnen (IETF) Sent: Tuesday, March 03, 2009 6:25 PM To: Andy Bierman; Ersue, Mehmet (NSN - DE/Munich) Cc: Netconf Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session I would think that any "updated syntax" would be in XSD. Unfortunately... I am not sure how you do that in XSD. Write a complete new XSD? If so, then so be it (that is my personal view). However... if any of those updates/extensions to NetConf will get published AFTER we have YANG as PS (which we expect in=20 September, right?) then we would do YANG I would think.=20 Again, personal opinion. Bert ----- Original Message -----=20 From: Andy Bierman=20 To: Ersue, Mehmet (NSN - DE/Munich)=20 Cc: Netconf=20 Sent: Tuesday, March 03, 2009 5:12 PM Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Andy, >=20 > I don't have any issues to have a slot for the I-D=20 > draft-bierman-netmod-netconf-module-00.txt. >=20 > As far as I can see the draft defines the NETCONF=20 > model in YANG. The questions you are raising below=20 > are not discussed in the document in detail. >=20 > I think we should have some more discussion on=20 > the document content to measure the interest of=20 > the WG. >=20 > Though IMO we should avoid a new discussion on=20 > "which language is better". I think we had already=20 > sufficient discussion on this during NETMOD=20 > preparation with some conclusion. >=20 I assume the with-defaults draft will be remain on the agenda, so the issue of how to publish the updated syntax will come up. What are your thoughts on this subject? How do the WG co-Chairs think the issues related to augmentation of the NETCONF protocol should be solved? > Mehmet > =20 Andy >=20 >> -----Original Message----- >> From: ext Andy Bierman [mailto:andy@netconfcentral.com]=20 >> Sent: Monday, March 02, 2009 5:31 PM >> To: Ersue, Mehmet (NSN - DE/Munich) >> Cc: Netconf >> Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF = Session >> >> Ersue, Mehmet (NSN - DE/Munich) wrote: >>> Dear All, >>> =20 >>> please find an update of the NETCONF session agenda. >>> =20 >>> PS: The duration of the slots is subject to change. >>> Presenters please confirm your slot. >>> =20 >> >> I requested a short time slot to discuss >> draft-bierman-netconf-module-00.txt. >> In general, the WG needs to deal with the emergence >> of YANG and DSDL, and the pervasiveness of XSD. >> >> How will the NETCONF protocol operations be augmented to >> support with-defaults or any other extension in the future? >> The WG should have a plan going forward to deal with all 3 = formats. >> It appears that the WG is going to continue to use XSD >> for normative syntax, YANG for non-normative syntax, and >> unclear what role DSDL has at all. >> >> >> >>> Mehmet >> Andy >> >>> ________________________________________ >>> =20 >>> ** Draft - 020309 ** >>> =20 >>> NETCONF WG >>> IETF 74, San Francisco, CA, USA >>> =20 >>> TUESDAY, March 24, 2009, 1300-1500 >>> =20 >>> WG Chairs: >>> Bert Wijnen > >>> Mehmet Ersue > >>> =20 >>> Scribes (IF no_volunteers THEN wait_forever) >>> Agenda bashing (2 minutes) >>> WG status review (5 minutes) >>> =20 >>> Chartered items: >>> =20 >>> 1. Partial Lock RPC for NETCONF - Balazs Lengyel (5 = minutes) >>> draft-ietf-netconf-partial-lock >>> 2. NETCONF Monitoring Schema - Mark Scott (15 minutes)=20 >>> draft-ietf-netconf-monitoring >>> 3. With-defaults capability for NETCONF - A.=20 >> Bierman/B. Lengyel=20 >>> (20 minutes) >>> draft-ietf-netconf-with-defaults >>> 4. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20 = minutes) >>> draft-ietf-netconf-4741bis >>> =20 >>> Non-Chartered items: >>> =20 >>> 1. Generic solution for the message integrity issue=20 >> (10 minutes) >>> 2. Robust Configuration Management within NETCONF -=20 >> R. Cole/D.=20 >>> Romascanu (15 minutes)=20 >>> draft-cole-netconf-robust-config-00 >>> =20 >>> Open mike >>> Any other topics to discuss? >>> =20 >>> AOB >>> >>> =20 >> -------------------------------------------------------------- >> ---------- >>> *From:* netconf-bounces@ietf.org=20 >> [mailto:netconf-bounces@ietf.org] >>> *On Behalf Of *ext Ersue, Mehmet (NSN - DE/Munich) >>> *Sent:* Monday, March 02, 2009 3:27 PM >>> *To:* Netconf >>> *Subject:* [Netconf] Draft Agenda for IETF #74 NETCONF = Session >>> >>> >>> Dear NETCONF WG, >>> >>> below is the draft agenda for the NETCONF WG session >>> at the IETF #74. Our session will be on Tuesday after >>> the lunch break at 1300-1500. >>> >>> Our main focus in the session will be as usual on open = issue >>> discussion but we have a few additional topics. >>> Please send us your comments and requests concerning >>> the agenda. >>> >>> The duration of the slots is not final and subject to = change. >>> Presenters please confirm your slot. >>> >>> BTW: As usual we need to organize the scribes and minute >>> takers _before_ the meeting. Please help us to start the >>> session on time and send us a note if you volunteer. >>> >>> Bert & Mehmet >>> >>> ___________________________________________________ >>> >>> ** Draft - 020309 ** >>> >>> NETCONF WG >>> IETF 74, San Francisco, CA, USA >>> >>> TUESDAY, March 24, 2009, 1300-1500 >>> >>> WG Chairs: >>> Bert Wijnen >>> Mehmet Ersue >>> >>> Scribes (IF no_volunteers THEN wait_forever) >>> Agenda bashing (2 minutes) >>> WG status review (5 minutes) >>> >>> Chartered items: >>> >>> 1. NETCONF Monitoring Schema - Mark Scott (15 = minutes)=20 >>> draft-ietf-netconf-monitoring >>> 2. Partial Lock RPC for NETCONF - Balazs Lengyel=20 >> (15 minutes) >>> draft-ietf-netconf-partial-lock >>> 3. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder=20 >> (20 minutes) >>> draft-ietf-netconf-4741bis >>> 4. With-defaults capability for NETCONF - B.=20 >> Lengyel (20 minutes) >>> draft-bierman-netconf-with-defaults >>> >>> Non-Chartered items: >>> >>> 1. Robust Configuration Management within NETCONF=20 >> - R. Cole/D. >>> Romascanu (15 minutes)=20 >>> draft-cole-netconf-robust-config-00 >>> >>> Open mike >>> Generic solution for the message identity issue=20 >> (10 minutes) >>> Any other topics to discuss? >>> >>> AOB >>> >>> >>> >> -------------------------------------------------------------- >> ---------- >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> >> >> >=20 >=20 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_0459_01C99C29.30ABFDE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
For now... if people want to do XSD only, then I am = fine with=20 that.
If they want to do YANG in addition (separate = section,=20 non-normative for now),
I am fine with that.
 
Bert
----- Original Message -----
From:=20 Romascanu, Dan=20 (Dan)
Cc: Netconf
Sent: Tuesday, March 03, 2009 = 5:34=20 PM
Subject: RE: [Netconf] Draft = Agenda for=20 IETF #74 NETCONF Session

So, what is the exact=20 proposal?
 
1. do YANG only betting on YANG timing with the = risks of=20 following a work-in-progress syntax, and of getting stuck because of = the=20 normative dependencies?
2. do both XSD and YANG, = maybe in=20 separate sections, with YANG staying informative if YANG gets delayed? =
 
Dan
 
From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen=20 (IETF)
Sent: Tuesday, March 03, 2009 6:25 PM
To: = Andy=20 Bierman; Ersue, Mehmet (NSN - DE/Munich)
Cc:=20 Netconf
Subject: Re: [Netconf] Draft Agenda for IETF #74 = NETCONF=20 Session

I would think that any "updated syntax" would be = in=20 XSD.
Unfortunately... I am not sure how you do that = in=20 XSD.
Write a complete new XSD? If so, then so be=20 it
(that is my personal view).
 
However... if any of those updates/extensions to = NetConf=20 will get
published AFTER we have YANG as PS (which we = expect in=20
September, right?) then we = would do=20 YANG I would think.
Again, personal opinion.
 
Bert
----- Original Message ----- =
From:=20 Andy Bierman
Cc: Netconf
Sent: Tuesday, March 03, = 2009 5:12=20 PM
Subject: Re: [Netconf] = Draft Agenda=20 for IETF #74 NETCONF Session

Ersue, Mehmet (NSN - DE/Munich) wrote:
> Hi=20 Andy,
>
> I don't have any issues to have a slot for = the I-D=20
> draft-bierman-netmod-netconf-module-00.txt.
> =
> As=20 far as I can see the draft defines the NETCONF
> model in = YANG. The=20 questions you are raising below
> are not discussed in the = document=20 in detail.
>
> I think we should have some more = discussion on=20
> the document content to measure the interest of
> = the=20 WG.
>
> Though IMO we should avoid a new discussion = on=20
> "which language is better". I think we had already =
>=20 sufficient discussion on this during NETMOD
> preparation = with some=20 conclusion.
>

I assume the with-defaults draft will = be=20 remain on the agenda,
so the issue of how to publish the = updated syntax=20 will come up.
What are your thoughts on this subject?
How do = the WG=20 co-Chairs think the issues related to
augmentation of the = NETCONF=20 protocol should be solved?


> Mehmet
> =20

Andy

>
>> -----Original=20 Message-----
>> From: ext Andy Bierman=20 [mailto:andy@netconfcentral.com]
>> Sent: Monday, March = 02, 2009=20 5:31 PM
>> To: Ersue, Mehmet (NSN - = DE/Munich)
>> Cc:=20 Netconf
>> Subject: Re: [Netconf] Draft Agenda for IETF = #74=20 NETCONF Session
>>
>> Ersue, Mehmet (NSN - = DE/Munich)=20 wrote:
>>> Dear All,
>>>  =
>>>=20 please find an update of the NETCONF session = agenda.
>>> =20
>>> PS: The duration of the slots is subject to=20 change.
>>> Presenters please confirm your=20 slot.
>>> 
>>
>> I requested a = short=20 time slot to discuss
>>=20 draft-bierman-netconf-module-00.txt.
>> In general, the = WG needs=20 to deal with the emergence
>> of YANG and DSDL, and the=20 pervasiveness of XSD.
>>
>> How will the NETCONF = protocol operations be augmented to
>> support = with-defaults or=20 any other extension in the future?
>> The WG should have = a plan=20 going forward to deal with all 3 formats.
>> It appears = that the=20 WG is going to continue to use XSD
>> for normative = syntax, YANG=20 for non-normative syntax, and
>> unclear what role DSDL = has at=20 all.
>>
>>
>>
>>>=20 Mehmet
>> Andy
>>
>>>=20 ________________________________________
>>> =20
>>> ** Draft - 020309 **
>>> =20
>>> NETCONF WG
>>> IETF 74, San = Francisco, CA,=20 USA
>>> 
>>> TUESDAY, March 24, = 2009,=20 1300-1500
>>> 
>>>    = WG=20 Chairs:
>>>    Bert Wijnen <bertietf@bwijnen.net = <mailto:bertietf@bwijnen.net>&= gt;
>>>   =20 Mehmet Ersue <mehmet.ersue@nsn.com = <mailto:mehmet.ersue@nsn.com>&= gt;
>>> =20
>>>    Scribes (IF no_volunteers THEN=20 wait_forever)
>>>    Agenda bashing (2=20 minutes)
>>>    WG status review (5=20 minutes)
>>> 
>>>   =20 Chartered items:
>>> =20
>>>       1. Partial = Lock RPC=20 for NETCONF - Balazs Lengyel (5=20 = minutes)
>>>        &= nbsp;=20 = draft-ietf-netconf-partial-lock
>>>    &n= bsp; =20 2. NETCONF Monitoring Schema - Mark Scott (15 minutes)=20 =
>>>         &nb= sp;=20 = draft-ietf-netconf-monitoring
>>>    &nbs= p; =20 3. With-defaults capability for NETCONF - A.
>> = Bierman/B.=20 Lengyel
>>> (20=20 = minutes)
>>>        &= nbsp; =20 = draft-ietf-netconf-with-defaults
>>>    &= nbsp; =20 4. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20=20 = minutes)
>>>        &= nbsp; =20 draft-ietf-netconf-4741bis
>>> =20
>>>    Non-Chartered=20 items:
>>> =20
>>>       1. Generic = solution=20 for the message integrity issue
>> (10=20 minutes)
>>>       2. = Robust=20 Configuration Management within NETCONF -
>> R. Cole/D.=20
>>> Romascanu (15 minutes)=20 =
>>>         &nb= sp;=20 draft-cole-netconf-robust-config-00
>>> =20
>>>    Open=20 mike
>>>       Any other = topics=20 to discuss?
>>>  =
>>>   =20 AOB
>>>
>>>     =
>>=20 = --------------------------------------------------------------
>>= ;=20 ----------
>>>     *From:* netconf-bounces@ietf.org=20
>>=20 = [mailto:netconf-bounces@ietf.org]
>>>    = =20 *On Behalf Of *ext Ersue, Mehmet (NSN -=20 DE/Munich)
>>>     *Sent:* Monday, = March=20 02, 2009 3:27 PM
>>>     *To:*=20 Netconf
>>>     *Subject:* = [Netconf] Draft=20 Agenda for IETF #74 NETCONF=20 = Session
>>>
>>>
>>>   =  =20 Dear NETCONF = WG,
>>>
>>>    =20 below is the draft agenda for the NETCONF WG=20 session
>>>     at the IETF #74. = Our=20 session will be on Tuesday = after
>>>    =20 the lunch break at=20 1300-1500.
>>>
>>>     = Our=20 main focus in the session will be as usual on open=20 issue
>>>     discussion but we = have a few=20 additional topics.
>>>     Please = send us=20 your comments and requests=20 concerning
>>>     the=20 agenda.
>>>
>>>     = The=20 duration of the slots is not final and subject to=20 change.
>>>     Presenters please = confirm=20 your slot.
>>>
>>>     = BTW: As=20 usual we need to organize the scribes and=20 minute
>>>     takers _before_ the = meeting. Please help us to start=20 the
>>>     session on time and = send us a=20 note if you=20 volunteer.
>>>
>>>     = Bert=20 & = Mehmet
>>>
>>>    =20 = ___________________________________________________
>>>
&g= t;>>    =20 ** Draft - 020309=20 **
>>>
>>>     NETCONF = WG
>>>     IETF 74, San Francisco, = CA,=20 USA
>>>
>>>     = TUESDAY, March=20 24, 2009,=20 = 1300-1500
>>>
>>>     &n= bsp; =20 WG = Chairs:
>>>        Bert=20 Wijnen <bertietf@bwijnen.net>
>= >>       =20 Mehmet Ersue <mehmet.ersue@nsn.com>
>= >>
>>>       =20 Scribes (IF no_volunteers THEN=20 = wait_forever)
>>>       =20 Agenda bashing (2=20 minutes)
>>>        = WG=20 status review (5=20 = minutes)
>>>
>>>     &nb= sp; =20 Chartered=20 = items:
>>>
>>>      = ;    =20 1. NETCONF Monitoring Schema - Mark Scott (15 minutes)=20 =
>>>         &nb= sp;    =20 = draft-ietf-netconf-monitoring
>>>    &nbs= p;     =20 2. Partial Lock RPC for NETCONF - Balazs Lengyel
>> (15=20 = minutes)
>>>        &= nbsp;    =20 = draft-ietf-netconf-partial-lock
>>>    &n= bsp;     =20 3. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder
>> = (20=20 = minutes)
>>>        &= nbsp;     =20 = draft-ietf-netconf-4741bis
>>>     &= nbsp;    =20 4. With-defaults capability for NETCONF - B.
>> Lengyel = (20=20 = minutes)
>>>        &= nbsp;     =20 = draft-bierman-netconf-with-defaults
>>>
>>> =       =20 Non-Chartered=20 = items:
>>>
>>>      = ;    =20 1. Robust Configuration Management within NETCONF
>> - = R.=20 Cole/D.
>>>     Romascanu (15 = minutes)=20 =
>>>         &nb= sp;    =20 = draft-cole-netconf-robust-config-00
>>>
>>> =       =20 Open=20 = mike
>>>         = ; =20 Generic solution for the message identity issue
>> (10=20 = minutes)
>>>        &= nbsp; =20 Any other topics to=20 = discuss?
>>>
>>>     &nb= sp; =20 AOB
>>>
>>>
>>>
>>=20 = --------------------------------------------------------------
>>= ;=20 ----------
>>>=20 _______________________________________________
>>> = Netconf=20 mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.o= rg/mailman/listinfo/netconf
>>
>>
>>
&g= t;=20
>=20 =



_______________________________________________
Netcon= f=20 mailing list
Netconf@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netconf
------=_NextPart_000_0459_01C99C29.30ABFDE0-- From andy@netconfcentral.com Tue Mar 3 08:57:25 2009 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 218F63A6917 for ; Tue, 3 Mar 2009 08:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 CenxxXeps27E for ; Tue, 3 Mar 2009 08:57:24 -0800 (PST) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 04ED93A679C for ; Tue, 3 Mar 2009 08:57:24 -0800 (PST) Received: (qmail 13889 invoked from network); 3 Mar 2009 16:57:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.96.1 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 3 Mar 2009 16:57:50 -0000 X-YMail-OSG: P5HcQ5EVM1mrNvtyxxivPaNtCXWA51XJ449.TRSxvbASnWa3p2_O35qatjXDW0tb7hrsM5ZefhBI3rUBOoBrSkFTJ_.yQ7TQL9dvcpeMV7ZF_15cxRU3tnWlFfVxlUQn1wu5T36a7iJ420JLEJAOPBY7REPJxLNev_eupR9v8_NRQQ3RCZoshuzr X-Yahoo-Newman-Property: ymail-3 Message-ID: <49AD618D.3070007@netconfcentral.com> Date: Tue, 03 Mar 2009 08:57:49 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <49AC09AA.4030406@netconfcentral.com><49AD5706.6030505@netconfcentral.com> <1F32D314B61840BBB997628DED4995F7@BertLaptop> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Netconf Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:57:25 -0000 Romascanu, Dan (Dan) wrote: > */So, what is the exact proposal?/* > > */1. do YANG only betting on YANG timing with the risks of following a > work-in-progress syntax, and of getting stuck because of the normative > dependencies? /* > */2. do /**/both XSD and YANG, maybe in separate sections, with YANG > staying informative if YANG gets delayed? /* IMO - (2) There is a 3rd XSD option I didn't mention before, which is to add 'augment points' to each of the RPC operations in 4741-bis. This allows for any 'with-defaults' type of extension, forever. Very limited augments, but easy to do, and will permit independent document publication of the extensions. I prefer a base document + extension RFCs, only because of the way the IETF standards track works. A monolithic document can cycle at Proposed Standard status forever. > *//* > */Dan/* > *//* Andy > ------------------------------------------------------------------------ > *From:* netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] *On > Behalf Of *Bert Wijnen (IETF) > *Sent:* Tuesday, March 03, 2009 6:25 PM > *To:* Andy Bierman; Ersue, Mehmet (NSN - DE/Munich) > *Cc:* Netconf > *Subject:* Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session > > I would think that any "updated syntax" would be in XSD. > Unfortunately... I am not sure how you do that in XSD. > Write a complete new XSD? If so, then so be it > (that is my personal view). > > However... if any of those updates/extensions to NetConf will get > published AFTER we have YANG as PS (which we expect in > September, right?) then we would do YANG I would think. > Again, personal opinion. > > Bert > > ----- Original Message ----- > *From:* Andy Bierman > *To:* Ersue, Mehmet (NSN - DE/Munich) > *Cc:* Netconf > *Sent:* Tuesday, March 03, 2009 5:12 PM > *Subject:* Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session > > Ersue, Mehmet (NSN - DE/Munich) wrote: > > Hi Andy, > > > > I don't have any issues to have a slot for the I-D > > draft-bierman-netmod-netconf-module-00.txt. > > > > As far as I can see the draft defines the NETCONF > > model in YANG. The questions you are raising below > > are not discussed in the document in detail. > > > > I think we should have some more discussion on > > the document content to measure the interest of > > the WG. > > > > Though IMO we should avoid a new discussion on > > "which language is better". I think we had already > > sufficient discussion on this during NETMOD > > preparation with some conclusion. > > > > I assume the with-defaults draft will be remain on the agenda, > so the issue of how to publish the updated syntax will come up. > What are your thoughts on this subject? > How do the WG co-Chairs think the issues related to > augmentation of the NETCONF protocol should be solved? > > > > Mehmet > > > > Andy > > > > >> -----Original Message----- > >> From: ext Andy Bierman [mailto:andy@netconfcentral.com] > >> Sent: Monday, March 02, 2009 5:31 PM > >> To: Ersue, Mehmet (NSN - DE/Munich) > >> Cc: Netconf > >> Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session > >> > >> Ersue, Mehmet (NSN - DE/Munich) wrote: > >>> Dear All, > >>> > >>> please find an update of the NETCONF session agenda. > >>> > >>> PS: The duration of the slots is subject to change. > >>> Presenters please confirm your slot. > >>> > >> > >> I requested a short time slot to discuss > >> draft-bierman-netconf-module-00.txt. > >> In general, the WG needs to deal with the emergence > >> of YANG and DSDL, and the pervasiveness of XSD. > >> > >> How will the NETCONF protocol operations be augmented to > >> support with-defaults or any other extension in the future? > >> The WG should have a plan going forward to deal with all 3 > formats. > >> It appears that the WG is going to continue to use XSD > >> for normative syntax, YANG for non-normative syntax, and > >> unclear what role DSDL has at all. > >> > >> > >> > >>> Mehmet > >> Andy > >> > >>> ________________________________________ > >>> > >>> ** Draft - 020309 ** > >>> > >>> NETCONF WG > >>> IETF 74, San Francisco, CA, USA > >>> > >>> TUESDAY, March 24, 2009, 1300-1500 > >>> > >>> WG Chairs: > >>> Bert Wijnen > > >>> Mehmet Ersue > > >>> > >>> Scribes (IF no_volunteers THEN wait_forever) > >>> Agenda bashing (2 minutes) > >>> WG status review (5 minutes) > >>> > >>> Chartered items: > >>> > >>> 1. Partial Lock RPC for NETCONF - Balazs Lengyel (5 > minutes) > >>> draft-ietf-netconf-partial-lock > >>> 2. NETCONF Monitoring Schema - Mark Scott (15 minutes) > >>> draft-ietf-netconf-monitoring > >>> 3. With-defaults capability for NETCONF - A. > >> Bierman/B. Lengyel > >>> (20 minutes) > >>> draft-ietf-netconf-with-defaults > >>> 4. 4741bis-draft - M. Bjorklund/J. Schönwälder (20 > minutes) > >>> draft-ietf-netconf-4741bis > >>> > >>> Non-Chartered items: > >>> > >>> 1. Generic solution for the message integrity issue > >> (10 minutes) > >>> 2. Robust Configuration Management within NETCONF - > >> R. Cole/D. > >>> Romascanu (15 minutes) > >>> draft-cole-netconf-robust-config-00 > >>> > >>> Open mike > >>> Any other topics to discuss? > >>> > >>> AOB > >>> > >>> > >> -------------------------------------------------------------- > >> ---------- > >>> *From:* netconf-bounces@ietf.org > > >> [mailto:netconf-bounces@ietf.org] > >>> *On Behalf Of *ext Ersue, Mehmet (NSN - DE/Munich) > >>> *Sent:* Monday, March 02, 2009 3:27 PM > >>> *To:* Netconf > >>> *Subject:* [Netconf] Draft Agenda for IETF #74 NETCONF > Session > >>> > >>> > >>> Dear NETCONF WG, > >>> > >>> below is the draft agenda for the NETCONF WG session > >>> at the IETF #74. Our session will be on Tuesday after > >>> the lunch break at 1300-1500. > >>> > >>> Our main focus in the session will be as usual on open > issue > >>> discussion but we have a few additional topics. > >>> Please send us your comments and requests concerning > >>> the agenda. > >>> > >>> The duration of the slots is not final and subject to > change. > >>> Presenters please confirm your slot. > >>> > >>> BTW: As usual we need to organize the scribes and minute > >>> takers _before_ the meeting. Please help us to start the > >>> session on time and send us a note if you volunteer. > >>> > >>> Bert & Mehmet > >>> > >>> ___________________________________________________ > >>> > >>> ** Draft - 020309 ** > >>> > >>> NETCONF WG > >>> IETF 74, San Francisco, CA, USA > >>> > >>> TUESDAY, March 24, 2009, 1300-1500 > >>> > >>> WG Chairs: > >>> Bert Wijnen > > >>> Mehmet Ersue > > >>> > >>> Scribes (IF no_volunteers THEN wait_forever) > >>> Agenda bashing (2 minutes) > >>> WG status review (5 minutes) > >>> > >>> Chartered items: > >>> > >>> 1. NETCONF Monitoring Schema - Mark Scott (15 > minutes) > >>> draft-ietf-netconf-monitoring > >>> 2. Partial Lock RPC for NETCONF - Balazs Lengyel > >> (15 minutes) > >>> draft-ietf-netconf-partial-lock > >>> 3. 4741bis-draft - M. Bjorklund/J. Schönwälder > >> (20 minutes) > >>> draft-ietf-netconf-4741bis > >>> 4. With-defaults capability for NETCONF - B. > >> Lengyel (20 minutes) > >>> draft-bierman-netconf-with-defaults > >>> > >>> Non-Chartered items: > >>> > >>> 1. Robust Configuration Management within NETCONF > >> - R. Cole/D. > >>> Romascanu (15 minutes) > >>> draft-cole-netconf-robust-config-00 > >>> > >>> Open mike > >>> Generic solution for the message identity issue > >> (10 minutes) > >>> Any other topics to discuss? > >>> > >>> AOB > >>> > >>> > >>> > >> -------------------------------------------------------------- > >> ---------- > >>> _______________________________________________ > >>> Netconf mailing list > >>> Netconf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netconf > >> > >> > >> > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From mehmet.ersue@nsn.com Tue Mar 3 10:09:11 2009 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 2170B3A6A07 for ; Tue, 3 Mar 2009 10:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.492 X-Spam-Level: X-Spam-Status: No, score=-5.492 tagged_above=-999 required=5 tests=[AWL=1.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQ0pfqgQgok8 for ; Tue, 3 Mar 2009 10:09:09 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 6B3353A69CE for ; Tue, 3 Mar 2009 10:09:07 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n23I9UkG003929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Mar 2009 19:09:30 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n23I9UlG027950; Tue, 3 Mar 2009 19:09:30 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 19:09:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99C2B.30C7A6F3" Date: Tue, 3 Mar 2009 19:09:27 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Draft Agenda for IETF #74 NETCONF Session Thread-Index: AcmcHM02iVVSLh2gQV2GFbE1A91FxQAAIJ0AAAKaOZA= References: <49AC09AA.4030406@netconfcentral.com><49AD5706.6030505@netconfcentral.com> <1F32D314B61840BBB997628DED4995F7@BertLaptop> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Romascanu, Dan (Dan)" , "Bert Wijnen (IETF)" , "Andy Bierman" X-OriginalArrivalTime: 03 Mar 2009 18:09:29.0977 (UTC) FILETIME=[3264E690:01C99C2B] Cc: Netconf Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 18:09:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99C2B.30C7A6F3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, =20 I agree with Bert. Also Martin stated the=20 same a bit earlier: =20 Martin wrote: > I think we have no other options right now - XSD must be normative, > but hopefully YANG will be normative for future extensions. The DSDL > schemas fall out of the YANG modules. =20 Everything else would be too much effort. I=20 can think on three options: A) do XSD-only=20 B) do both XSD (normative) and YANG=20 C) wait on YANG =20 My preferences are A) or B) for fast publication=20 of documents. The author should be allowed=20 to decide whether he/she supports YANG=20 model additionally. He/she might also get=20 some support from YANG guys. =20 I strongly support the use of one modeling=20 language in NETCONF _and_ NETMOD documents=20 'in the future'.=20 IMO this has different benefits, e.g. avoiding=20 complexity for translations or augmentations,=20 avoiding inconsistencies with two languages=20 in one document, faster learning curve,=20 increasing acceptance outside of IETF. Cheers, Mehmet=20 =20 ________________________________ From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Tuesday, March 03, 2009 5:34 PM To: Bert Wijnen (IETF); Andy Bierman; Ersue, Mehmet (NSN - DE/Munich) Cc: Netconf Subject: RE: [Netconf] Draft Agenda for IETF #74 NETCONF Session =09 =09 So, what is the exact proposal? =20 1. do YANG only betting on YANG timing with the risks of following a = work-in-progress syntax, and of getting stuck because of the normative = dependencies?=20 2. do both XSD and YANG, maybe in separate sections, with YANG staying = informative if YANG gets delayed?=20 =20 Dan =20 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On = Behalf Of Bert Wijnen (IETF) Sent: Tuesday, March 03, 2009 6:25 PM To: Andy Bierman; Ersue, Mehmet (NSN - DE/Munich) Cc: Netconf Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session =09 =09 I would think that any "updated syntax" would be in XSD. Unfortunately... I am not sure how you do that in XSD. Write a complete new XSD? If so, then so be it (that is my personal view). =20 However... if any of those updates/extensions to NetConf will get published AFTER we have YANG as PS (which we expect in=20 September, right?) then we would do YANG I would think.=20 Again, personal opinion. =20 Bert ----- Original Message -----=20 From: Andy Bierman =20 To: Ersue, Mehmet (NSN - DE/Munich) =20 Cc: Netconf =20 Sent: Tuesday, March 03, 2009 5:12 PM Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Andy, >=20 > I don't have any issues to have a slot for the I-D=20 > draft-bierman-netmod-netconf-module-00.txt. >=20 > As far as I can see the draft defines the NETCONF=20 > model in YANG. The questions you are raising below=20 > are not discussed in the document in detail. >=20 > I think we should have some more discussion on=20 > the document content to measure the interest of=20 > the WG. >=20 > Though IMO we should avoid a new discussion on=20 > "which language is better". I think we had already=20 > sufficient discussion on this during NETMOD=20 > preparation with some conclusion. >=20 =09 I assume the with-defaults draft will be remain on the agenda, so the issue of how to publish the updated syntax will come up. What are your thoughts on this subject? How do the WG co-Chairs think the issues related to augmentation of the NETCONF protocol should be solved? =09 =09 > Mehmet > =20 =09 Andy =09 >=20 >> -----Original Message----- >> From: ext Andy Bierman [mailto:andy@netconfcentral.com]=20 >> Sent: Monday, March 02, 2009 5:31 PM >> To: Ersue, Mehmet (NSN - DE/Munich) >> Cc: Netconf >> Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session >> >> Ersue, Mehmet (NSN - DE/Munich) wrote: >>> Dear All, >>> =20 >>> please find an update of the NETCONF session agenda. >>> =20 >>> PS: The duration of the slots is subject to change. >>> Presenters please confirm your slot. >>> =20 >> >> I requested a short time slot to discuss >> draft-bierman-netconf-module-00.txt. >> In general, the WG needs to deal with the emergence >> of YANG and DSDL, and the pervasiveness of XSD. >> >> How will the NETCONF protocol operations be augmented to >> support with-defaults or any other extension in the future? >> The WG should have a plan going forward to deal with all 3 = formats. >> It appears that the WG is going to continue to use XSD >> for normative syntax, YANG for non-normative syntax, and >> unclear what role DSDL has at all. >> >> >> >>> Mehmet >> Andy >> >>> ________________________________________ >>> =20 >>> ** Draft - 020309 ** >>> =20 >>> NETCONF WG >>> IETF 74, San Francisco, CA, USA >>> =20 >>> TUESDAY, March 24, 2009, 1300-1500 >>> =20 >>> WG Chairs: >>> Bert Wijnen > >>> Mehmet Ersue > >>> =20 >>> Scribes (IF no_volunteers THEN wait_forever) >>> Agenda bashing (2 minutes) >>> WG status review (5 minutes) >>> =20 >>> Chartered items: >>> =20 >>> 1. Partial Lock RPC for NETCONF - Balazs Lengyel (5 = minutes) >>> draft-ietf-netconf-partial-lock >>> 2. NETCONF Monitoring Schema - Mark Scott (15 minutes)=20 >>> draft-ietf-netconf-monitoring >>> 3. With-defaults capability for NETCONF - A.=20 >> Bierman/B. Lengyel=20 >>> (20 minutes) >>> draft-ietf-netconf-with-defaults >>> 4. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20 = minutes) >>> draft-ietf-netconf-4741bis >>> =20 >>> Non-Chartered items: >>> =20 >>> 1. Generic solution for the message integrity issue=20 >> (10 minutes) >>> 2. Robust Configuration Management within NETCONF -=20 >> R. Cole/D.=20 >>> Romascanu (15 minutes)=20 >>> draft-cole-netconf-robust-config-00 >>> =20 >>> Open mike >>> Any other topics to discuss? >>> =20 >>> AOB >>> >>> =20 >> -------------------------------------------------------------- >> ---------- >>> *From:* netconf-bounces@ietf.org=20 >> [mailto:netconf-bounces@ietf.org] >>> *On Behalf Of *ext Ersue, Mehmet (NSN - DE/Munich) >>> *Sent:* Monday, March 02, 2009 3:27 PM >>> *To:* Netconf >>> *Subject:* [Netconf] Draft Agenda for IETF #74 NETCONF = Session >>> >>> >>> Dear NETCONF WG, >>> >>> below is the draft agenda for the NETCONF WG session >>> at the IETF #74. Our session will be on Tuesday after >>> the lunch break at 1300-1500. >>> >>> Our main focus in the session will be as usual on open issue >>> discussion but we have a few additional topics. >>> Please send us your comments and requests concerning >>> the agenda. >>> >>> The duration of the slots is not final and subject to change. >>> Presenters please confirm your slot. >>> >>> BTW: As usual we need to organize the scribes and minute >>> takers _before_ the meeting. Please help us to start the >>> session on time and send us a note if you volunteer. >>> >>> Bert & Mehmet >>> >>> ___________________________________________________ >>> >>> ** Draft - 020309 ** >>> >>> NETCONF WG >>> IETF 74, San Francisco, CA, USA >>> >>> TUESDAY, March 24, 2009, 1300-1500 >>> >>> WG Chairs: >>> Bert Wijnen >>> Mehmet Ersue >>> >>> Scribes (IF no_volunteers THEN wait_forever) >>> Agenda bashing (2 minutes) >>> WG status review (5 minutes) >>> >>> Chartered items: >>> >>> 1. NETCONF Monitoring Schema - Mark Scott (15 minutes)=20 >>> draft-ietf-netconf-monitoring >>> 2. Partial Lock RPC for NETCONF - Balazs Lengyel=20 >> (15 minutes) >>> draft-ietf-netconf-partial-lock >>> 3. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder=20 >> (20 minutes) >>> draft-ietf-netconf-4741bis >>> 4. With-defaults capability for NETCONF - B.=20 >> Lengyel (20 minutes) >>> draft-bierman-netconf-with-defaults >>> >>> Non-Chartered items: >>> >>> 1. Robust Configuration Management within NETCONF=20 >> - R. Cole/D. >>> Romascanu (15 minutes)=20 >>> draft-cole-netconf-robust-config-00 >>> >>> Open mike >>> Generic solution for the message identity issue=20 >> (10 minutes) >>> Any other topics to discuss? >>> >>> AOB >>> >>> >>> >> -------------------------------------------------------------- >> ---------- >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> >> >> >=20 >=20 =09 =09 =09 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf =09 ------_=_NextPart_001_01C99C2B.30C7A6F3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
 
I agree with Bert. Also=20 Martin stated the
same a bit earlier:
 
Martin wrote:
> I=20 think we have no other options right now - XSD must be = normative,
> but hopefully YANG will be = normative for=20 future extensions. The DSDL
>=20 schemas fall out of the YANG modules.
 
Everything else would be too much effort. I =
can=20 think on three options:
A)=20 do XSD-only 
B)=20 do both XSD (normative) and YANG
C)=20 wait on YANG
 
My=20 preferences are A) or B) for=20 fast publication
of=20 documents. The author should be allowed =
to=20 decide whether he/she supports YANG=20
model additionally. He/she might=20 also get
some=20 support from YANG guys.
 
I=20 strongly support the use of one modeling
language in NETCONF _and_ NETMOD documents =
'in=20 the future'.
IMO=20 this has different benefits, e.g. = avoiding=20
complexity for translations or = augmentations,=20
avoiding inconsistencies=20 with two languages
in one=20 document, faster learning curve,=20
increasing acceptance=20 outside of IETF.

Cheers,
Mehmet

 

From: ext Romascanu, Dan (Dan)=20 [mailto:dromasca@avaya.com]
Sent: Tuesday, March 03, 2009 = 5:34=20 PM
To: Bert Wijnen (IETF); Andy Bierman; Ersue, Mehmet (NSN = -=20 DE/Munich)
Cc: Netconf
Subject: RE: [Netconf] = Draft Agenda=20 for IETF #74 NETCONF Session

So, what is the exact=20 proposal?
 
1. do YANG only betting on YANG timing with the = risks of=20 following a work-in-progress syntax, and of getting stuck because of = the=20 normative dependencies?
2. do both XSD and YANG, = maybe in=20 separate sections, with YANG staying informative if YANG gets delayed? =
 
Dan
 
From: = netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen=20 (IETF)
Sent: Tuesday, March 03, 2009 6:25 PM
To: = Andy=20 Bierman; Ersue, Mehmet (NSN - DE/Munich)
Cc:=20 Netconf
Subject: Re: [Netconf] Draft Agenda for IETF #74 = NETCONF=20 Session

I would think that any "updated syntax" would be = in=20 XSD.
Unfortunately... I am not sure how you do that = in=20 XSD.
Write a complete new XSD? If so, then so be=20 it
(that is my personal view).
 
However... if any of those updates/extensions to = NetConf=20 will get
published AFTER we have YANG as PS (which we = expect in=20
September, right?) then we = would do=20 YANG I would think.
Again, personal opinion.
 
Bert
----- Original Message ----- =
From:=20 Andy Bierman
Cc: Netconf
Sent: Tuesday, March 03, = 2009 5:12=20 PM
Subject: Re: [Netconf] = Draft Agenda=20 for IETF #74 NETCONF Session

Ersue, Mehmet (NSN - DE/Munich) wrote:
> Hi=20 Andy,
>
> I don't have any issues to have a slot for = the I-D=20
> draft-bierman-netmod-netconf-module-00.txt.
> =
> As=20 far as I can see the draft defines the NETCONF
> model in = YANG. The=20 questions you are raising below
> are not discussed in the = document=20 in detail.
>
> I think we should have some more = discussion on=20
> the document content to measure the interest of
> = the=20 WG.
>
> Though IMO we should avoid a new discussion = on=20
> "which language is better". I think we had already =
>=20 sufficient discussion on this during NETMOD
> preparation = with some=20 conclusion.
>

I assume the with-defaults draft will = be=20 remain on the agenda,
so the issue of how to publish the = updated syntax=20 will come up.
What are your thoughts on this subject?
How do = the WG=20 co-Chairs think the issues related to
augmentation of the = NETCONF=20 protocol should be solved?


> Mehmet
> =20

Andy

>
>> -----Original=20 Message-----
>> From: ext Andy Bierman=20 [mailto:andy@netconfcentral.com]
>> Sent: Monday, March = 02, 2009=20 5:31 PM
>> To: Ersue, Mehmet (NSN - = DE/Munich)
>> Cc:=20 Netconf
>> Subject: Re: [Netconf] Draft Agenda for IETF = #74=20 NETCONF Session
>>
>> Ersue, Mehmet (NSN - = DE/Munich)=20 wrote:
>>> Dear All,
>>>  =
>>>=20 please find an update of the NETCONF session = agenda.
>>> =20
>>> PS: The duration of the slots is subject to=20 change.
>>> Presenters please confirm your=20 slot.
>>> 
>>
>> I requested a = short=20 time slot to discuss
>>=20 draft-bierman-netconf-module-00.txt.
>> In general, the = WG needs=20 to deal with the emergence
>> of YANG and DSDL, and the=20 pervasiveness of XSD.
>>
>> How will the NETCONF = protocol operations be augmented to
>> support = with-defaults or=20 any other extension in the future?
>> The WG should have = a plan=20 going forward to deal with all 3 formats.
>> It appears = that the=20 WG is going to continue to use XSD
>> for normative = syntax, YANG=20 for non-normative syntax, and
>> unclear what role DSDL = has at=20 all.
>>
>>
>>
>>>=20 Mehmet
>> Andy
>>
>>>=20 ________________________________________
>>> =20
>>> ** Draft - 020309 **
>>> =20
>>> NETCONF WG
>>> IETF 74, San = Francisco, CA,=20 USA
>>> 
>>> TUESDAY, March 24, = 2009,=20 1300-1500
>>> 
>>>    = WG=20 Chairs:
>>>    Bert Wijnen <bertietf@bwijnen.net = <mailto:bertietf@bwijnen.net>&= gt;
>>>   =20 Mehmet Ersue <mehmet.ersue@nsn.com = <mailto:mehmet.ersue@nsn.com>&= gt;
>>> =20
>>>    Scribes (IF no_volunteers THEN=20 wait_forever)
>>>    Agenda bashing (2=20 minutes)
>>>    WG status review (5=20 minutes)
>>> 
>>>   =20 Chartered items:
>>> =20
>>>       1. Partial = Lock RPC=20 for NETCONF - Balazs Lengyel (5=20 = minutes)
>>>        &= nbsp;=20 = draft-ietf-netconf-partial-lock
>>>    &n= bsp; =20 2. NETCONF Monitoring Schema - Mark Scott (15 minutes)=20 =
>>>         &nb= sp;=20 = draft-ietf-netconf-monitoring
>>>    &nbs= p; =20 3. With-defaults capability for NETCONF - A.
>> = Bierman/B.=20 Lengyel
>>> (20=20 = minutes)
>>>        &= nbsp; =20 = draft-ietf-netconf-with-defaults
>>>    &= nbsp; =20 4. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20=20 = minutes)
>>>        &= nbsp; =20 draft-ietf-netconf-4741bis
>>> =20
>>>    Non-Chartered=20 items:
>>> =20
>>>       1. Generic = solution=20 for the message integrity issue
>> (10=20 minutes)
>>>       2. = Robust=20 Configuration Management within NETCONF -
>> R. Cole/D.=20
>>> Romascanu (15 minutes)=20 =
>>>         &nb= sp;=20 draft-cole-netconf-robust-config-00
>>> =20
>>>    Open=20 mike
>>>       Any other = topics=20 to discuss?
>>>  =
>>>   =20 AOB
>>>
>>>     =
>>=20 = --------------------------------------------------------------
>>= ;=20 ----------
>>>     *From:* netconf-bounces@ietf.org=20
>>=20 = [mailto:netconf-bounces@ietf.org]
>>>    = =20 *On Behalf Of *ext Ersue, Mehmet (NSN -=20 DE/Munich)
>>>     *Sent:* Monday, = March=20 02, 2009 3:27 PM
>>>     *To:*=20 Netconf
>>>     *Subject:* = [Netconf] Draft=20 Agenda for IETF #74 NETCONF=20 = Session
>>>
>>>
>>>   =  =20 Dear NETCONF = WG,
>>>
>>>    =20 below is the draft agenda for the NETCONF WG=20 session
>>>     at the IETF #74. = Our=20 session will be on Tuesday = after
>>>    =20 the lunch break at=20 1300-1500.
>>>
>>>     = Our=20 main focus in the session will be as usual on open=20 issue
>>>     discussion but we = have a few=20 additional topics.
>>>     Please = send us=20 your comments and requests=20 concerning
>>>     the=20 agenda.
>>>
>>>     = The=20 duration of the slots is not final and subject to=20 change.
>>>     Presenters please = confirm=20 your slot.
>>>
>>>     = BTW: As=20 usual we need to organize the scribes and=20 minute
>>>     takers _before_ the = meeting. Please help us to start=20 the
>>>     session on time and = send us a=20 note if you=20 volunteer.
>>>
>>>     = Bert=20 & = Mehmet
>>>
>>>    =20 = ___________________________________________________
>>>
&g= t;>>    =20 ** Draft - 020309=20 **
>>>
>>>     NETCONF = WG
>>>     IETF 74, San Francisco, = CA,=20 USA
>>>
>>>     = TUESDAY, March=20 24, 2009,=20 = 1300-1500
>>>
>>>     &n= bsp; =20 WG = Chairs:
>>>        Bert=20 Wijnen <bertietf@bwijnen.net>
>= >>       =20 Mehmet Ersue <mehmet.ersue@nsn.com>
>= >>
>>>       =20 Scribes (IF no_volunteers THEN=20 = wait_forever)
>>>       =20 Agenda bashing (2=20 minutes)
>>>        = WG=20 status review (5=20 = minutes)
>>>
>>>     &nb= sp; =20 Chartered=20 = items:
>>>
>>>      = ;    =20 1. NETCONF Monitoring Schema - Mark Scott (15 minutes)=20 =
>>>         &nb= sp;    =20 = draft-ietf-netconf-monitoring
>>>    &nbs= p;     =20 2. Partial Lock RPC for NETCONF - Balazs Lengyel
>> (15=20 = minutes)
>>>        &= nbsp;    =20 = draft-ietf-netconf-partial-lock
>>>    &n= bsp;     =20 3. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder
>> = (20=20 = minutes)
>>>        &= nbsp;     =20 = draft-ietf-netconf-4741bis
>>>     &= nbsp;    =20 4. With-defaults capability for NETCONF - B.
>> Lengyel = (20=20 = minutes)
>>>        &= nbsp;     =20 = draft-bierman-netconf-with-defaults
>>>
>>> =       =20 Non-Chartered=20 = items:
>>>
>>>      = ;    =20 1. Robust Configuration Management within NETCONF
>> - = R.=20 Cole/D.
>>>     Romascanu (15 = minutes)=20 =
>>>         &nb= sp;    =20 = draft-cole-netconf-robust-config-00
>>>
>>> =       =20 Open=20 = mike
>>>         = ; =20 Generic solution for the message identity issue
>> (10=20 = minutes)
>>>        &= nbsp; =20 Any other topics to=20 = discuss?
>>>
>>>     &nb= sp; =20 AOB
>>>
>>>
>>>
>>=20 = --------------------------------------------------------------
>>= ;=20 ----------
>>>=20 _______________________________________________
>>> = Netconf=20 mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.o= rg/mailman/listinfo/netconf
>>
>>
>>
&g= t;=20
>=20 =



_______________________________________________
Netcon= f=20 mailing list
Netconf@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netconf
------_=_NextPart_001_01C99C2B.30C7A6F3-- From mehmet.ersue@nsn.com Tue Mar 3 10:20:58 2009 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 1193628C28A for ; Tue, 3 Mar 2009 10:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=-0.963, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waUCzqA3JP0J for ; Tue, 3 Mar 2009 10:20:56 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 479E028C30C for ; Tue, 3 Mar 2009 10:20:55 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n23ILLPW032435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Mar 2009 19:21:21 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n23ILLK2023303; Tue, 3 Mar 2009 19:21:21 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 19:21:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99C2C.D8A8655A" Date: Tue, 3 Mar 2009 19:21:18 +0100 Message-ID: In-Reply-To: <49AD5706.6030505@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Draft Agenda for IETF #74 NETCONF Session Thread-Index: AcmcGuzu3xqmA+N6QkCMrPqilr2oNwAEJ0Xw References: <49AC09AA.4030406@netconfcentral.com> <49AD5706.6030505@netconfcentral.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" X-OriginalArrivalTime: 03 Mar 2009 18:21:20.0920 (UTC) FILETIME=[DA263180:01C99C2C] Cc: Netconf Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 18:20:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99C2C.D8A8655A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andy Bierman wrote: > Ersue, Mehmet (NSN - DE/Munich) wrote: > > Hi Andy, > >=20 > > I don't have any issues to have a slot for the I-D=20 > > draft-bierman-netmod-netconf-module-00.txt. > >=20 > > As far as I can see the draft defines the NETCONF=20 > > model in YANG. The questions you are raising below=20 > > are not discussed in the document in detail. > >=20 > > I think we should have some more discussion on=20 > > the document content to measure the interest of=20 > > the WG. > >=20 > > Though IMO we should avoid a new discussion on=20 > > "which language is better". I think we had already=20 > > sufficient discussion on this during NETMOD=20 > > preparation with some conclusion. >=20 > I assume the with-defaults draft will be remain on the agenda, Yes. with-defaults draft is a WG item and we are keen=20 of hearing the status and discussing issues. > so the issue of how to publish the updated syntax will come up. We can have additional discussion on this during open=20 mic or earlier. Let us define it later based on the results=20 of the maillist discussion. > What are your thoughts on this subject? > How do the WG co-Chairs think the issues related to > augmentation of the NETCONF protocol should be solved? See parallel mail. Cheers, Mehmet >=20 >=20 > > Mehmet > > =20 >=20 > Andy >=20 > >=20 > >> -----Original Message----- > >> From: ext Andy Bierman [mailto:andy@netconfcentral.com]=20 > >> Sent: Monday, March 02, 2009 5:31 PM > >> To: Ersue, Mehmet (NSN - DE/Munich) > >> Cc: Netconf > >> Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session > >> > >> Ersue, Mehmet (NSN - DE/Munich) wrote: > >>> Dear All, > >>> =20 > >>> please find an update of the NETCONF session agenda. > >>> =20 > >>> PS: The duration of the slots is subject to change. > >>> Presenters please confirm your slot. > >>> =20 > >> > >> I requested a short time slot to discuss > >> draft-bierman-netconf-module-00.txt. > >> In general, the WG needs to deal with the emergence > >> of YANG and DSDL, and the pervasiveness of XSD. > >> > >> How will the NETCONF protocol operations be augmented to > >> support with-defaults or any other extension in the future? > >> The WG should have a plan going forward to deal with all 3 formats. > >> It appears that the WG is going to continue to use XSD > >> for normative syntax, YANG for non-normative syntax, and > >> unclear what role DSDL has at all. > >> > >> > >> > >>> Mehmet > >> Andy > >> > >>> ________________________________________ > >>> =20 > >>> ** Draft - 020309 ** > >>> =20 > >>> NETCONF WG > >>> IETF 74, San Francisco, CA, USA > >>> =20 > >>> TUESDAY, March 24, 2009, 1300-1500 > >>> =20 > >>> WG Chairs: > >>> Bert Wijnen > > >>> Mehmet Ersue > > >>> =20 > >>> Scribes (IF no_volunteers THEN wait_forever) > >>> Agenda bashing (2 minutes) > >>> WG status review (5 minutes) > >>> =20 > >>> Chartered items: > >>> =20 > >>> 1. Partial Lock RPC for NETCONF - Balazs Lengyel (5 minutes) > >>> draft-ietf-netconf-partial-lock > >>> 2. NETCONF Monitoring Schema - Mark Scott (15 minutes)=20 > >>> draft-ietf-netconf-monitoring > >>> 3. With-defaults capability for NETCONF - A.=20 > >> Bierman/B. Lengyel=20 > >>> (20 minutes) > >>> draft-ietf-netconf-with-defaults > >>> 4. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20 = minutes) > >>> draft-ietf-netconf-4741bis > >>> =20 > >>> Non-Chartered items: > >>> =20 > >>> 1. Generic solution for the message integrity issue=20 > >> (10 minutes) > >>> 2. Robust Configuration Management within NETCONF -=20 > >> R. Cole/D.=20 > >>> Romascanu (15 minutes)=20 > >>> draft-cole-netconf-robust-config-00 > >>> =20 > >>> Open mike > >>> Any other topics to discuss? > >>> =20 > >>> AOB > >>> > >>> =20 > >> -------------------------------------------------------------- > >> ---------- > >>> *From:* netconf-bounces@ietf.org=20 > >> [mailto:netconf-bounces@ietf.org] > >>> *On Behalf Of *ext Ersue, Mehmet (NSN - DE/Munich) > >>> *Sent:* Monday, March 02, 2009 3:27 PM > >>> *To:* Netconf > >>> *Subject:* [Netconf] Draft Agenda for IETF #74 NETCONF Session > >>> > >>> > >>> Dear NETCONF WG, > >>> > >>> below is the draft agenda for the NETCONF WG session > >>> at the IETF #74. Our session will be on Tuesday after > >>> the lunch break at 1300-1500. > >>> > >>> Our main focus in the session will be as usual on open issue > >>> discussion but we have a few additional topics. > >>> Please send us your comments and requests concerning > >>> the agenda. > >>> > >>> The duration of the slots is not final and subject to change. > >>> Presenters please confirm your slot. > >>> > >>> BTW: As usual we need to organize the scribes and minute > >>> takers _before_ the meeting. Please help us to start the > >>> session on time and send us a note if you volunteer. > >>> > >>> Bert & Mehmet > >>> > >>> ___________________________________________________ > >>> > >>> ** Draft - 020309 ** > >>> > >>> NETCONF WG > >>> IETF 74, San Francisco, CA, USA > >>> > >>> TUESDAY, March 24, 2009, 1300-1500 > >>> > >>> WG Chairs: > >>> Bert Wijnen > >>> Mehmet Ersue > >>> > >>> Scribes (IF no_volunteers THEN wait_forever) > >>> Agenda bashing (2 minutes) > >>> WG status review (5 minutes) > >>> > >>> Chartered items: > >>> > >>> 1. NETCONF Monitoring Schema - Mark Scott (15 minutes)=20 > >>> draft-ietf-netconf-monitoring > >>> 2. Partial Lock RPC for NETCONF - Balazs Lengyel=20 > >> (15 minutes) > >>> draft-ietf-netconf-partial-lock > >>> 3. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder=20 > >> (20 minutes) > >>> draft-ietf-netconf-4741bis > >>> 4. With-defaults capability for NETCONF - B.=20 > >> Lengyel (20 minutes) > >>> draft-bierman-netconf-with-defaults > >>> > >>> Non-Chartered items: > >>> > >>> 1. Robust Configuration Management within NETCONF=20 > >> - R. Cole/D. > >>> Romascanu (15 minutes)=20 > >>> draft-cole-netconf-robust-config-00 > >>> > >>> Open mike > >>> Generic solution for the message identity issue=20 > >> (10 minutes) > >>> Any other topics to discuss? > >>> > >>> AOB > >>> > >>> > >>> > >> -------------------------------------------------------------- > >> ---------- > >>> _______________________________________________ > >>> Netconf mailing list > >>> Netconf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netconf > >> > >> > >> > >=20 > >=20 >=20 >=20 >=20 >=20 ------_=_NextPart_001_01C99C2C.D8A8655A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Netconf] Draft Agenda for IETF #74 NETCONF Session

Andy Bierman = wrote:
> Ersue, Mehmet = (NSN - DE/Munich) wrote:
> > Hi = Andy,
> > =
> > I don't = have any issues to have a slot for the I-D
> > = draft-bierman-netmod-netconf-module-00.txt.
> > =
> > As far as = I can see the draft defines the NETCONF
> > model in = YANG. The questions you are raising below
> > are not = discussed in the document in detail.
> > =
> > I think we = should have some more discussion on
> > the = document content to measure the interest of
> > the = WG.
> > =
> > Though IMO = we should avoid a new discussion on
> > = "which language is better". I think we had already =
> > sufficient = discussion on this during NETMOD
> > = preparation with some conclusion.
>
> I assume the = with-defaults draft will be remain on the agenda,

Yes. with-defaults = draft is a WG item and we are keen
of hearing the = status and discussing issues.

> so the issue of = how to publish the updated syntax will come up.

We can have = additional discussion on this during open
mic or earlier. = Let us define it later based on the results
of the maillist = discussion.

> What are your = thoughts on this subject?
> How do the WG = co-Chairs think the issues related to
> augmentation of = the NETCONF protocol should be solved?
See parallel = mail.


Cheers,
Mehmet
>
>
> > = Mehmet
> >  =
>
> = Andy
>
> > =
> >> = -----Original Message-----
> >> From: = ext Andy Bierman [mailto:andy@netconfcentral.com]
> >> Sent: = Monday, March 02, 2009 5:31 PM
> >> To: = Ersue, Mehmet (NSN - DE/Munich)
> >> Cc: = Netconf
> >> = Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF = Session
> = >>
> >> Ersue, = Mehmet (NSN - DE/Munich) wrote:
> >>> = Dear All,
> = >>> 
> >>> = please find an update of the NETCONF session agenda.
> = >>> 
> >>> = PS: The duration of the slots is subject to change.
> >>> = Presenters please confirm your slot.
> = >>> 
> = >>
> >> I = requested a short time slot to discuss
> >> = draft-bierman-netconf-module-00.txt.
> >> In = general, the WG needs to deal with the emergence
> >> of = YANG and DSDL, and the pervasiveness of XSD.
> = >>
> >> How = will the NETCONF protocol operations be augmented to
> >> = support with-defaults or any other extension in the = future?
> >> The WG = should have a plan going forward to deal with all 3 = formats.
> >> It = appears that the WG is going to continue to use XSD
> >> for = normative syntax, YANG for non-normative syntax, and
> >> = unclear what role DSDL has at all.
> = >>
> = >>
> = >>
> >>> = Mehmet
> >> = Andy
> = >>
> >>> = ________________________________________
> = >>> 
> >>> ** = Draft - 020309 **
> = >>> 
> >>> = NETCONF WG
> >>> = IETF 74, San Francisco, CA, USA
> = >>> 
> >>> = TUESDAY, March 24, 2009, 1300-1500
> = >>> 
> = >>>    WG Chairs:
> = >>>    Bert Wijnen <bertietf@bwijnen.net =
> = <mailto:bertietf@bwijnen.net>>
> = >>>    Mehmet Ersue <mehmet.ersue@nsn.com =
> = <mailto:mehmet.ersue@nsn.com>>
> = >>> 
> = >>>    Scribes (IF no_volunteers THEN = wait_forever)
> = >>>    Agenda bashing (2 minutes)
> = >>>    WG status review (5 = minutes)
> = >>> 
> = >>>    Chartered items:
> = >>> 
> = >>>       1. Partial Lock RPC for = NETCONF - Balazs Lengyel (5 minutes)
> = >>>          = draft-ietf-netconf-partial-lock
> = >>>       2. NETCONF Monitoring = Schema - Mark Scott (15 minutes)
> = >>>           = draft-ietf-netconf-monitoring
> = >>>       3. With-defaults = capability for NETCONF - A.
> >> = Bierman/B. Lengyel
> >>> = (20 minutes)
> = >>>           = draft-ietf-netconf-with-defaults
> = >>>       4. 4741bis-draft - M. = Bjorklund/J. Sch=F6nw=E4lder (20 minutes)
> = >>>           = draft-ietf-netconf-4741bis
> = >>> 
> = >>>    Non-Chartered items:
> = >>> 
> = >>>       1. Generic solution for = the message integrity issue
> >> (10 = minutes)
> = >>>       2. Robust Configuration = Management within NETCONF -
> >> R. = Cole/D.
> >>> = Romascanu (15 minutes)
> = >>>           = draft-cole-netconf-robust-config-00
> = >>> 
> = >>>    Open mike
> = >>>       Any other topics to = discuss?
> = >>> 
> = >>>    AOB
> = >>>
> = >>>    
> >> = --------------------------------------------------------------
> >> = ----------
> = >>>     *From:* netconf-bounces@ietf.org =
> >> = [mailto:netconf-bounces@ietf.org]
> = >>>     *On Behalf Of *ext Ersue, Mehmet = (NSN - DE/Munich)
> = >>>     *Sent:* Monday, March 02, 2009 3:27 = PM
> = >>>     *To:* Netconf
> = >>>     *Subject:* [Netconf] Draft Agenda = for IETF #74 NETCONF Session
> = >>>
> = >>>
> = >>>     Dear NETCONF WG,
> = >>>
> = >>>     below is the draft agenda for the = NETCONF WG session
> = >>>     at the IETF #74. Our session will = be on Tuesday after
> = >>>     the lunch break at = 1300-1500.
> = >>>
> = >>>     Our main focus in the session will = be as usual on open issue
> = >>>     discussion but we have a few = additional topics.
> = >>>     Please send us your comments and = requests concerning
> = >>>     the agenda.
> = >>>
> = >>>     The duration of the slots is not = final and subject to change.
> = >>>     Presenters please confirm your = slot.
> = >>>
> = >>>     BTW: As usual we need to organize = the scribes and minute
> = >>>     takers _before_ the meeting. Please = help us to start the
> = >>>     session on time and send us a note = if you volunteer.
> = >>>
> = >>>     Bert & Mehmet
> = >>>
> = >>>     = ___________________________________________________
> = >>>
> = >>>     ** Draft - 020309 **
> = >>>
> = >>>     NETCONF WG
> = >>>     IETF 74, San Francisco, CA, = USA
> = >>>
> = >>>     TUESDAY, March 24, 2009, = 1300-1500
> = >>>
> = >>>        WG = Chairs:
> = >>>        Bert Wijnen = <bertietf@bwijnen.net>
> = >>>        Mehmet Ersue = <mehmet.ersue@nsn.com>
> = >>>
> = >>>        Scribes (IF = no_volunteers THEN wait_forever)
> = >>>        Agenda bashing (2 = minutes)
> = >>>        WG status review = (5 minutes)
> = >>>
> = >>>        Chartered = items:
> = >>>
> = >>>           = 1. NETCONF Monitoring Schema - Mark Scott (15 minutes)
> = >>>          &= nbsp;    draft-ietf-netconf-monitoring
> = >>>           = 2. Partial Lock RPC for NETCONF - Balazs Lengyel
> >> (15 = minutes)
> = >>>          &= nbsp;   draft-ietf-netconf-partial-lock
> = >>>           = 3. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder
> >> (20 = minutes)
> = >>>          &= nbsp;    draft-ietf-netconf-4741bis
> = >>>           = 4. With-defaults capability for NETCONF - B.
> >> = Lengyel (20 minutes)
> = >>>          &= nbsp;    = draft-bierman-netconf-with-defaults
> = >>>
> = >>>        Non-Chartered = items:
> = >>>
> = >>>           = 1. Robust Configuration Management within NETCONF
> >> - R. = Cole/D.
> = >>>     Romascanu (15 minutes) =
> = >>>          &= nbsp;    = draft-cole-netconf-robust-config-00
> = >>>
> = >>>        Open = mike
> = >>>           = Generic solution for the message identity issue
> >> (10 = minutes)
> = >>>           = Any other topics to discuss?
> = >>>
> = >>>        AOB
> = >>>
> = >>>
> = >>>
> >> = --------------------------------------------------------------
> >> = ----------
> >>> = _______________________________________________
> >>> = Netconf mailing list
> >>> = Netconf@ietf.org
> >>> = https://www.ietf.org/mailman/listinfo/netconf
> = >>
> = >>
> = >>
> > =
> > =
>
>
>
>

------_=_NextPart_001_01C99C2C.D8A8655A-- From mbj@tail-f.com Tue Mar 3 11:44:19 2009 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 5B7EF3A6B2B for ; Tue, 3 Mar 2009 11:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.107, 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 Iayw1yU8wJGs for ; Tue, 3 Mar 2009 11:44:18 -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 0D0013A6B33 for ; Tue, 3 Mar 2009 11:44: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 5E5A076C4D7; Tue, 3 Mar 2009 20:44:44 +0100 (CET) Date: Tue, 03 Mar 2009 20:44:44 +0100 (CET) Message-Id: <20090303.204444.158645126.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49AD618D.3070007@netconfcentral.com> References: <1F32D314B61840BBB997628DED4995F7@BertLaptop> <49AD618D.3070007@netconfcentral.com> X-Mailer: Mew version 6.0.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] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 19:44:19 -0000 Andy Bierman wrote: > Romascanu, Dan (Dan) wrote: > > */So, what is the exact proposal?/* > > */1. do YANG only betting on YANG timing with the risks of following a > > *work-in-progress syntax, and of getting stuck because of the normative > > *dependencies? /* > > */2. do /**/both XSD and YANG, maybe in separate sections, with YANG staying > > *informative if YANG gets delayed? /* > > IMO - (2) Suppose we do (2) - we already do that for partial locking and monitoring, let's say we do it for 4741bis as well. In some future, YANG becomes PS. Now we have all those documents with non-normative YANG models. Do we have to re-publish them all with normative YANG? If not, how can a new YANG PS model reuse/extend any of those non-normative models? /martin From mbj@tail-f.com Tue Mar 3 11:53:42 2009 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 CBF483A69CE for ; Tue, 3 Mar 2009 11:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.104, 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 M8c3gmHnF6ZG for ; Tue, 3 Mar 2009 11:53:42 -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 0E15C3A67F9 for ; Tue, 3 Mar 2009 11:53:42 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 1C85776C4D7; Tue, 3 Mar 2009 20:54:09 +0100 (CET) Date: Tue, 03 Mar 2009 20:54:08 +0100 (CET) Message-Id: <20090303.205408.140202751.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <49AD5D00.4020909@netconfcentral.com> References: <49AD5706.6030505@netconfcentral.com> <1F32D314B61840BBB997628DED4995F7@BertLaptop> <49AD5D00.4020909@netconfcentral.com> X-Mailer: Mew version 6.0.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] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 19:53:42 -0000 Andy Bierman wrote: > Bert Wijnen (IETF) wrote: > > I would think that any "updated syntax" would be in XSD. > > Unfortunately... I am not sure how you do that in XSD. > > Write a complete new XSD? If so, then so be it > > (that is my personal view). > > > > The current XSD would need to be edited, > but of course this makes 'with-defaults' > part of 4741-bis, not a separate document. > Not a show-stopper of course, but not > what the WG wanted to do. > > XSD has awful 'augment' capabilities. > You have to know in advance exactly what you are > going to need to augment, and plan for it in advance. Another option could be to not use the formal XSD ways of extending schemas at all. Instead, we could use XSD to describe the current schema, with no substitutionGroups etc. And we describe this clearly in text, i.e. we state that new capabilities may extend this schema by informal text. Next, when we need to define a new capability, text is added that describes how the base _XML_ is extended. This is the approach taken by Andy and Balazs already in the with-defaults draft. I think this is fine. /martin From andy@netconfcentral.com Tue Mar 3 12:01:29 2009 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 88E0828C2F6 for ; Tue, 3 Mar 2009 12:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, 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 wLxwCHbhFprP for ; Tue, 3 Mar 2009 12:01:28 -0800 (PST) Received: from n25.bullet.mail.mud.yahoo.com (n25.bullet.mail.mud.yahoo.com [68.142.206.220]) by core3.amsl.com (Postfix) with SMTP id E984328C15F for ; Tue, 3 Mar 2009 12:01:10 -0800 (PST) Received: from [209.191.108.97] by n25.bullet.mail.mud.yahoo.com with NNFMP; 03 Mar 2009 20:01:38 -0000 Received: from [68.142.201.72] by t4.bullet.mud.yahoo.com with NNFMP; 03 Mar 2009 20:01:38 -0000 Received: from [127.0.0.1] by omp424.mail.mud.yahoo.com with NNFMP; 03 Mar 2009 20:01:38 -0000 X-Yahoo-Newman-Id: 346490.91604.bm@omp424.mail.mud.yahoo.com Received: (qmail 23164 invoked from network); 3 Mar 2009 20:01:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.82.123 with plain) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 3 Mar 2009 20:01:37 -0000 X-YMail-OSG: FZxQ2nMVM1mOrRU.LhBYpHRtbnII8EhBs_VZnSYMlxFYqV7O62YbpJou.BDlC3XW.E8r5_mpkG9HLsQNqA4f.mp4h.DSG0A0EKuZNZWhVH5Rgn4ziO5XGWcyN7esBwN1NNI5HQ9uOxUY7_q55BtGO4do2E1IapBKwlJkUZ1QkGt0wjxVRxXZkfxBZTY4meexvdsSqzoLohe.U1IPhZTw5w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49AD8C9F.1060601@netconfcentral.com> Date: Tue, 03 Mar 2009 12:01:35 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <1F32D314B61840BBB997628DED4995F7@BertLaptop> <49AD618D.3070007@netconfcentral.com> <20090303.204444.158645126.mbj@tail-f.com> In-Reply-To: <20090303.204444.158645126.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 20:01:29 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Romascanu, Dan (Dan) wrote: >>> */So, what is the exact proposal?/* >>> */1. do YANG only betting on YANG timing with the risks of following a >>> *work-in-progress syntax, and of getting stuck because of the normative >>> *dependencies? /* >>> */2. do /**/both XSD and YANG, maybe in separate sections, with YANG staying >>> *informative if YANG gets delayed? /* >> IMO - (2) > > Suppose we do (2) - we already do that for partial locking and > monitoring, let's say we do it for 4741bis as well. > > In some future, YANG becomes PS. Now we have all those documents with > non-normative YANG models. Do we have to re-publish them all with > normative YANG? If not, how can a new YANG PS model reuse/extend any > of those non-normative models? > You are suggesting that (in the long run) we are better off with only normative YANG. This implies that XSD would not be normative, and only the YANG version would be in any NETCONF/NETMOD RFC. Or would XSD become the non-normative appendix? Sounds OK to me. It may be just what we need to stop tinkering with YANG and get it in the IESG queue already. > /martin > > Andy From andy@netconfcentral.com Tue Mar 3 12:07:31 2009 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 BD60B28C2EE for ; Tue, 3 Mar 2009 12:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=-0.011, 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 i2AAKCZxml8H for ; Tue, 3 Mar 2009 12:07:31 -0800 (PST) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 015DA28C2B9 for ; Tue, 3 Mar 2009 12:07:31 -0800 (PST) Received: (qmail 21823 invoked from network); 3 Mar 2009 20:07:58 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.82.123 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 3 Mar 2009 20:07:58 -0000 X-YMail-OSG: e5ZUMK4VM1koD00pFnxBVoqC86x5.T_dBcbG5QXJDPPqKhrsOFlCQd_Fa_eJc82PJfMxEoL6IV2JhrwBRXy62qN.OVUBNU8Jn_2j5OLRvbi7eCIg1l4gyyKROYf6fua1zUyyeda3M9ZL0zs2zhMdsrFaiWsttQOSsec8w6uRg38coweGEqz5C9Sx9ECGRaPHjlCptD4pkicfeVHTOshV9A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49AD8E1C.1090202@netconfcentral.com> Date: Tue, 03 Mar 2009 12:07:56 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <49AD5706.6030505@netconfcentral.com> <1F32D314B61840BBB997628DED4995F7@BertLaptop> <49AD5D00.4020909@netconfcentral.com> <20090303.205408.140202751.mbj@tail-f.com> In-Reply-To: <20090303.205408.140202751.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 20:07:31 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Bert Wijnen (IETF) wrote: >>> I would think that any "updated syntax" would be in XSD. >>> Unfortunately... I am not sure how you do that in XSD. >>> Write a complete new XSD? If so, then so be it >>> (that is my personal view). >>> >> The current XSD would need to be edited, >> but of course this makes 'with-defaults' >> part of 4741-bis, not a separate document. >> Not a show-stopper of course, but not >> what the WG wanted to do. >> >> XSD has awful 'augment' capabilities. >> You have to know in advance exactly what you are >> going to need to augment, and plan for it in advance. > > Another option could be to not use the formal XSD ways of extending > schemas at all. Instead, we could use XSD to describe the current > schema, with no substitutionGroups etc. And we describe this clearly > in text, i.e. we state that new capabilities may extend this schema by > informal text. Next, when we need to define a new capability, text is > added that describes how the base _XML_ is extended. > > This is the approach taken by Andy and Balazs already in the > with-defaults draft. I think this is fine. > This was the only part of the draft I wanted to change (besides the scope issue raised by Phil). I don't want every NETCONF user to be forced to maintain their own 'doctored' version of the schema (XSD, YANG, or DSDL). An acceptable work-around would be if IANA or the WG maintained online versions of the up-to-date schema. Then (at least) everyone has the opportunity to use the same doctored version. > > /martin > > Andy From lhotka@cesnet.cz Tue Mar 3 12:19:16 2009 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 0EEFA28C306 for ; Tue, 3 Mar 2009 12:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.954 X-Spam-Level: X-Spam-Status: No, score=-0.954 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 qfCqVonqm9hO for ; Tue, 3 Mar 2009 12:19:15 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 41DBF28C129 for ; Tue, 3 Mar 2009 12:19:15 -0800 (PST) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id B85AFD800C7; Tue, 3 Mar 2009 21:19:41 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49AD8C9F.1060601@netconfcentral.com> References: <1F32D314B61840BBB997628DED4995F7@BertLaptop> <49AD618D.3070007@netconfcentral.com> <20090303.204444.158645126.mbj@tail-f.com> <49AD8C9F.1060601@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Tue, 03 Mar 2009 21:19:43 +0100 Message-Id: <1236111583.7081.22.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 20:19:16 -0000 Andy Bierman píše v Út 03. 03. 2009 v 12:01 -0800: > You are suggesting that (in the long run) we are better > off with only normative YANG. What about the XML attributes such as message-id that are turned to elements in your YANG module for NETCONF? > > This implies that XSD would not be normative, and only > the YANG version would be in any NETCONF/NETMOD RFC. > Or would XSD become the non-normative appendix? IMO this would be only confusing and/or error-prone. If YANG is normative, it should suffice. > > Sounds OK to me. > It may be just what we need to stop tinkering with YANG > and get it in the IESG queue already. +1 Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Tue Mar 3 12:41:14 2009 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 C52223A69EB for ; Tue, 3 Mar 2009 12:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 egTilQlVZF9v for ; Tue, 3 Mar 2009 12:41:14 -0800 (PST) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 1789B3A69CE for ; Tue, 3 Mar 2009 12:41:14 -0800 (PST) Received: (qmail 37821 invoked from network); 3 Mar 2009 20:41:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.82.123 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 3 Mar 2009 20:41:41 -0000 X-YMail-OSG: Wf4lQd4VM1nd.74I23AmgyV7Or8jUJBAEn1IzjAGKMaDkLswGVQko.I6da4HymzrLzH1gaXxr82DC05De28emDa8MYAU0qeJdNaUZwOVCJWlS5bKxKicMXPZPCjYv49sTvmVPDIVXV0qTf3VUnLLkFpu X-Yahoo-Newman-Property: ymail-3 Message-ID: <49AD9604.90800@netconfcentral.com> Date: Tue, 03 Mar 2009 12:41:40 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ladislav Lhotka References: <1F32D314B61840BBB997628DED4995F7@BertLaptop> <49AD618D.3070007@netconfcentral.com> <20090303.204444.158645126.mbj@tail-f.com> <49AD8C9F.1060601@netconfcentral.com> <1236111583.7081.22.camel@missotis> In-Reply-To: <1236111583.7081.22.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 20:41:14 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Út 03. 03. 2009 v 12:01 -0800: >> You are suggesting that (in the long run) we are better >> off with only normative YANG. > > What about the XML attributes such as message-id that are turned to > elements in your YANG module for NETCONF? > Actually, I just meant the YANG data models that do not use XML attributes. I think the XSD in RFC 4741 should still be normative for the protocol itself. IMO, using XML attributes was a mistake. The element is a disaster, from a schema validation POV. >> This implies that XSD would not be normative, and only >> the YANG version would be in any NETCONF/NETMOD RFC. >> Or would XSD become the non-normative appendix? > > IMO this would be only confusing and/or error-prone. If YANG is > normative, it should suffice. > >> Sounds OK to me. >> It may be just what we need to stop tinkering with YANG >> and get it in the IESG queue already. > > +1 > > Lada > Andy From lhotka@cesnet.cz Tue Mar 3 12:58:40 2009 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 3AE593A68DD for ; Tue, 3 Mar 2009 12:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.966 X-Spam-Level: X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 F66Z7uVPbv6x for ; Tue, 3 Mar 2009 12:58:39 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 781AA3A677D for ; Tue, 3 Mar 2009 12:58:39 -0800 (PST) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A7154D800C5; Tue, 3 Mar 2009 21:59:06 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49AD9604.90800@netconfcentral.com> References: <1F32D314B61840BBB997628DED4995F7@BertLaptop> <49AD618D.3070007@netconfcentral.com> <20090303.204444.158645126.mbj@tail-f.com> <49AD8C9F.1060601@netconfcentral.com> <1236111583.7081.22.camel@missotis> <49AD9604.90800@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Tue, 03 Mar 2009 21:59:08 +0100 Message-Id: <1236113948.7081.42.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 20:58:40 -0000 Andy Bierman píše v Út 03. 03. 2009 v 12:41 -0800: > Actually, I just meant the YANG data models that > do not use XML attributes. I had the impression that most contributors to this thread assumed YANG will replace the XSD in RFC 4741 and all extensions as well. > > I think the XSD in RFC 4741 should still be normative > for the protocol itself. The schema is broken, so I am very sceptical about its so called normativeness. It happily validates PDUs that are in fact invalid according to the text. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From dromasca@avaya.com Wed Mar 4 04:40:00 2009 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 0B9053A6C80; Wed, 4 Mar 2009 04:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 F+Ht7KGCJiKe; Wed, 4 Mar 2009 04:39:59 -0800 (PST) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id AFB013A6C7A; Wed, 4 Mar 2009 04:39:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,300,1233550800"; d="scan'208";a="154172642" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 04 Mar 2009 07:40:26 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 04 Mar 2009 07:40:26 -0500 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, 4 Mar 2009 13:39:37 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-netconf-tls-07.txt to Proposed Standard Thread-Index: AcmctE6PJ+XXJxdqS+eRZAX3IY0LqwAEeJog From: "Romascanu, Dan (Dan)" To: , , "Netconf" Subject: [Netconf] FW: Evaluation: draft-ietf-netconf-tls-07.txt to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 12:40:00 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-07.txt Technical Summary The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to provide a secure connection for the transport of NETCONF messages. The mechanisms defined in this document include the support for certificate-based mutual authentication and key derivation, utilizing the protected ciphersuite negotiation, mutual authentication and key management capabilities of the TLS (Transport Layer Security) protocol. Working Group Summary Many WG member were thinking that password-based authentication is already handled well enough by the existing NETCONF transports (SSH and BEEP), and the NETCONF-over- TLS specification does not need to handle passwords. It has been recommended to scope the document to certificate- based authentication.=20 There was also some controversy on the use of pre-shared keys (PSKs) derived from passwords. Based on this dicussion the Working Group decided to remove the text related to PSK based- authentication. See http://www.ietf.org/mail-archive/web/netconf/current/msg03856.html =20 There was some controversal discussion about the Connection Closure. The consensus was that the document adopts the closure mechanism from draft-ietf-syslog-transport-tls-, Section 4.4.=20 =20 There was also some controversy about the use of a dedicated port of NETCONF over TLS. The consensus was that a dedicated port should be requested.=20 =20 The summary of the last changes can be found in: http://www.ietf.org/mail-archive/web/netconf/current/msg03873.html http://www.ietf.org/mail-archive/web/netconf/current/msg03882.html=20 There were many WG members who did not strongly support or object to the document. Nobody objected to the document during or after the WGLC. The level of review in the WG was adequate , with several=20 independent reviews by WG members. There is WG consensus to publish =20 the document.=20 Document Quality No vendors have announced that they will utilize this protocol.=20 Two implementations with independent code-base and initiated by the document author are available as open source. The author ensures that the two implementations have been tested as interoperable. Personnel The document was reviewed by Eric Rescorla, Juergen Schoenwaelder, David Harrington, the WG security advisor Charlie Kaufman, and the security ADs Pasi Eronen and Tim Polk.=20 Mehmet Ersue is the document shepherd, and Dan Romascanu the shepherding AD.=20 RFC Editor Note (Insert RFC Editor Note here or remove section) IRTF Note (Insert IRTF Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section) From root@core3.amsl.com Wed Mar 4 09:15:01 2009 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 98D7F3A6BA0; Wed, 4 Mar 2009 09:15: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: <20090304171501.98D7F3A6BA0@core3.amsl.com> Date: Wed, 4 Mar 2009 09:15:01 -0800 (PST) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-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: Wed, 04 Mar 2009 17:15: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 : NETCONF Configuration Protocol Author(s) : R. Enns, et al. Filename : draft-ietf-netconf-4741bis-00.txt Pages : 104 Date : 2009-03-04 The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-4741bis-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-4741bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-04091401.I-D@ietf.org> --NextPart-- From mbj@tail-f.com Wed Mar 4 09:27:10 2009 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 E3A2228C3C8 for ; Wed, 4 Mar 2009 09:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.096, 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 2ii3ZZ9MIXRv for ; Wed, 4 Mar 2009 09:27:10 -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 1612C28C3EA for ; Wed, 4 Mar 2009 09:27:10 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 24A6276C4E6 for ; Wed, 4 Mar 2009 18:27:38 +0100 (CET) Date: Wed, 04 Mar 2009 18:27:37 +0100 (CET) Message-Id: <20090304.182737.97731960.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <20090304171501.98D7F3A6BA0@core3.amsl.com> References: <20090304171501.98D7F3A6BA0@core3.amsl.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-4741bis-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: Wed, 04 Mar 2009 17:27:11 -0000 Hi, We have sumbitted this initial version of 4741bis. It contains bugfixes and some minor issues, but we have not yet addressed the bigger issues where we believe we need some WG discussion. And yes, I know that the formatting of the table on page 68 is wrong :( /martin From csherratt@syphan.com Wed Mar 4 11:49:28 2009 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 92E2B28C45F for ; Wed, 4 Mar 2009 11:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 9IXa3diMiqGk for ; Wed, 4 Mar 2009 11:49:27 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 19E7E28C14E for ; Wed, 4 Mar 2009 11:49:26 -0800 (PST) Received: by fxm24 with SMTP id 24so3055334fxm.37 for ; Wed, 04 Mar 2009 11:49:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.70.3 with SMTP id s3mr404521fga.48.1236196194142; Wed, 04 Mar 2009 11:49:54 -0800 (PST) Date: Wed, 4 Mar 2009 19:49:54 +0000 Message-ID: From: Carl Sherratt To: netconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Netconf] Real Time Gap Improvements to the target configuration locking mechanism 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, 04 Mar 2009 19:49:28 -0000 Hi, I would like to suggest some improvements in the way configuration locks are currently handled by the netconf standard and that in draft, If we could possibly discuss either the problems/merits of the current target configuration locking mechanism and also potential problems/merits of my suggestion. Hopefully the outcome will be an improved locking mechanism which we can add to the working draft. At present, if a NETCONF Session holder (in a multi-session environment) wants to edit a configuration the following happens in an ok scenario :- 1) session holder requests to obtain a lock 2) ok is sent back confirming they have the lock, but for how long? 3) get-config whilst they have the lock to ensure it hasn't been altered by another session 4) rpc-reply containing the configuration 5) edit the configuration 6) edit-config either merges, replaces or creates or deletes the locked uncommited=A0 configuration. 7) ok is sent back confirming the edit 8) session holder commits to make the changes apply to the device 9) ok is send back confirming the commitment What I have noticed is a lot of real-time gaps in a process which I believe should contain minimal gaps in order to prevent error. A) My first suggestion is to embed the request in a request. This removes a real-time gap and ensures the session holder isn't spending valuable lock time on sending another request.=A0 The request would look something like this :- =A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 ..... B) The second suggestion I have is to embed a lock-timeout in the response, the session holder can use this to re-request the lock if it needs more edit-time, loosing the lock during a long edit time may be fustrating to a consoler user. So The rpc-reply returning the locked configuration would contain the following :- =A0=A0 300 =A0=A0 =A0=A0=A0=A0=A0=A0 ...... =A0=A0 I would also suggest including the element in messages returned for failed lock requests, in this way the lock request could use the timeout as a basis for next request, timeout could be held in the section of the C) The last suggestion and probably the more questionable one is to have an embedded commit for edit-configs on candidate targets . So in this case the session holder owning a lock ( only lock holders should be able to commit) would pass the new configuration in an edit-config as follows :- =A0=A0=A0=A0=A0 =A0=A0 120 rollback-on-error ... The result is a lot less real time gaps (see numbered steps below) and thus a much tighter real-time model can be applied if one was required (in the case of multiple sessions). At present Merge does take care of unlocked edits but we all know that merge conflicts can occur when attempting to merge data so these are currently left to race-conditions which I for one can not allow into my current system. 1) session holder requests get-config with embedded lock request on 2) rpc-reply containing the configuration and lock-timeout 3) edit the configuration 4) edit-config either merges, replaces or creates or deletes the locked config (embed commit if candidate) 5) ok is sent back confirming the edit (and commit if candidate) I hope this will provoke discussion which will lead to improvement of the standard, the outcome hopefully impacting the current draft. I look forward to your comments, Carl. From mbj@tail-f.com Wed Mar 4 12:20:51 2009 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 73F0D3A6D2A for ; Wed, 4 Mar 2009 12:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.093, 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 jCRfBzP4BF6V for ; Wed, 4 Mar 2009 12:20:50 -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 A66753A692E for ; Wed, 4 Mar 2009 12:20:50 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id B014476C4E6 for ; Wed, 4 Mar 2009 21:21:17 +0100 (CET) Date: Wed, 04 Mar 2009 21:21:17 +0100 (CET) Message-Id: <20090304.212117.91501539.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <20090304.182737.97731960.mbj@tail-f.com> References: <20090304171501.98D7F3A6BA0@core3.amsl.com> <20090304.182737.97731960.mbj@tail-f.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-4741bis-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: Wed, 04 Mar 2009 20:20:51 -0000 Hi, I forgot to mention (maybe the obvious) that rfcdiff works fine on this draft: http://tools.ietf.org/rfcdiff?url1=http://www.ietf.org/rfc/rfc4741.txt&url2=http://tools.ietf.org/id/draft-ietf-netconf-4741bis-00.txt /martin From Washam.Fan@huaweisymantec.com Wed Mar 4 22:50:57 2009 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 29FD03A6ADC for ; Wed, 4 Mar 2009 22:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 5d2xqXXF5478 for ; Wed, 4 Mar 2009 22:50:56 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id AFE6C3A67E5 for ; Wed, 4 Mar 2009 22:50:51 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=iso-8859-1 Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KG0006VRTPGGT20@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Thu, 05 Mar 2009 14:51:18 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KG000HIOTPDAR00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Thu, 05 Mar 2009 14:51:16 +0800 (CST) Received: from [10.27.142.189] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 05 Mar 2009 14:51:13 +0800 From: WashamFan To: Carl Sherratt Message-id: Date: Thu, 05 Mar 2009 14:51:13 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: References: Content-transfer-encoding: quoted-printable Cc: netconf@ietf.org Subject: Re: [Netconf] Real Time Gap Improvements to the target configuration locking mechanism 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: Thu, 05 Mar 2009 06:50:57 -0000 Hi=2C If I understand correctly=2C you really want to introduce a new mechanis= m=2C which allows for nested rpcs=2E IMO=2C it seems to break the layered arc= h a little=2E Netconf base protocol allows for pipelining handling of a series of rpcs= =2C see sec 4=2E5=2C rfc4741=2E I don=27t know if it can mitigate your conce= rn=2E Besides=2C It seems to me that there is no so-called =22lock timeout=22 = in rfcs and drafts=2E Generally=2C lock duration is a short period of time=2C= you mentioned =27re-request lock=27 below=2C did you mean renew previous loc= k or compete with potential other sessions to gain a new lock=3F The latte= r may make the situation worse when losing the competition=2E And the former seems to break =22lock duration is a short period of time=22=2E Any comments=3F washam =3E Hi=2C =3E = =3E I would like to suggest some improvements in the way configuration =3E locks are currently handled by the netconf standard and that in dra= ft=2C =3E If we could possibly discuss either the problems/merits of the curr= ent =3E target configuration locking mechanism and also potential =3E problems/merits of my suggestion=2E Hopefully the outcome will be a= n =3E improved locking mechanism which we can add to the working draft=2E= =3E = =3E At present=2C if a NETCONF Session holder (in a multi-session =3E environment) wants to edit a configuration the following happens in= an =3E ok scenario =3A- =3E = =3E 1) session holder requests to obtain a lock =3E 2) ok is sent back confirming they have the lock=2C but for how lon= g=3F =3E 3) get-config whilst they have the lock to ensure it hasn=27t been =3E altered by another session =3E 4) rpc-reply containing the configuration =3E 5) edit the configuration =3E 6) edit-config either merges=2C replaces or creates or deletes the =3E locked uncommited=A0 configuration=2E =3E 7) ok is sent back confirming the edit =3E 8) session holder commits to make the changes apply to the device =3E 9) ok is send back confirming the commitment =3E = =3E What I have noticed is a lot of real-time gaps in a process which I= =3E believe should contain minimal gaps in order to prevent error=2E =3E = =3E A) My first suggestion is to embed the =3Clock=3E request in a =3E =3Cget-config=3E request=2E This removes a real-time gap and ensure= s the =3E session holder isn=27t spending valuable lock time on sending anoth= er =3E request=2E=A0 The request would look something like this =3A- =3E = =3E =3Cget-config=3E =3E =A0=A0=A0=A0=A0 =3C!--=A0 embedded lock =3E=A0 --=3E =3E =A0=A0=A0=A0=A0 =3Clock=3E =3E =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3Ctarget=3E =3E =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3Crun= ning / =3E =3E =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3C/target=3E =3E =A0=A0=A0=A0=A0 =3C/lock=3E =3E =A0=A0=A0=A0=A0 =3C!--- The rest of the get-config request --=3E =3E =A0=A0=A0=A0=A0=A0=A0 =2E=2E=2E=2E=2E =3E =3C/get-config=3E =3E = =3E B) The second suggestion I have is to embed a lock-timeout in the =3E response=2C the session holder can use this to re-request the lock = if it =3E needs more edit-time=2C loosing the lock during a long edit time ma= y be =3E fustrating to a consoler user=2E =3E = =3E So The rpc-reply returning the locked configuration would contain t= he =3E following =3A- =3E =3Crpc-reply message-id=3D=22xxx=22=3E =3E =A0=A0 =3Clock-timeout=3E300=3C/lock-timeout=3E =3E =A0=A0 =3Cconfig=3E =3E =A0=A0=A0=A0=A0=A0 =2E=2E=2E=2E=2E=2E =3E =A0=A0 =3C/config=3E =3E =3C/rpc-reply=3E =3E = =3E I would also suggest including the =3Clock-timeout=3E element in =3E =3Crpc-error=3E messages returned for failed lock requests=2C in th= is way =3E the lock request could use the timeout as a basis for next request=2C= =3E timeout could be held in the =3Cerror-info=3E section of the =3Crpc= -error=3E =3E = =3E = =3E C) The last suggestion and probably the more questionable one is to= =3E have an embedded commit for edit-configs on candidate targets =2E =3E = =3E So in this case the session holder owning a lock ( only lock holder= s =3E should be able to commit) would pass the new configuration in an =3E edit-config as follows =3A- =3E = =3E =3Cedit-config=3E =3E =A0=A0=A0=A0=A0 =3C!-- Embedded commit --=3E =3E =A0=A0 =3Ccommit=3E =3E =3Cconfirmed/=3E =3E =3Cconfirm-timeout=3E120=3C/confirm-timeout=3E =3E =3C/commit=3E =3E = =3E =3Ctarget=3E =3E =3Ccandidate/=3E =3E =3C/target=3E =3E =3Cerror-option=3Erollback-on-error=3C/error-option=3E =3E =3Cconfig=3E =3E =2E=2E=2E =3E =3C/config=3E =3E =3C/edit-config=3E =3E = =3E The result is a lot less real time gaps (see numbered steps below) =3E and thus a much tighter real-time model can be applied if one was =3E required (in the case of multiple sessions)=2E At present Merge doe= s =3E take care of unlocked edits but we all know that merge conflicts ca= n =3E occur when attempting to merge data so these are currently left to =3E race-conditions which I for one can not allow into my current syste= m=2E =3E = =3E 1) session holder requests get-config with embedded lock request o= n =3E 2) rpc-reply containing the configuration and lock-timeout =3E 3) edit the configuration =3E 4) edit-config either merges=2C replaces or creates or deletes the =3E locked config (embed commit if candidate) =3E 5) ok is sent back confirming the edit (and commit if candidate) =3E = =3E = =3E I hope this will provoke discussion which will lead to improvement = of =3E the standard=2C the outcome hopefully impacting the current draft=2E= =3E = =3E I look forward to your comments=2C =3E Carl=2E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E Netconf mailing list =3E Netconf=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/netconf =3E From csherratt@syphan.com Thu Mar 5 01:55:57 2009 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 A45F728C37B for ; Thu, 5 Mar 2009 01:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 qitk36RFdEzb for ; Thu, 5 Mar 2009 01:55:56 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id EDAB428C372 for ; Thu, 5 Mar 2009 01:55:55 -0800 (PST) Received: by fxm24 with SMTP id 24so3262545fxm.37 for ; Thu, 05 Mar 2009 01:56:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.92.9 with SMTP id p9mr808503fgb.15.1236246983885; Thu, 05 Mar 2009 01:56:23 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Mar 2009 09:56:23 +0000 Message-ID: From: Carl Sherratt To: netconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Netconf] Real Time Gap Improvements to the target configuration locking mechanism 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: Thu, 05 Mar 2009 09:55:57 -0000 Hi, > If I understand correctly, you really want to introduce a new mechanism, > which allows for nested rpcs. IMO, it seems to break the layered arch > a little. I'm questioning how valid it is to have lock at the rpc layer. A session would only need the lock in order to perform another rpc operation on the configuration, therefore I see the lock as an optional element of those rpcs which can alter the contents of a target configuration. At present, the current protocol defines a competitive lock mechanism. There is no "lock timeout" at present and this means the "short period of time" is undefined. In some cases, where the lock is only needed for that "short period of time" this works, however, for other cases, where e.g session A requires the lock for a =A0longer period of =A0time, the lock is lost and the configuration may be =A0changed by e.g session B, leaving session A with significant changes on out-of-date configuration. =A0This can be resolved with the use of candidate merge, however, it seems like a lot of processing for a simple operation, if the lock is renewed then this prevents any need to tidy up conflicts. > Besides, It seems to me that there is no so-called "lock timeout" in > rfcs and drafts. Generally, lock duration is a short period of time, you > mentioned 're-request lock' below, did you mean renew previous lock > or compete with potential other sessions to gain a new lock? The latter > may make the situation worse when losing the competition. And the > former seems to break "lock duration is a short period of time". In answer to your question, I am referring to both lock renewal and lock-request. I agree that providing time-out to all lock requesters can lead to higher competition although in reality this would just mean less failed lock-requests (less traffic) because lock-requesters would only re-request at strategic points in time. A restriction which I haven't suggested until now is to have a limit on renewals, a limit may resolve your concerns on a session holding a lock for too long a period, this should be configurable and shout be a 'longer period of time' in comparison to the lock-timeout which should be a 'short period of time', although examples of real time values should be given otherwise the term short becomes meaningless. I quote the RFC here in order to focus on the purpose of lock :- " =A0 The lock operation allows the client to lock the configuration =A0 =A0 =A0system of a device. =A0Such locks are intended to be short-lived= and =A0 =A0 =A0allow a client to make a change without fear of interaction with =A0 =A0 =A0other NETCONF clients, non-NETCONF clients (e.g., SNMP and comma= nd =A0 =A0 =A0line interface (CLI) scripts), and human users" Why short-lived? The short-lived lock ensures that hanging sessions timeout and thus the lock gets dropped. I don't believe there is any statement that the period of time-out should not be defined, I see time-out definition as a useful element of data by both Netconf Session Server and Client and lock-renewal as something that would forfill the above quote from the RFC. Carl On Thu, Mar 5, 2009 at 6:51 AM, WashamFan w= rote: > Hi, > > If I understand correctly, you really want to introduce a new mechanism, > which allows for nested rpcs. IMO, it seems to break the layered arch > a little. > > Netconf base protocol allows for pipelining handling of a series of rpcs, > see sec 4.5, rfc4741. I don't know if it can mitigate your concern. > > Besides, It seems to me that there is no so-called "lock timeout" in > rfcs and drafts. Generally, lock duration is a short period of time, you > mentioned 're-request lock' below, did you mean renew previous lock > or compete with potential other sessions to gain a new lock? The latter > may make the situation worse when losing the competition. And the > former seems to break "lock duration is a short period of time". > > Any comments? > > washam > >> Hi, >> >> =A0I would like to suggest some improvements in the way configuration >> =A0locks are currently handled by the netconf standard and that in draft= , >> =A0If we could possibly discuss either the problems/merits of the curren= t >> =A0target configuration locking mechanism and also potential >> =A0problems/merits of my suggestion. Hopefully the outcome will be an >> =A0improved locking mechanism which we can add to the working draft. >> >> =A0At present, if a NETCONF Session holder (in a multi-session >> =A0environment) wants to edit a configuration the following happens in a= n >> =A0ok scenario :- >> >> =A01) session holder requests to obtain a lock >> =A02) ok is sent back confirming they have the lock, but for how long? >> =A03) get-config whilst they have the lock to ensure it hasn't been >> =A0altered by another session >> =A04) rpc-reply containing the configuration >> =A05) edit the configuration >> =A06) edit-config either merges, replaces or creates or deletes the >> =A0locked uncommited=A0 configuration. >> =A07) ok is sent back confirming the edit >> =A08) session holder commits to make the changes apply to the device >> =A09) ok is send back confirming the commitment >> >> =A0What I have noticed is a lot of real-time gaps in a process which I >> =A0believe should contain minimal gaps in order to prevent error. >> >> =A0A) My first suggestion is to embed the request in a >> =A0 request. This removes a real-time gap and ensures the >> =A0session holder isn't spending valuable lock time on sending another >> =A0request.=A0 The request would look something like this :- >> >> =A0 >> =A0=A0=A0=A0=A0=A0 >> =A0=A0=A0=A0=A0=A0 >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >> =A0=A0=A0=A0=A0=A0 >> =A0=A0=A0=A0=A0=A0 >> =A0=A0=A0=A0=A0=A0=A0=A0 ..... >> =A0 >> >> =A0B) The second suggestion I have is to embed a lock-timeout in the >> =A0response, the session holder can use this to re-request the lock if i= t >> =A0needs more edit-time, loosing the lock during a long edit time may be >> =A0fustrating to a consoler user. >> >> =A0So The rpc-reply returning the locked configuration would contain the >> =A0following :- >> =A0 >> =A0=A0=A0 300 >> =A0=A0=A0 >> =A0=A0=A0=A0=A0=A0=A0 ...... >> =A0=A0=A0 >> =A0 >> >> =A0I would also suggest including the element in >> =A0 messages returned for failed lock requests, in this way >> =A0the lock request could use the timeout as a basis for next request, >> =A0timeout could be held in the section of the >> >> >> =A0C) The last suggestion and probably the more questionable one is to >> =A0have an embedded commit for edit-configs on candidate targets . >> >> =A0So in this case the session holder owning a lock ( only lock holders >> =A0should be able to commit) would pass the new configuration in an >> =A0edit-config as follows :- >> >> =A0 >> =A0=A0=A0=A0=A0=A0 >> =A0=A0=A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 120 >> =A0 =A0 =A0 =A0 >> >> =A0 =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 rollback-on-error >> =A0 =A0 =A0 =A0 =A0 >> =A0... >> =A0 =A0 =A0 =A0 =A0 >> =A0 >> >> =A0The result is a lot less real time gaps (see numbered steps below) >> =A0and thus a much tighter real-time model can be applied if one was >> =A0required (in the case of multiple sessions). At present Merge does >> =A0take care of unlocked edits but we all know that merge conflicts can >> =A0occur when attempting to merge data so these are currently left to >> =A0race-conditions which I for one can not allow into my current system. >> >> =A01) session holder requests =A0get-config with embedded lock request o= n >> =A02) rpc-reply containing the configuration and lock-timeout >> =A03) edit the configuration >> =A04) edit-config either merges, replaces or creates or deletes the >> =A0locked config (embed commit if candidate) >> =A05) ok is sent back confirming the edit (and commit if candidate) >> >> >> =A0I hope this will provoke discussion which will lead to improvement of >> =A0the standard, the outcome hopefully impacting the current draft. >> >> =A0I look forward to your comments, >> =A0Carl. >> =A0_______________________________________________ >> =A0Netconf mailing list >> =A0Netconf@ietf.org >> =A0https://www.ietf.org/mailman/listinfo/netconf >> > -- Syphan Technologies True 10G IDS D +441756631203 M +447932773346 E csherratt@syphan.com --=20 Syphan Technologies True 10G IDS D +441756631203 M +447932773346 E csherratt@syphan.com From Washam.Fan@huaweisymantec.com Thu Mar 5 04:30:13 2009 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 D76103A6850 for ; Thu, 5 Mar 2009 04:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.308, 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 fV6mvZxzzr1I for ; Thu, 5 Mar 2009 04:30:11 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 51B2E28C224 for ; Thu, 5 Mar 2009 04:30:11 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=iso-8859-1 Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KG1006DY9EXGT60@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Thu, 05 Mar 2009 20:30:35 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KG100G7B9EVVK10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Thu, 05 Mar 2009 20:30:33 +0800 (CST) Received: from [10.27.142.189] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 05 Mar 2009 20:30:31 +0800 From: WashamFan To: Carl Sherratt Message-id: Date: Thu, 05 Mar 2009 20:30:31 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: References: Content-transfer-encoding: quoted-printable Cc: netconf@ietf.org Subject: Re: [Netconf] Real Time Gap Improvements to the target configuration locking mechanism 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: Thu, 05 Mar 2009 12:30:13 -0000 Hi=2C Lock is in rpc layer=2C I am not sure if it will be or not in future=2E = But at present=2C I think it is a little difficult to convince the members to change it=2C since I= think it is a major change=2C and maybe has some compatibility problems with exis= ting implementation=2E Well=2C I admit we=27re not told how to measure =27short-lived=27=2E But= the reality is=2C = lock would not be released unless the owner unlock or session abort=2C s= o I = could lock for a long time as long as I like=2E I must admit I am not sure how your problem can impact the protocol=2E I expect someone else commenting on this=2E washam =3E Hi=2C =3E = =3E =3E If I understand correctly=2C you really want to introduce a new= mechanism=2C =3E =3E which allows for nested rpcs=2E IMO=2C it seems to break the la= yered arch =3E =3E a little=2E =3E = =3E I=27m questioning how valid it is to have lock at the rpc layer=2E = A =3E session would only need the lock in order to perform another rpc =3E operation on the configuration=2C therefore I see the lock as an =3E optional element of those rpcs which can alter the contents of a =3E target configuration=2E =3E = =3E At present=2C the current protocol defines a competitive lock mecha= nism=2E =3E There is no =22lock timeout=22 at present and this means the =22sho= rt period =3E of time=22 is undefined=2E In some cases=2C where the lock is only = needed =3E for that =22short period of time=22 this works=2C however=2C for ot= her cases=2C =3E where e=2Eg session A requires the lock for a =A0longer period of =A0= time=2C =3E the lock is lost and the configuration may be =A0changed by e=2Eg s= ession =3E B=2C leaving session A with significant changes on out-of-date =3E configuration=2E =A0This can be resolved with the use of candidate = merge=2C =3E however=2C it seems like a lot of processing for a simple operation= =2C if =3E the lock is renewed then this prevents any need to tidy up conflict= s=2E =3E = =3E =3E Besides=2C It seems to me that there is no so-called =22lock ti= meout=22 in =3E =3E rfcs and drafts=2E Generally=2C lock duration is a short period= of = =3E time=2C you =3E =3E mentioned =27re-request lock=27 below=2C did you mean renew pre= vious lock =3E =3E or compete with potential other sessions to gain a new lock=3F = The latter =3E =3E may make the situation worse when losing the competition=2E And= the =3E =3E former seems to break =22lock duration is a short period of tim= e=22=2E =3E = =3E In answer to your question=2C I am referring to both lock renewal a= nd =3E lock-request=2E I agree that providing time-out to all lock request= ers =3E can lead to higher competition although in reality this would just =3E mean less failed lock-requests (less traffic) because lock-requeste= rs =3E would only re-request at strategic points in time=2E A restriction = which =3E I haven=27t suggested until now is to have a limit on renewals=2C a= limit =3E may resolve your concerns on a session holding a lock for too long = a =3E period=2C this should be configurable and shout be a =27longer peri= od of =3E time=27 in comparison to the lock-timeout which should be a =27shor= t =3E period of time=27=2C although examples of real time values should b= e given =3E otherwise the term short becomes meaningless=2E =3E = =3E I quote the RFC here in order to focus on the purpose of lock =3A- =3E = =3E =22 =A0 The lock operation allows the client to lock the configurat= ion =3E =A0 =A0 =A0system of a device=2E =A0Such locks are intended to be s= hort-lived and =3E =A0 =A0 =A0allow a client to make a change without fear of interact= ion with =3E =A0 =A0 =A0other NETCONF clients=2C non-NETCONF clients (e=2Eg=2E=2C= SNMP and command =3E =A0 =A0 =A0line interface (CLI) scripts)=2C and human users=22 =3E = =3E Why short-lived=3F The short-lived lock ensures that hanging sessio= ns =3E timeout and thus the lock gets dropped=2E I don=27t believe there i= s any =3E statement that the period of time-out should not be defined=2C I se= e =3E time-out definition as a useful element of data by both Netconf =3E Session Server and Client and lock-renewal as something that would =3E forfill the above quote from the RFC=2E =3E = =3E Carl =3E = =3E = =3E On Thu=2C Mar 5=2C 2009 at 6=3A51 AM=2C WashamFan = =3E =3CWasham=2EFan=40huaweisymantec=2Ecom=3E wrote=3A =3E =3E Hi=2C =3E =3E =3E =3E If I understand correctly=2C you really want to introduce a new= mechanism=2C =3E =3E which allows for nested rpcs=2E IMO=2C it seems to break the la= yered arch =3E =3E a little=2E =3E =3E =3E =3E Netconf base protocol allows for pipelining handling of a serie= s of = =3E rpcs=2C =3E =3E see sec 4=2E5=2C rfc4741=2E I don=27t know if it can mitigate y= our concern=2E =3E =3E =3E =3E Besides=2C It seems to me that there is no so-called =22lock ti= meout=22 in =3E =3E rfcs and drafts=2E Generally=2C lock duration is a short period= of = =3E time=2C you =3E =3E mentioned =27re-request lock=27 below=2C did you mean renew pre= vious lock =3E =3E or compete with potential other sessions to gain a new lock=3F = The latter =3E =3E may make the situation worse when losing the competition=2E And= the =3E =3E former seems to break =22lock duration is a short period of tim= e=22=2E =3E =3E =3E =3E Any comments=3F =3E =3E =3E =3E washam =3E =3E =3E =3E=3E Hi=2C =3E =3E=3E =3E =3E=3E =A0I would like to suggest some improvements in the way conf= iguration =3E =3E=3E =A0locks are currently handled by the netconf standard and t= hat in draft=2C =3E =3E=3E =A0If we could possibly discuss either the problems/merits o= f the current =3E =3E=3E =A0target configuration locking mechanism and also potential= =3E =3E=3E =A0problems/merits of my suggestion=2E Hopefully the outcome= will be an =3E =3E=3E =A0improved locking mechanism which we can add to the workin= g draft=2E =3E =3E=3E =3E =3E=3E =A0At present=2C if a NETCONF Session holder (in a multi-ses= sion =3E =3E=3E =A0environment) wants to edit a configuration the following = happens = =3E in an =3E =3E=3E =A0ok scenario =3A- =3E =3E=3E =3E =3E=3E =A01) session holder requests to obtain a lock =3E =3E=3E =A02) ok is sent back confirming they have the lock=2C but f= or how long=3F =3E =3E=3E =A03) get-config whilst they have the lock to ensure it hasn= =27t been =3E =3E=3E =A0altered by another session =3E =3E=3E =A04) rpc-reply containing the configuration =3E =3E=3E =A05) edit the configuration =3E =3E=3E =A06) edit-config either merges=2C replaces or creates or de= letes the =3E =3E=3E =A0locked uncommited=A0 configuration=2E =3E =3E=3E =A07) ok is sent back confirming the edit =3E =3E=3E =A08) session holder commits to make the changes apply to th= e device =3E =3E=3E =A09) ok is send back confirming the commitment =3E =3E=3E =3E =3E=3E =A0What I have noticed is a lot of real-time gaps in a proce= ss which = =3E I =3E =3E=3E =A0believe should contain minimal gaps in order to prevent e= rror=2E =3E =3E=3E =3E =3E=3E =A0A) My first suggestion is to embed the =3Clock=3E request= in a =3E =3E=3E =A0=3Cget-config=3E request=2E This removes a real-time gap = and ensures the =3E =3E=3E =A0session holder isn=27t spending valuable lock time on sen= ding another =3E =3E=3E =A0request=2E=A0 The request would look something like this = =3A- =3E =3E=3E =3E =3E=3E =A0=3Cget-config=3E =3E =3E=3E =A0=A0=A0=A0=A0=A0 =3C!--=A0 embedded lock =3E=A0 --=3E =3E =3E=3E =A0=A0=A0=A0=A0=A0 =3Clock=3E =3E =3E=3E =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3Ctarge= t=3E =3E =3E=3E =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 =3Crunning / =3E =3E =3E=3E =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3C/t= arget=3E =3E =3E=3E =A0=A0=A0=A0=A0=A0 =3C/lock=3E =3E =3E=3E =A0=A0=A0=A0=A0=A0 =3C!--- The rest of the get-config reques= t --=3E =3E =3E=3E =A0=A0=A0=A0=A0=A0=A0=A0 =2E=2E=2E=2E=2E =3E =3E=3E =A0=3C/get-config=3E =3E =3E=3E =3E =3E=3E =A0B) The second suggestion I have is to embed a lock-timeou= t in the =3E =3E=3E =A0response=2C the session holder can use this to re-request= the lock = =3E if it =3E =3E=3E =A0needs more edit-time=2C loosing the lock during a long ed= it time = =3E may be =3E =3E=3E =A0fustrating to a consoler user=2E =3E =3E=3E =3E =3E=3E =A0So The rpc-reply returning the locked configuration would= contain = =3E the =3E =3E=3E =A0following =3A- =3E =3E=3E =A0=3Crpc-reply message-id=3D=22xxx=22=3E =3E =3E=3E =A0=A0=A0 =3Clock-timeout=3E300=3C/lock-timeout=3E =3E =3E=3E =A0=A0=A0 =3Cconfig=3E =3E =3E=3E =A0=A0=A0=A0=A0=A0=A0 =2E=2E=2E=2E=2E=2E =3E =3E=3E =A0=A0=A0 =3C/config=3E =3E =3E=3E =A0=3C/rpc-reply=3E =3E =3E=3E =3E =3E=3E =A0I would also suggest including the =3Clock-timeout=3E ele= ment in =3E =3E=3E =A0=3Crpc-error=3E messages returned for failed lock request= s=2C in this way =3E =3E=3E =A0the lock request could use the timeout as a basis for nex= t request=2C =3E =3E=3E =A0timeout could be held in the =3Cerror-info=3E section of = the =3Crpc-error=3E =3E =3E=3E =3E =3E=3E =3E =3E=3E =A0C) The last suggestion and probably the more questionable= one is = =3E to =3E =3E=3E =A0have an embedded commit for edit-configs on candidate tar= gets =2E =3E =3E=3E =3E =3E=3E =A0So in this case the session holder owning a lock ( only l= ock holders =3E =3E=3E =A0should be able to commit) would pass the new configuratio= n in an =3E =3E=3E =A0edit-config as follows =3A- =3E =3E=3E =3E =3E=3E =A0=3Cedit-config=3E =3E =3E=3E =A0=A0=A0=A0=A0=A0 =3C!-- Embedded commit --=3E =3E =3E=3E =A0=A0=A0 =A0 =A0 =A0=3Ccommit=3E =3E =3E=3E =A0 =A0 =A0 =A0 =A0 =3Cconfirmed/=3E =3E =3E=3E =A0 =A0 =A0 =A0 =A0 =3Cconfirm-timeout=3E120=3C/confirm-time= out=3E =3E =3E=3E =A0 =A0 =A0 =A0 =3C/commit=3E =3E =3E=3E =3E =3E=3E =A0 =A0 =A0 =A0 =A0 =3Ctarget=3E =3E =3E=3E =A0 =A0 =A0 =A0 =A0 =A0 =3Ccandidate/=3E =3E =3E=3E =A0 =A0 =A0 =A0 =A0 =3C/target=3E =3E =3E=3E =A0 =A0 =A0 =A0 =A0 =3Cerror-option=3Erollback-on-error=3C/e= rror-option=3E =3E =3E=3E =A0 =A0 =A0 =A0 =A0 =3Cconfig=3E =3E =3E=3E =A0=2E=2E=2E =3E =3E=3E =A0 =A0 =A0 =A0 =A0 =3C/config=3E =3E =3E=3E =A0=3C/edit-config=3E =3E =3E=3E =3E =3E=3E =A0The result is a lot less real time gaps (see numbered ste= ps below) =3E =3E=3E =A0and thus a much tighter real-time model can be applied if= one was =3E =3E=3E =A0required (in the case of multiple sessions)=2E At present= Merge does =3E =3E=3E =A0take care of unlocked edits but we all know that merge co= nflicts = =3E can =3E =3E=3E =A0occur when attempting to merge data so these are currentl= y left to =3E =3E=3E =A0race-conditions which I for one can not allow into my cur= rent system=2E =3E =3E=3E =3E =3E=3E =A01) session holder requests =A0get-config with embedded lo= ck request = =3E on =3E =3E=3E =A02) rpc-reply containing the configuration and lock-timeou= t =3E =3E=3E =A03) edit the configuration =3E =3E=3E =A04) edit-config either merges=2C replaces or creates or de= letes the =3E =3E=3E =A0locked config (embed commit if candidate) =3E =3E=3E =A05) ok is sent back confirming the edit (and commit if can= didate) =3E =3E=3E =3E =3E=3E =3E =3E=3E =A0I hope this will provoke discussion which will lead to = =3E improvement of =3E =3E=3E =A0the standard=2C the outcome hopefully impacting the curre= nt draft=2E =3E =3E=3E =3E =3E=3E =A0I look forward to your comments=2C =3E =3E=3E =A0Carl=2E =3E =3E=3E =A0=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F =3E =3E=3E =A0Netconf mailing list =3E =3E=3E =A0Netconf=40ietf=2Eorg =3E =3E=3E =A0https=3A//www=2Eietf=2Eorg/mailman/listinfo/netconf =3E =3E=3E =3E =3E =3E = =3E = =3E = =3E -- =3E Syphan Technologies =3E True 10G IDS =3E D +441756631203 =3E M +447932773346 =3E E csherratt=40syphan=2Ecom =3E = =3E = =3E = =3E -- = =3E Syphan Technologies =3E True 10G IDS =3E D +441756631203 =3E M +447932773346 =3E E csherratt=40syphan=2Ecom =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E Netconf mailing list =3E Netconf=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/netconf =3E From bertietf@bwijnen.net Fri Mar 6 13:41:45 2009 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 D3CB93A6923 for ; Fri, 6 Mar 2009 13:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.285 X-Spam-Level: X-Spam-Status: No, score=-0.285 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2Mko5J+4RPn for ; Fri, 6 Mar 2009 13:41:44 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 312A83A6869 for ; Fri, 6 Mar 2009 13:41:44 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1Lfho5-0002cr-A1; Fri, 06 Mar 2009 22:42:13 +0100 Message-ID: <934D92B9274946C5A1E1A3C021DFCA3D@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Carl Sherratt" , References: In-Reply-To: Date: Fri, 6 Mar 2009 22:19:23 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E04_01C99EA9.9A772150" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: Re: [Netconf] Real Time Gap Improvements to the target configurationlocking mechanism 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, 06 Mar 2009 21:41:45 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0E04_01C99EA9.9A772150 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am OK to have this discussion on the mailing list. However, as document shepherd for the partial-lock draft I object to the idea that this discussion and/or its outcome would have an impact on this draft. We have finished WG Last Call, We have addressed all comments in a new revision and the doc is ready to go to AD and IESG. Besides, in order to make sense, the below discussion would apply to both the base protocol which includes the global lock and to the partial lock draft. So if we come to consensus that something along the lines of the proposals below needs to be done, then we need to think of it in generic terms, and it will impact the base protocol. We need to figure out how to deal with that ... that is IF we do come to = consensus that something needs to be done/changed. Bert ----- Original Message -----=20 From: Carl Sherratt=20 To: netconf@ietf.org=20 Sent: Wednesday, March 04, 2009 8:49 PM Subject: [Netconf] Real Time Gap Improvements to the target = configurationlocking mechanism Hi, I would like to suggest some improvements in the way configuration locks are currently handled by the netconf standard and that in draft, If we could possibly discuss either the problems/merits of the current target configuration locking mechanism and also potential problems/merits of my suggestion. Hopefully the outcome will be an improved locking mechanism which we can add to the working draft. At present, if a NETCONF Session holder (in a multi-session environment) wants to edit a configuration the following happens in an ok scenario :- 1) session holder requests to obtain a lock 2) ok is sent back confirming they have the lock, but for how long? 3) get-config whilst they have the lock to ensure it hasn't been altered by another session 4) rpc-reply containing the configuration 5) edit the configuration 6) edit-config either merges, replaces or creates or deletes the locked uncommited configuration. 7) ok is sent back confirming the edit 8) session holder commits to make the changes apply to the device 9) ok is send back confirming the commitment What I have noticed is a lot of real-time gaps in a process which I believe should contain minimal gaps in order to prevent error. A) My first suggestion is to embed the request in a request. This removes a real-time gap and ensures the session holder isn't spending valuable lock time on sending another request. The request would look something like this :- ..... B) The second suggestion I have is to embed a lock-timeout in the response, the session holder can use this to re-request the lock if it needs more edit-time, loosing the lock during a long edit time may be fustrating to a consoler user. So The rpc-reply returning the locked configuration would contain the following :- 300 ...... I would also suggest including the element in messages returned for failed lock requests, in this way the lock request could use the timeout as a basis for next request, timeout could be held in the section of the C) The last suggestion and probably the more questionable one is to have an embedded commit for edit-configs on candidate targets . So in this case the session holder owning a lock ( only lock holders should be able to commit) would pass the new configuration in an edit-config as follows :- 120 rollback-on-error ... The result is a lot less real time gaps (see numbered steps below) and thus a much tighter real-time model can be applied if one was required (in the case of multiple sessions). At present Merge does take care of unlocked edits but we all know that merge conflicts can occur when attempting to merge data so these are currently left to race-conditions which I for one can not allow into my current system. 1) session holder requests get-config with embedded lock request on 2) rpc-reply containing the configuration and lock-timeout 3) edit the configuration 4) edit-config either merges, replaces or creates or deletes the locked config (embed commit if candidate) 5) ok is sent back confirming the edit (and commit if candidate) I hope this will provoke discussion which will lead to improvement of the standard, the outcome hopefully impacting the current draft. I look forward to your comments, Carl. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_0E04_01C99EA9.9A772150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am OK to have this discussion on the mailing=20 list.
However, as document shepherd for the partial-lock = draft I=20 object to the
idea that this discussion and/or its outcome would = have an=20 impact on
this draft. We have finished WG Last Call, We have = addressed=20 all
comments in a new revision and the doc is ready to = go to AD=20 and IESG.
 
Besides, in order to make sense, the below = discussion would=20 apply to
both the base protocol which includes the global = lock and to=20 the
partial lock draft. So if we come to consensus that = something=20 along the
lines of the proposals below needs to be done, = then we=20 need to think
of it in generic terms, and it will impact the base = protocol.=20 We need
to figure out how to deal with that ... that is IF = we do come=20 to consensus
that something needs to be = done/changed.
 
Bert
 
----- Original Message -----
From:=20 Carl=20 Sherratt
Sent: Wednesday, March 04, 2009 = 8:49=20 PM
Subject: [Netconf] Real Time = Gap=20 Improvements to the target configurationlocking mechanism

Hi,

I would like to suggest some improvements in = the way=20 configuration
locks are currently handled by the netconf standard = and that=20 in draft,
If we could possibly discuss either the problems/merits = of the=20 current
target configuration locking mechanism and also=20 potential
problems/merits of my suggestion. Hopefully the outcome = will be=20 an
improved locking mechanism which we can add to the working=20 draft.

At present, if a NETCONF Session holder (in a=20 multi-session
environment) wants to edit a configuration the = following=20 happens in an
ok scenario :-

1) session holder requests to = obtain a=20 lock
2) ok is sent back confirming they have the lock, but for how=20 long?
3) get-config whilst they have the lock to ensure it hasn't=20 been
altered by another session
4) rpc-reply containing the=20 configuration
5) edit the configuration
6) edit-config either = merges,=20 replaces or creates or deletes the
locked uncommited = configuration.
7)=20 ok is sent back confirming the edit
8) session holder commits to = make the=20 changes apply to the device
9) ok is send back confirming the=20 commitment

What I have noticed is a lot of real-time gaps in a = process=20 which I
believe should contain minimal gaps in order to prevent=20 error.

A) My first suggestion is to embed the <lock> = request in=20 a
<get-config> request. This removes a real-time gap and = ensures=20 the
session holder isn't spending valuable lock time on sending=20 another
request. The request would look something like this=20 :-

<get-config>
<!-- embedded lock >=20 -->
<lock>
<target>
<running /=20 >
</target>
</lock>
<!--- The rest of the=20 get-config request -->
.....
</get-config>

B) = The second=20 suggestion I have is to embed a lock-timeout in the
response, the = session=20 holder can use this to re-request the lock if it
needs more = edit-time,=20 loosing the lock during a long edit time may be
fustrating to a = consoler=20 user.

So The rpc-reply returning the locked configuration would = contain=20 the
following :-
<rpc-reply=20 = message-id=3D"xxx">
<lock-timeout>300</lock-timeout><config>
......
</config>
</rpc-reply>
I=20 would also suggest including the <lock-timeout> element=20 in
<rpc-error> messages returned for failed lock requests, in = this=20 way
the lock request could use the timeout as a basis for next=20 request,
timeout could be held in the <error-info> section of = the=20 <rpc-error>


C) The last suggestion and probably the = more=20 questionable one is to
have an embedded commit for edit-configs on=20 candidate targets .

So in this case the session holder owning a = lock (=20 only lock holders
should be able to commit) would pass the new=20 configuration in an
edit-config as follows=20 :-

<edit-config>
<!-- Embedded commit=20 -->
     =20 <commit>
        =20 <confirmed/>
         = = <confirm-timeout>120</confirm-timeout>
   &= nbsp;  =20 = </commit>

        =20 = <target>
         &= nbsp;=20 <candidate/>
         = </target>
        =20 = <error-option>rollback-on-error</error-option>
  = ;      =20 = <config>
...
        = =20 </config>
</edit-config>

The result is a lot = less real=20 time gaps (see numbered steps below)
and thus a much tighter = real-time=20 model can be applied if one was
required (in the case of multiple=20 sessions). At present Merge does
take care of unlocked edits but we = all=20 know that merge conflicts can
occur when attempting to merge data = so these=20 are currently left to
race-conditions which I for one can not allow = into my=20 current system.

1) session holder requests  get-config = with=20 embedded lock request on
2) rpc-reply containing the configuration = and=20 lock-timeout
3) edit the configuration
4) edit-config either = merges,=20 replaces or creates or deletes the
locked config (embed commit if=20 candidate)
5) ok is sent back confirming the edit (and commit if=20 candidate)


I hope this will provoke discussion which will = lead to=20 improvement of
the standard, the outcome hopefully impacting the = current=20 draft.

I look forward to your=20 = comments,
Carl.
_______________________________________________
= Netconf=20 mailing list
Netconf@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netconf
------=_NextPart_000_0E04_01C99EA9.9A772150-- From andy@netconfcentral.com Fri Mar 6 14:11:37 2009 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 11C413A677C for ; Fri, 6 Mar 2009 14:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=-0.041, 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 ZSpfCgzSNJmf for ; Fri, 6 Mar 2009 14:11:35 -0800 (PST) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id A7C853A6905 for ; Fri, 6 Mar 2009 14:11:35 -0800 (PST) Received: (qmail 21894 invoked from network); 6 Mar 2009 22:12:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.225.83 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 6 Mar 2009 22:12:06 -0000 X-YMail-OSG: 3DaZNacVM1kKDn2nmjq0T06jETwYx.LMhTMFSkKmzq.4y1xX2IVB5FZGBbbAlTjPPJxbLpgxYGWH_d27pT65QTBJREt5dwkE99.CcodKYrcLADZRWfvnCJaFm_j8agY4EGuXx9TF4SeWDgDPxR_Cqp05mPWUQe5UJ.nwhTag3SrBfxxPIftA.Y_8 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49B19FB5.1090708@netconfcentral.com> Date: Fri, 06 Mar 2009 14:12:05 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <934D92B9274946C5A1E1A3C021DFCA3D@BertLaptop> In-Reply-To: <934D92B9274946C5A1E1A3C021DFCA3D@BertLaptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Real Time Gap Improvements to the target configurationlocking mechanism 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, 06 Mar 2009 22:11:37 -0000 Bert Wijnen (IETF) wrote: > I am OK to have this discussion on the mailing list. > However, as document shepherd for the partial-lock draft I object to the > idea that this discussion and/or its outcome would have an impact on > this draft. We have finished WG Last Call, We have addressed all > comments in a new revision and the doc is ready to go to AD and IESG. > > Besides, in order to make sense, the below discussion would apply to > both the base protocol which includes the global lock and to the > partial lock draft. So if we come to consensus that something along the > lines of the proposals below needs to be done, then we need to think > of it in generic terms, and it will impact the base protocol. We need > to figure out how to deal with that ... that is IF we do come to consensus > that something needs to be done/changed. > The 2 step process from the Good Old Days applies here: 1) Do we think there is a problem to be solved? 2) If yes on (1), then what solution options to we have? I will not comment on (2), except that the NETCONF layer violation is a non-starter. IMO, there is no real problem to be solved here. A manager can send back-to-back or use partial-lock. > Bert Andy > > > ----- Original Message ----- > *From:* Carl Sherratt > *To:* netconf@ietf.org > *Sent:* Wednesday, March 04, 2009 8:49 PM > *Subject:* [Netconf] Real Time Gap Improvements to the target > configurationlocking mechanism > > Hi, > > I would like to suggest some improvements in the way configuration > locks are currently handled by the netconf standard and that in draft, > If we could possibly discuss either the problems/merits of the current > target configuration locking mechanism and also potential > problems/merits of my suggestion. Hopefully the outcome will be an > improved locking mechanism which we can add to the working draft. > > At present, if a NETCONF Session holder (in a multi-session > environment) wants to edit a configuration the following happens in an > ok scenario :- > > 1) session holder requests to obtain a lock > 2) ok is sent back confirming they have the lock, but for how long? > 3) get-config whilst they have the lock to ensure it hasn't been > altered by another session > 4) rpc-reply containing the configuration > 5) edit the configuration > 6) edit-config either merges, replaces or creates or deletes the > locked uncommited configuration. > 7) ok is sent back confirming the edit > 8) session holder commits to make the changes apply to the device > 9) ok is send back confirming the commitment > > What I have noticed is a lot of real-time gaps in a process which I > believe should contain minimal gaps in order to prevent error. > > A) My first suggestion is to embed the request in a > request. This removes a real-time gap and ensures the > session holder isn't spending valuable lock time on sending another > request. The request would look something like this :- > > > > > > > > > > ..... > > > B) The second suggestion I have is to embed a lock-timeout in the > response, the session holder can use this to re-request the lock if it > needs more edit-time, loosing the lock during a long edit time may be > fustrating to a consoler user. > > So The rpc-reply returning the locked configuration would contain the > following :- > > 300 > > ...... > > > > I would also suggest including the element in > messages returned for failed lock requests, in this way > the lock request could use the timeout as a basis for next request, > timeout could be held in the section of the > > > C) The last suggestion and probably the more questionable one is to > have an embedded commit for edit-configs on candidate targets . > > So in this case the session holder owning a lock ( only lock holders > should be able to commit) would pass the new configuration in an > edit-config as follows :- > > > > > > 120 > > > > > > rollback-on-error > > ... > > > > The result is a lot less real time gaps (see numbered steps below) > and thus a much tighter real-time model can be applied if one was > required (in the case of multiple sessions). At present Merge does > take care of unlocked edits but we all know that merge conflicts can > occur when attempting to merge data so these are currently left to > race-conditions which I for one can not allow into my current system. > > 1) session holder requests get-config with embedded lock request on > 2) rpc-reply containing the configuration and lock-timeout > 3) edit the configuration > 4) edit-config either merges, replaces or creates or deletes the > locked config (embed commit if candidate) > 5) ok is sent back confirming the edit (and commit if candidate) > > > I hope this will provoke discussion which will lead to improvement of > the standard, the outcome hopefully impacting the current draft. > > I look forward to your comments, > Carl. > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > ------------------------------------------------------------------------ > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From andy@netconfcentral.com Sat Mar 7 21:17:24 2009 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 4565028C12E for ; Sat, 7 Mar 2009 21:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 3ItuuCx8Kj9z for ; Sat, 7 Mar 2009 21:17:23 -0800 (PST) Received: from n14.bullet.mail.mud.yahoo.com (n14.bullet.mail.mud.yahoo.com [68.142.206.41]) by core3.amsl.com (Postfix) with SMTP id 5C2CC28C12D for ; Sat, 7 Mar 2009 21:17:23 -0800 (PST) Received: from [209.191.108.97] by n14.bullet.mail.mud.yahoo.com with NNFMP; 08 Mar 2009 05:17:55 -0000 Received: from [68.142.201.242] by t4.bullet.mud.yahoo.com with NNFMP; 08 Mar 2009 05:17:55 -0000 Received: from [127.0.0.1] by omp403.mail.mud.yahoo.com with NNFMP; 08 Mar 2009 05:17:55 -0000 X-Yahoo-Newman-Id: 790087.67446.bm@omp403.mail.mud.yahoo.com Received: (qmail 63925 invoked from network); 8 Mar 2009 05:17:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.225.83 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 8 Mar 2009 05:17:54 -0000 X-YMail-OSG: qGcRrIIVM1m9B94JyFDojnR3mzreA6TLmEOk4GrZrNVCxt8Q9iROzYJciganw02KnJVBSpdrJumHutYRJ4bWwjJj.ra594168zT1fS_qFQoe83aciHiRt1.7QKhFN3YQpXWN3c4.LYS2RtkjY3eRc0HY X-Yahoo-Newman-Property: ymail-3 Message-ID: <49B35501.4090504@netconfcentral.com> Date: Sat, 07 Mar 2009 21:17:53 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Netconf] with-defaults capability URI 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, 08 Mar 2009 05:17:24 -0000 Hi, Sec. 2.3: urn:ietf:params:netconf:capability:with-defaults The identifier MUST have an additional parameter: "basic". This indicates how the agent reports default data in messages, in the case the manager does not specify the required behavior in the request. The allowed values of this parameter are report-all, trim, explicit as defined in Section 2.1.1. E.g.: urn:ietf:params:netconf:capability:with-defaults?basic=report-all This scheme does not work if the agent uses 'report-all'. It tells the manager what the agent will do if is missing. But, what if 'basic=report-all', and the manager sends 'with-defaults=false' in a request? What will the agent do wrt/ default filtering? Will the agent use 'trim' mode or 'explicit' mode? (Yes.) The manager needs to know which one. How about this scheme instead? And how about using a version number as well? urn:...:with-defaults:1.0?with=&without= e.g.: urn:...:with-defaults:1.0?with=trim&without=report-all with = behavior when request includes 'with-defaults=false' = [trim, explicit] without = behavior when request does not include 'with-default' element at all = [report-all, trim, explicit] In case it is not clear, when 'with-defaults=true' is present, the behavior is always 'report-all'. Andy From bertietf@bwijnen.net Mon Mar 9 03:43:41 2009 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 169343A6C1B; Mon, 9 Mar 2009 03:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.008 X-Spam-Level: X-Spam-Status: No, score=0.008 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHlh3lKONiVm; Mon, 9 Mar 2009 03:43:39 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 8A2CB3A6C05; Mon, 9 Mar 2009 03:43:37 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1Lgcxu-0006zy-IA; Mon, 09 Mar 2009 11:44:10 +0100 Message-ID: <6DA3019ECC07434BB9D95CE17C11123F@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Mon, 9 Mar 2009 11:43:40 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03B1_01C9A0AC.4A8355B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: NETMOD Working Group Subject: [Netconf] NETCONF/YANG Interoperability Test Summit 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, 09 Mar 2009 10:43:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_03B1_01C9A0AC.4A8355B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We do not want to use the mailing lists to promote any products. However, when I read in the IWL newsletter =20 http://www.iwl.com/spring-2009-newsletter.html that there are prelimenary plans for some interoperability testing: NETCONF & YANG Interoperability Test Summit InterWorking Labs is in the preliminary stages of planning a=20 NETCONF & YANG Interoperability Test Summit. It is tentatively scheduled for July 20-24, 2009.=20 We would like you to pencil in those dates if you can attend. More information will be available at the end of May 2009 I figured it would be good to make sure that all NETCONF and NETMOD participants are aware of this. I remember that the IWL interoperability = Test Summits for SNMP (all versions) helped us (implementers) a lot=20 in making sure we had good (and debugged) implementations that=20 worked well together.=20 Bert Wijnen ------=_NextPart_000_03B1_01C9A0AC.4A8355B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We do not want to use the mailing = lists to=20 promote any products.
 
However, when I read in the IWL=20 newsletter 
      = http://www.iwl.com/spring-2009-newsletter.html
that there are prelimenary plans = for some=20 interoperability testing:
 
    NETCONF & = YANG=20 Interoperability Test Summit
    InterWorking Labs = is in the=20 preliminary stages of planning a
    NETCONF & YANG=20 Interoperability Test Summit.
    It is tentatively = scheduled=20 for July 20-24, 2009. 
    We would like you = to pencil in=20 those dates if you can attend.
    More information = will be=20 available at the end of May 2009
 
I figured it would be good to make sure that all = NETCONF and=20 NETMOD
participants are aware of this. I remember that the = IWL=20 interoperability
Test Summits for SNMP (all versions) helped us=20 (implementers) a lot
in making sure we had good = (and debugged)=20 implementations that
worked well together. =
 
Bert Wijnen
------=_NextPart_000_03B1_01C9A0AC.4A8355B0-- From bertietf@bwijnen.net Mon Mar 9 05:44:50 2009 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 99FCB3A6984; Mon, 9 Mar 2009 05:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.286 X-Spam-Level: X-Spam-Status: No, score=-0.286 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypzVdbKluIh9; Mon, 9 Mar 2009 05:44:49 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id A41913A6956; Mon, 9 Mar 2009 05:44:48 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1Lger9-0005Jx-AL; Mon, 09 Mar 2009 13:45:19 +0100 Message-ID: From: "Bert Wijnen \(IETF\)" To: Date: Mon, 9 Mar 2009 13:44:38 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04E9_01C9A0BD.30DEA310" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 X-Mailman-Approved-At: Mon, 09 Mar 2009 05:46:35 -0700 Cc: Ron Bonica Subject: [Netconf] Request to publish draft-ietf-netconf-partial-lock-07 as Proposed Standard RFC 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, 09 Mar 2009 12:44:50 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_04E9_01C9A0BD.30DEA310 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dan, please take this document to the next step. The WG has consensus to request publication as a Proposed Standard RFC. Document Shepherd Write-Up for draft-ietf-netconf-partial-lock-07.=20 Template used was dated September 17, 2008. (1.a) Who is the Document Shepherd for this document? Has the=20 Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 version is ready for forwarding to the IESG for publication? Bert Wijnen is the document shepherd.=20 Yes, I have reviewed the document many times, including this version 7, that I believe is ready for forwarding to the AD/IESG. (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that=20 have been performed? The document has had wide review and re-reviews of NETCONF WG members and also from others. I do not have any concerns regarding the level of review for this document. (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML? I do not believe any extra special review (other than normal IETF Last Call) is needed. (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director=20 and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or = has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue. I do not have any specific concerns. No IPR disclosure been filed as far as we know. (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it? The document has WG consensus and the WG wants the document to be published as a Proposed Standard. (1.f) Has anyone threatened an appeal or otherwise indicated extreme = discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.) No-one has threatened with an appeal or expressed extreme discontent. (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See=20 http://www.ietf.org/ID-Checklist.html and=20 http://tools.ietf.org/tools/idnits/). Boilerplate checks are=20 not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews? Document passes ID-nits (as shown by the IETF idnits tool: http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/ draft-ietf-netconf-partial-lock-07.txt) (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967]. References are split in Normative and Informative. All normative documents have been published. (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation? IANA considerations are present and complete. No new namespaces are created and so no new Expert is needed. (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker? The XSD section has been checked by Mehmet Ersu (co-chair of the WG) and has been found to be valid. (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections: Technical Summary=20 The NETCONF protocol defines the lock and unlock RPCs, used to lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. Working Group Summary=20 The working group went over several versions of the=20 document. The comments and reviews helped improve the document a lot and brought us to consensus on the 7th revision of the docuemnt. Document Quality There are prelimenary implementations of this protocol =20 and updates to comply with this spec are in plan. Others are planning to implement this spec too. Bert Wijnen Document Shepherd ------=_NextPart_000_04E9_01C9A0BD.30DEA310 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dan, please take this document to the next step. The = WG has=20 consensus
to request publication as a Proposed Standard=20 RFC.
 
Document Shepherd Write-Up for=20 draft-ietf-netconf-partial-lock-07. 
Template used was dated September 17, = 2008.
 
    (1.a) Who is the Document = Shepherd for this=20 document? Has the =
         =20 Document Shepherd personally reviewed this version of the=20
          document and, = in=20 particular, does he or she believe this=20
          version is = ready for=20 forwarding to the IESG for publication?
 
  Bert Wijnen is the document shepherd. =
  Yes, I=20 have reviewed the document many times, including this version
  = 7, that=20 I believe is ready for forwarding to the AD/IESG.
 
    (1.b) Has the document had = adequate review=20 both from key WG members=20
          and from key = non-WG=20 members? Does the Document Shepherd have=20
          any concerns = about=20 the depth or breadth of the reviews that=20
          have been=20 performed?
 
  The document has had wide review and = re-reviews of=20 NETCONF WG members
  and also from others. I do not have any = concerns=20 regarding the level
  of review for this document.
 
    (1.c) Does the Document Shepherd = have=20 concerns that the document=20
          needs more = review=20 from a particular or broader perspective,=20
          e.g., = security,=20 operational complexity, someone familiar with=20
          AAA,=20 internationalization or XML?
 
  I do not believe any extra special review = (other than=20 normal IETF
  Last Call) is needed.
 
    (1.d) Does the Document Shepherd = have any=20 specific concerns or =
         =20 issues with this document that the Responsible Area Director=20
          and/or the = IESG=20 should be aware of? For example, perhaps he=20
          or she is=20 uncomfortable with certain parts of the document, or=20
          has concerns = whether=20 there really is a need for it. In any=20
          event, if the = WG has=20 discussed those issues and has indicated=20
          that it still = wishes=20 to advance the document, detail those=20
          concerns = here. Has an=20 IPR disclosure related to this document=20
          been filed? = If so,=20 please include a reference to the=20
          disclosure = and=20 summarize the WG discussion and conclusion on=20
          this=20 issue.
 
  I do not have any specific = concerns.
  No IPR=20 disclosure been filed as far as we know.
 
    (1.e) How solid is the WG = consensus behind=20 this document? Does it=20
          represent the = strong=20 concurrence of a few individuals, with=20
          others being = silent,=20 or does the WG as a whole understand and=20
          agree with=20 it?
 
  The document has WG consensus and the WG = wants the=20 document to be
  published as a Proposed Standard.
 
    (1.f) Has anyone threatened an = appeal or=20 otherwise indicated extreme=20
          discontent? = If so,=20 please summarise the areas of conflict in=20
          separate = email=20 messages to the Responsible Area Director. (It=20
          should be in = a=20 separate email because this questionnaire is=20
          entered into = the ID=20 Tracker.)
 
  No-one has threatened with an appeal or = expressed=20 extreme discontent.
 
    (1.g) Has the Document Shepherd = personally=20 verified that the =
         =20 document satisfies all ID nits? (See=20
          http://www.ietf.org/ID-Che= cklist.html=20 and
          http://tools.ietf.org/tools/= idnits/).=20 Boilerplate checks are=20
          not enough; = this=20 check needs to be thorough. Has the document=20
          met all = formal review=20 criteria it needs to, such as the MIB=20
          Doctor, media = type=20 and URI type reviews?
 
  Document passes ID-nits (as shown by the IETF = idnits=20 tool:
     htt= p://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/
 &n= bsp;       =20 draft-ietf-netconf-partial-lock-07.txt)
 

    (1.h) Has the document split its references = into=20 normative and
          = informative? Are there normative references to documents that=20
          are not ready = for=20 advancement or are otherwise in an unclear=20
          state? If = such=20 normative references exist, what is the=20
          strategy for = their=20 completion? Are there normative references=20
          that are = downward=20 references, as described in [RFC3967]? If=20
          so, list = these=20 downward references to support the Area=20
          Director in = the Last=20 Call procedure for them [RFC3967].
 
  References are split in Normative and Informative. All=20 normative
  documents have been published.
 
    (1.i) Has the Document Shepherd verified that = the=20 document IANA
          = consideration section exists and is consistent with the body=20
          of the = document? If=20 the document specifies protocol=20
          extensions, = are=20 reservations requested in appropriate IANA=20
          registries? = Are the=20 IANA registries clearly identified? If=20
          the document = creates=20 a new registry, does it define the=20
          proposed = initial=20 contents of the registry and an allocation=20
          procedure for = future=20 registrations? Does it suggest a=20
          reasonable = name for=20 the new registry? See [RFC5226]. If the=20
          document = describes an=20 Expert Review process has Shepherd=20
          conferred = with the=20 Responsible Area Director so that the IESG=20
          can appoint = the=20 needed Expert during the IESG Evaluation?
 
  IANA considerations are present and complete. No new = namespaces=20 are
  created and so no new Expert is needed.
 
    (1.j) Has the Document Shepherd verified that = sections=20 of the
          = document that=20 are written in a formal language, such as XML=20
          code, BNF = rules, MIB=20 definitions, etc., validate correctly in=20
          an automated=20 checker?
 
  The XSD section has been checked by Mehmet Ersu (co-chair of = the=20 WG)
  and has been found to be valid.
 
    (1.k) The IESG approval announcement includes a = Document=20
          Announcement=20 Write-Up. Please provide such a Document=20
          Announcement=20 Write-Up? Recent examples can be found in=20 the
          "Action"=20 announcements for approved documents. The approval=20
          announcement = contains=20 the following sections:
 
          Technical = Summary=20
 
           &n= bsp;=20 The NETCONF protocol defines the lock and unlock=20 RPCs,
          &nbs= p; =20 used to lock entire configuration datastores.  In=20 some
           = ; =20 situations, a way to lock only parts of a=20 configuration
         &n= bsp;  =20 datastore is required.  This document defines=20 a
           &n= bsp;=20 capability-based extension to the NETCONF protocol=20 for
           =  =20 locking portions of a configuration datastore.
 
          Working = Group=20 Summary
 
           &n= bsp;=20 The working group went over several versions of the=20
           &nb= sp;=20 document. The comments and reviews helped improve=20 the
           =  =20 document a lot and brought us to consensus on=20 the
           =  =20 7th revision of the docuemnt.
 
          Document=20 Quality
          &n= bsp; =20 There are prelimenary implementations of this protocol    =
           &nb= sp; and=20 updates to comply with this spec are in plan.=20 Others
          &nb= sp; =20 are planning to implement this spec too.
 
Bert Wijnen
Document Shepherd
 
------=_NextPart_000_04E9_01C9A0BD.30DEA310-- From mehmet.ersue@nsn.com Mon Mar 9 08:42:26 2009 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 8F3FB3A6840 for ; Mon, 9 Mar 2009 08:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.504 X-Spam-Level: X-Spam-Status: No, score=-5.504 tagged_above=-999 required=5 tests=[AWL=1.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amL5YCIEWRyC for ; Mon, 9 Mar 2009 08:42:25 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 65C1C3A67AF for ; Mon, 9 Mar 2009 08:42:24 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n29FguoZ000795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Mar 2009 16:42:56 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n29Fgurw017615; Mon, 9 Mar 2009 16:42:56 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 16:42:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9A0CD.B6114EBC" Date: Mon, 9 Mar 2009 16:42:54 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Draft Agenda for IETF #74 NETCONF Session Thread-Index: AcmbQvoAww2K+4N3QkyOIAKlDQE82AADjyYgAV45pcA= References: From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 09 Mar 2009 15:42:55.0849 (UTC) FILETIME=[B729F590:01C9A0CD] Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 15:42:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A0CD.B6114EBC Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9A0CD.B6114EBC" ------_=_NextPart_002_01C9A0CD.B6114EBC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, =20 I uploaded the attached draft agenda to the meeting=20 material site.=20 http://www.ietf.org/proceedings/09mar/agenda/netconf.txt =20 PS: As usual we need to organize the scribes and minute=20 takers _before_ the meeting. Please help us to start the=20 session on time and send us a note if you volunteer.=20 PS2: The sequence and duration of the slots might change.=20 Cheers, Mehmet=20 =20 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On = Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) Sent: Monday, March 02, 2009 5:15 PM To: Netconf Subject: Re: [Netconf] Draft Agenda for IETF #74 NETCONF Session =09 =09 Dear All, =20 please find an update of the NETCONF session agenda. =20 PS: The duration of the slots is subject to change.=20 Presenters please confirm your slot.=20 =20 Mehmet=20 ________________________________________ =20 ** Draft - 020309 ** =20 NETCONF WG=20 IETF 74, San Francisco, CA, USA =20 TUESDAY, March 24, 2009, 1300-1500=20 =20 WG Chairs: Bert Wijnen Mehmet Ersue =20 Scribes (IF no_volunteers THEN wait_forever)=20 Agenda bashing (2 minutes)=20 WG status review (5 minutes)=20 =20 Chartered items: =20 1. Partial Lock RPC for NETCONF - Balazs Lengyel (5 minutes)=20 draft-ietf-netconf-partial-lock=20 2. NETCONF Monitoring Schema - Mark Scott (15 minutes) =20 draft-ietf-netconf-monitoring 3. With-defaults capability for NETCONF - A. Bierman/B. Lengyel = (20 minutes) draft-ietf-netconf-with-defaults 4. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20 minutes) draft-ietf-netconf-4741bis =20 Non-Chartered items: =20 1. Generic solution for the message integrity issue (10 minutes) 2. Robust Configuration Management within NETCONF - R. Cole/D. = Romascanu (15 minutes) =20 draft-cole-netconf-robust-config-00 =20 Open mike=20 Any other topics to discuss?=20 =20 AOB =09 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On = Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) Sent: Monday, March 02, 2009 3:27 PM To: Netconf Subject: [Netconf] Draft Agenda for IETF #74 NETCONF Session =09 =09 Dear NETCONF WG,=20 below is the draft agenda for the NETCONF WG session=20 at the IETF #74. Our session will be on Tuesday after=20 the lunch break at 1300-1500.=20 Our main focus in the session will be as usual on open issue=20 discussion but we have a few additional topics.=20 Please send us your comments and requests concerning=20 the agenda.=20 The duration of the slots is not final and subject to change.=20 Presenters please confirm your slot.=20 BTW: As usual we need to organize the scribes and minute=20 takers _before_ the meeting. Please help us to start the=20 session on time and send us a note if you volunteer.=20 Bert & Mehmet=20 ___________________________________________________=20 ** Draft - 020309 **=20 NETCONF WG=20 IETF 74, San Francisco, CA, USA=20 TUESDAY, March 24, 2009, 1300-1500=20 WG Chairs:=20 Bert Wijnen =20 Mehmet Ersue =20 Scribes (IF no_volunteers THEN wait_forever)=20 Agenda bashing (2 minutes)=20 WG status review (5 minutes)=20 Chartered items:=20 1. NETCONF Monitoring Schema - Mark Scott (15 minutes) =20 draft-ietf-netconf-monitoring=20 2. Partial Lock RPC for NETCONF - Balazs Lengyel (15 minutes)=20 draft-ietf-netconf-partial-lock=20 3. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20 minutes)=20 draft-ietf-netconf-4741bis=20 4. With-defaults capability for NETCONF - B. Lengyel (20 = minutes)=20 draft-bierman-netconf-with-defaults=20 Non-Chartered items:=20 1. Robust Configuration Management within NETCONF - R. Cole/D. = Romascanu (15 minutes) =20 draft-cole-netconf-robust-config-00=20 Open mike=20 Generic solution for the message identity issue (10 minutes)=20 Any other topics to discuss?=20 AOB=20 ------_=_NextPart_002_01C9A0CD.B6114EBC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Draft Agenda for IETF #74 NETCONF Session
Hi All,
 
I uploaded the attached draft agenda to the = meeting=20
material site.
http://= www.ietf.org/proceedings/09mar/agenda/netconf.txt
=
 
PS: As usual we need to organize the = scribes and=20 minute
takers _before_ the meeting. Please = help us to=20 start the
session on time and send us a note = if you=20 volunteer.
PS2: The sequence and duration of the = slots might=20 change.=20

Cheers,
Mehmet
 

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, = Mehmet (NSN -=20 DE/Munich)
Sent: Monday, March 02, 2009 5:15 = PM
To:=20 Netconf
Subject: Re: [Netconf] Draft Agenda for IETF #74 = NETCONF=20 Session

Dear All,
 
please find = an update of=20 the NETCONF session agenda.
 
PS: = The duration of the slots is subject to = change.=20
Presenters please confirm=20 your slot.
 
Mehmet =
________________________________________
 
**=20 Draft - 020309 **
 
NETCONF WG
IETF 74, San Francisco, CA, = USA
 
TUESDAY, March 24, 2009, 1300-1500
 
   WG Chairs:
   Bert Wijnen <bertietf@bwijnen.net>
&nbs= p; =20 Mehmet Ersue <mehmet.ersue@nsn.com><= /SPAN>
 
   Scribes (IF no_volunteers THEN wait_forever)=20
   Agenda bashing (2 minutes)
   WG status = review=20 (5 minutes)
 
   Chartered items:
 
      1. Partial Lock RPC for = NETCONF - Balazs=20 Lengyel (5 minutes) =
        =20 draft-ietf-netconf-partial-lock
      2. = NETCONF=20 Monitoring Schema - Mark Scott (15 minutes) =20
         =20 draft-ietf-netconf-monitoring
      3.=20 With-defaults capability for NETCONF - A. Bierman/B. Lengyel (20=20 minutes)
         =20 draft-ietf-netconf-with-defaults
      4.=20 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20=20 minutes)
         =20 draft-ietf-netconf-4741bis
 
   Non-Chartered items:
 
      1. Generic solution for the = message=20 integrity issue (10 minutes)
      2. = Robust=20 Configuration Management within NETCONF - R. Cole/D. Romascanu (15=20 minutes)  =
         =20 draft-cole-netconf-robust-config-00
 
   Open mike
      Any = other=20 topics to discuss?
 
   AOB

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, = Mehmet (NSN=20 - DE/Munich)
Sent: Monday, March 02, 2009 3:27 = PM
To:=20 Netconf
Subject: [Netconf] Draft Agenda for IETF #74 = NETCONF=20 Session


Dear NETCONF WG,

below is the draft agenda for the = NETCONF WG=20 session
at the IETF #74. = Our session=20 will be on Tuesday after
the lunch=20 break at 1300-1500.

Our main focus in the session will = be as usual=20 on open issue
discussion = but we have a=20 few additional topics.
Please send us=20 your comments and requests concerning
the agenda.

The duration of the slots is not = final and=20 subject to change.
Presenters please=20 confirm your slot.

BTW: As usual we need to organize = the scribes=20 and minute
takers _before_ = the meeting.=20 Please help us to start the
session on=20 time and send us a note if you volunteer.

Bert & Mehmet

___________________________________________________=20

** Draft - 020309=20 **

NETCONF WG=20
IETF = 74, San=20 Francisco, CA, USA

TUESDAY, March 24, = 2009,=20 1300-1500

   WG=20 Chairs:
   Bert Wijnen = <bertietf@bwijnen.net>=20
   = Mehmet Ersue=20 <mehmet.ersue@nsn.com>

   = Scribes (IF=20 no_volunteers THEN wait_forever)
   Agenda bashing (2 minutes)=20
   WG=20 status review (5 minutes)

   = Chartered=20 items:

      1.=20 NETCONF Monitoring Schema - Mark Scott (15 minutes) =20
         =20 draft-ietf-netconf-monitoring
      2. Partial = Lock RPC for=20 NETCONF - Balazs Lengyel (15 minutes)
        =20 draft-ietf-netconf-partial-lock
      3. = 4741bis-draft - M.=20 Bjorklund/J. Sch=F6nw=E4lder (20 minutes)
         =20 draft-ietf-netconf-4741bis
      4. = With-defaults=20 capability for NETCONF - B. Lengyel (20 minutes) =
         =20 draft-bierman-netconf-with-defaults

   = Non-Chartered=20 items:

      1.=20 Robust Configuration Management within NETCONF - R. Cole/D. = Romascanu (15=20 minutes) 
         =20 draft-cole-netconf-robust-config-00

   Open = mike=20
      Generic solution for the = message=20 identity issue (10 minutes)
      Any other = topics to=20 discuss?

   = AOB=20

------_=_NextPart_002_01C9A0CD.B6114EBC-- ------_=_NextPart_001_01C9A0CD.B6114EBC Content-Type: text/plain; name="090309_Draft_Agenda_NETCONF_IETF74.txt" Content-Transfer-Encoding: base64 Content-Description: 090309_Draft_Agenda_NETCONF_IETF74.txt Content-Disposition: attachment; filename="090309_Draft_Agenda_NETCONF_IETF74.txt" KiogRHJhZnQgLSAwOTAzMDkgKioNCg0KTkVUQ09ORiBXRyANCklFVEYgNzQsIFNhbiBGcmFuY2lz Y28sIENBLCBVU0ENCg0KVFVFU0RBWSwgTWFyY2ggMjQsIDIwMDksIDEzMDAtMTUwMCANCg0KICAg V0cgQ2hhaXJzOg0KICAgQmVydCBXaWpuZW4gPGJlcnRpZXRmQGJ3aWpuZW4ubmV0Pg0KICAgTWVo bWV0IEVyc3VlIDxtZWhtZXQuZXJzdWVAbnNuLmNvbT4NCg0KICAgU2NyaWJlcyAoSUYgbm9fdm9s dW50ZWVycyBUSEVOIHdhaXRfZm9yZXZlcikgDQogICBBZ2VuZGEgYmFzaGluZyAoMiBtaW51dGVz KSANCiAgIFdHIHN0YXR1cyByZXZpZXcgKDUgbWludXRlcykgDQoNCiAgIENoYXJ0ZXJlZCBpdGVt czoNCg0KICAgICAgMS4gUGFydGlhbCBMb2NrIFJQQyBmb3IgTkVUQ09ORiAtIEJhbGF6cyBMZW5n eWVsICg1IG1pbnV0ZXMpIA0KICAgICAgICAgZHJhZnQtaWV0Zi1uZXRjb25mLXBhcnRpYWwtbG9j ayANCiAgICAgIDIuIE5FVENPTkYgTW9uaXRvcmluZyBTY2hlbWEgLSBNYXJrIFNjb3R0ICgxNSBt aW51dGVzKSAgDQogICAgICAgICAgZHJhZnQtaWV0Zi1uZXRjb25mLW1vbml0b3JpbmcNCiAgICAg IDMuIFdpdGgtZGVmYXVsdHMgY2FwYWJpbGl0eSBmb3IgTkVUQ09ORiAtIEIuIExlbmd5ZWwgKDIw IG1pbnV0ZXMpDQogICAgICAgICAgZHJhZnQtaWV0Zi1uZXRjb25mLXdpdGgtZGVmYXVsdHMNCiAg ICAgIDQuIDQ3NDFiaXMtZHJhZnQgLSBNLiBCam9ya2x1bmQvSi4gU2No9m535GxkZXIgKDIwIG1p bnV0ZXMpDQogICAgICAgICAgZHJhZnQtaWV0Zi1uZXRjb25mLTQ3NDFiaXMNCg0KICAgTm9uLUNo YXJ0ZXJlZCBpdGVtczoNCg0KICAgICAgMS4gR2VuZXJpYyBzb2x1dGlvbiBmb3IgdGhlIG1lc3Nh Z2UgaW50ZWdyaXR5IGlzc3VlICgxMCBtaW51dGVzKQ0KICAgICAgMi4gUm9idXN0IENvbmZpZ3Vy YXRpb24gTWFuYWdlbWVudCB3aXRoaW4gTkVUQ09ORiAtIFIuIENvbGUvRC4gUm9tYXNjYW51ICgx NSBtaW51dGVzKSAgDQogICAgICAgICAgZHJhZnQtY29sZS1uZXRjb25mLXJvYnVzdC1jb25maWct MDANCg0KICAgT3BlbiBtaWtlICgxMCBtaW51dGVzKQ0KICAgICAgQW55IG90aGVyIHRvcGljcyB0 byBkaXNjdXNzPyANCg0KICAgQU9CDQo= ------_=_NextPart_001_01C9A0CD.B6114EBC-- From kwatsen@juniper.net Mon Mar 9 11:43:51 2009 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 27B3A3A69A8 for ; Mon, 9 Mar 2009 11:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyCptgJqoEUZ for ; Mon, 9 Mar 2009 11:43:50 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 5B00E3A6970 for ; Mon, 9 Mar 2009 11:43:50 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSbVjiHiPSqrkA7DcAz99KNrJlaAzUVZI@postini.com; Mon, 09 Mar 2009 11:44:25 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 9 Mar 2009 11:29:36 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 11:29:36 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 11:29:36 -0700 Received: from antitop.jnpr.net ([172.24.15.27]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 11:29:36 -0700 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, 9 Mar 2009 11:29:35 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue with draft-ietf-netconf-partial-lock-07.txt Thread-Index: Acmg5P/IuL2rzZfAQre6iVjYQZMq7g== From: Kent Watsen To: X-OriginalArrivalTime: 09 Mar 2009 18:29:36.0011 (UTC) FILETIME=[FFB995B0:01C9A0E4] Subject: [Netconf] issue with draft-ietf-netconf-partial-lock-07.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: Mon, 09 Mar 2009 18:43:51 -0000 All, I rarely have a chance to look at my NetConf list subscription email, but today's message from Bert to the IESG Secretary to publish the partial-lock ID caught my eye I just read the partial-lock-07 and have a concern with its design - notably pointed out by section 2.1.1.3 (Multiple managers handling the candidate datastore in a semi-coordinated work mode) where it says: Operators coordinate with each other. When all of them finish their tasks one of them orders commit. If any of the operators are still working, and holds a lock, the commit will fail, and will need to be repeated after all managers finish. To me, this makes the partial-lock on candidate datastores useless - as no mgt-app will use it over global-lock without a guarantee that its changes will get committed. For instance, our apps do this today: And, to use partial-lock, we'd want to do this: Did anyone discuss adding a to compliment this ID? Thanks, Kent -- Kent Watsen Software Architect Network Management Juniper Networks From bertietf@bwijnen.net Mon Mar 9 13:43:20 2009 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 AF66B3A67A4 for ; Mon, 9 Mar 2009 13:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.008 X-Spam-Level: X-Spam-Status: No, score=0.008 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRi1D5xjPkbG for ; Mon, 9 Mar 2009 13:43:19 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 8FB4B3A687B for ; Mon, 9 Mar 2009 13:43:19 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1LgmKF-0005Tu-Pa; Mon, 09 Mar 2009 21:43:51 +0100 Message-ID: <062D8087CB8847AE932FDC3B02840804@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Kent Watsen" , References: In-Reply-To: Date: Mon, 9 Mar 2009 21:43:22 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_074D_01C9A100.11F412D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: Re: [Netconf] issue with draft-ietf-netconf-partial-lock-07.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: Mon, 09 Mar 2009 20:43:20 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_074D_01C9A100.11F412D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ken, I don;t recall that this was ever discussed or brought up. Bringing up this type of thing seems a bit late in the process. But nevertheless, I am open to hear other WG participants opinion. Meanwhile, I think it is best to let the process continue, which means = that - AD will do review - Document goes to IETF Last Call - document goes to IESG (if IETF LC does not reveal any fatal flaws). If we see support of your concerns in the WG, we may consider your = comments as one of the IETF Last Call comments and deal with it that way. Bert ----- Original Message -----=20 From: Kent Watsen=20 To: netconf@ietf.org=20 Sent: Monday, March 09, 2009 7:29 PM Subject: [Netconf] issue with draft-ietf-netconf-partial-lock-07.txt All, I rarely have a chance to look at my NetConf list subscription email, but today's message from Bert to the IESG Secretary to publish the partial-lock ID caught my eye I just read the partial-lock-07 and have a concern with its design - notably pointed out by section 2.1.1.3 (Multiple managers handling the candidate datastore in a semi-coordinated work mode) where it says: Operators coordinate with each other. When all of them finish = their tasks one of them orders commit. If any of the operators are still working, and holds a lock, the commit will fail, and will need to = be repeated after all managers finish. To me, this makes the partial-lock on candidate datastores useless - = as no mgt-app will use it over global-lock without a guarantee that its changes will get committed. For instance, our apps do this today: And, to use partial-lock, we'd want to do this: Did anyone discuss adding a to compliment this ID? Thanks, Kent -- Kent Watsen Software Architect Network Management Juniper Networks _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_074D_01C9A100.11F412D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ken, I don;t recall that this was ever discussed or = brought=20 up.
 
Bringing up this type of thing seems a bit late in = the=20 process.
 
But nevertheless, I am open to hear other WG = participants=20 opinion.
 
Meanwhile, I think it is best to let the process = continue,=20 which means that
- AD will do review
- Document goes to IETF Last Call
- document goes to IESG (if IETF LC does not reveal = any fatal=20 flaws).
 
If we see support of your concerns in the WG, we may = consider=20 your comments
as one of the IETF Last Call comments and deal with = it that=20 way.
 
Bert
----- Original Message -----
From:=20 Kent Watsen=20
Sent: Monday, March 09, 2009 = 7:29=20 PM
Subject: [Netconf] issue with=20 draft-ietf-netconf-partial-lock-07.txt


All,

I rarely have a chance to look at my = NetConf=20 list subscription email,
but today's message from Bert to the IESG=20 Secretary to publish the
partial-lock ID caught my eye

I = just read=20 the partial-lock-07 and have a concern with its design -
notably = pointed=20 out by section 2.1.1.3 (Multiple managers handling the
candidate = datastore=20 in a semi-coordinated work mode) where it says:

   = Operators=20 coordinate with each other.  When all of them finish=20 their
   tasks one of them orders commit.  If any of = the=20 operators are still
   working, and holds a lock, the = commit will=20 fail, and will need to be
   repeated after all managers=20 finish.

To me, this makes the partial-lock on candidate = datastores=20 useless - as
no mgt-app will use it over global-lock without a = guarantee=20 that its
changes will get committed.  For instance, our apps = do this=20 = today:

<lock>
<edit-config>
<commit>
&l= t;unlock>

And,=20 to use partial-lock, we'd want to do=20 = this:

<partial-lock>
<edit-config>
<partial-c= ommit> =20 <!-- only commits nodes protected by=20 lock-id
-->
<partial-unlock>

Did anyone discuss = adding a=20 <partial-commit> to compliment this=20 ID?


Thanks,
Kent


--
Kent = Watsen
Software=20 Architect
Network Management
Juniper=20 = Networks

_______________________________________________
Netcon= f=20 mailing list
Netconf@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netconf
------=_NextPart_000_074D_01C9A100.11F412D0-- From root@core3.amsl.com Mon Mar 9 16:45:01 2009 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9601128C286; Mon, 9 Mar 2009 16:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309234501.9601128C286@core3.amsl.com> Date: Mon, 9 Mar 2009 16:45:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 23: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 : NETCONF Monitoring Schema Author(s) : M. Scott, et al. Filename : draft-ietf-netconf-monitoring-04.txt Pages : 46 Date : 2009-03-09 This document defines a NETCONF data model (in XML Schema) to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF datastores, sessions, locks, subscriptions, and statistics. This data facilitates the management of a NETCONF server. This document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new NETCONF operation to retrieve them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-monitoring-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09164237.I-D@ietf.org> --NextPart-- From balazs.lengyel@ericsson.com Wed Mar 11 04:05:13 2009 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 CF6C83A6A2F for ; Wed, 11 Mar 2009 04:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6 X-Spam-Level: X-Spam-Status: No, score=-6 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GchiuOJuAAt for ; Wed, 11 Mar 2009 04:05:13 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A9A993A68A4 for ; Wed, 11 Mar 2009 04:05:12 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5C945220F7; Wed, 11 Mar 2009 12:05:47 +0100 (CET) X-AuditID: c1b4fb3e-b00a2bb0000023da-ce-49b79b0b213b Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 42B462205C; Wed, 11 Mar 2009 12:05:47 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 12:05:46 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 12:05:46 +0100 Message-ID: <49B79B0A.3040505@ericsson.com> Date: Wed, 11 Mar 2009 12:05:46 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Kent Watsen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Mar 2009 11:05:46.0591 (UTC) FILETIME=[542E0EF0:01C9A239] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] issue with draft-ietf-netconf-partial-lock-07.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: Wed, 11 Mar 2009 11:05:13 -0000 Hello Bert, Kent, Yes your concern was voiced in discussions e.g. by Phil Shafer and some others. As I see the basic problem is that one node needs to be handled by multiple operators. This means that each operator should only touch part of the configuration. For the running configuration this is easy as we have partial lock and (partial) edit-config. For the candidate this is more difficult as commit is global. However the working group decided that we do not want to provide partial versions of other operations (commit, copy-config, delete-config, validate?). The workgroup decided that partial locking as an optional feature is useful without other (new/updated) partial operations, so the WG does not want other partial operations as that would be a too big impact. I agree, partial-locking will be most useful for operators using the writable-running capability, but it can be used even for the candidate datastore. Balazs Kent Watsen wrote: > All, > > I rarely have a chance to look at my NetConf list subscription email, > but today's message from Bert to the IESG Secretary to publish the > partial-lock ID caught my eye > > I just read the partial-lock-07 and have a concern with its design - > notably pointed out by section 2.1.1.3 (Multiple managers handling the > candidate datastore in a semi-coordinated work mode) where it says: > > Operators coordinate with each other. When all of them finish their > tasks one of them orders commit. If any of the operators are still > working, and holds a lock, the commit will fail, and will need to be > repeated after all managers finish. > > To me, this makes the partial-lock on candidate datastores useless - as > no mgt-app will use it over global-lock without a guarantee that its > changes will get committed. For instance, our apps do this today: > > > > > > > And, to use partial-lock, we'd want to do this: > > > > > > > Did anyone discuss adding a to compliment this ID? > > > Thanks, > Kent > > > -- > Kent Watsen > Software Architect > Network Management > Juniper Networks > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From bertietf@bwijnen.net Wed Mar 11 09:15:24 2009 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 5C37F28C18A for ; Wed, 11 Mar 2009 09:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxUgiR-aKbVo for ; Wed, 11 Mar 2009 09:15:19 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 3A8523A6980 for ; Wed, 11 Mar 2009 09:15:19 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1LhR5z-0002xA-5C; Wed, 11 Mar 2009 17:15:51 +0100 Message-ID: <4162AF81834B411DA2CE36360EDECEB5@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" References: <08332EA1C1F240958EC552C561A9A4F1@BertLaptop> In-Reply-To: <08332EA1C1F240958EC552C561A9A4F1@BertLaptop> Date: Wed, 11 Mar 2009 17:15:06 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0553_01C9A26C.EC5A0520" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: Margaret Wasserman Subject: Re: [Netconf] WG Last Call: Pls review proposed text change regarding:[Technical Errata Reported] RFC4742 (1628) 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, 11 Mar 2009 16:15:24 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0553_01C9A26C.EC5A0520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Wg participants, I have not seen/heard any oobjections to the below. I will now request = RFC-Editor=20 to mark the reported errata/erratum as a formal errata/erratum (I = believe the correct latin is erratum if it is a single one) and use the text as = provided by Margaret. I will ask Dan to confirm that to RFC-Editor and I will then also ask = Dan to instruct IANA to make the according change to the registry. Bert and Mehmet ----- Original Message -----=20 From: Bert Wijnen (IETF)=20 To: Netconf=20 Cc: Margaret Wasserman=20 Sent: Thursday, February 26, 2009 5:28 PM Subject: [Netconf] WG Last Call: Pls review proposed text change = regarding:[Technical Errata Reported] RFC4742 (1628) WG participants, Please review the below proposed text replacement to address a = reported Errata. Deadline is March 11th, so that (if needed... probabl;y not, but just = in case) we=20 can try to get it on IESG agenda on 12th.=20 Propably it is just OK if Dan approves it onces we as a WG have = consensus. Bert and Mehmet ----- Original Message -----=20 From: Margaret Wasserman=20 To: Bert Wijnen (IETF)=20 Cc: Ted Goddard ; mehmet.ersue@nsn.com=20 Sent: Wednesday, February 25, 2009 6:16 PM Subject: Re: [Technical Errata Reported] RFC4742 (1628) Hi Bert, This errata is correct, and netconf should be listed as an SSN =20 subsystem name, not an SSH service name. However, we need to change =20 more than the RFC text, as the IANA registry is also incorrect. The text change in the correct format would look like this... On page 7 (in Section 7. IANA Considerations) please replace: IANA is also requested to assign "netconf" as an SSH Service Name as defined in [RFC4250], as follows: Service Name Reference ------------- --------- netconf RFC 4742 With: Corrected Text -------------- IANA is also requested to assign "netconf" as an SSH Connection Protocol Subsystem Name as defined in [RFC4250], as follows: Subsystem Name Reference ------------- --------- netconf RFC 4742 However, I don' t think we should make this change unless/until we can = =20 make a corresponding change with IANA. What is the procedure for = that? Thanks, Margaret > On Feb 25, 2009, at 10:41 AM, Bert Wijnen (IETF) wrote: > Could the authors/editors PLEASE report/respond/vent their opinion? > > Thanks, > Bert and Mehmet > > ----- Original Message ----- > From: Pasi.Eronen@nokia.com > To: ted.goddard@icesoft.com ; mrw@lilacglade.org > Cc: mehmet.ersue@nsn.com ; bertietf@bwijnen.net > Sent: Monday, February 23, 2009 2:23 PM > Subject: RE: [Technical Errata Reported] RFC4742 (1628) > > Ted, Margaret, Bert, and Mehmet, > > Has there been any progress on this? (I'm not on the NETCONF mailing = =20 > list, but quick look at the archive didn't find anything) > > Best regards, > Pasi > > From: ext Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net] > Sent: 09 December, 2008 11:18 > To: Netconf; Ted Goddard; Margaret Wasserman > Cc: Eronen Pasi (Nokia-NRC/Helsinki) > Subject: Fw: [Technical Errata Reported] RFC4742 (1628) > > NETCONF WG members, > > We have received the following reported Technical errata. > We have had a few interactions between the authors, WG chairs, AD =20 > and Pasi. > It seems that the Errata report is indeed correct. > It also seems a bit heavy to issue a new RFC just for this. > So we (WG chairs) are suggesting that Ted and Margaret compose a fix = =20 > (can be > based mainly on the text that Pasi already provided) in the form of: > > on page xxxx replace > > old text > > with > > new text > > And that we all get a chance on the mailing list to review and =20 > comment. > Once we're OK with the text, we can pass it to the RFC-Editor. > And also put it in our queue for the time that rfc4742 needs = revision. > Maybve... while we do rfc4741 revision we find other things that =20 > could also > have an impact on 4742, and we can then decide if that is serious =20 > enough to > also reissue rfc4742. > > So Ted and Marageret, pls send proposed text. > > Bert and Mehmet > > > ----- Original Message ----- > From: RFC Errata System > To: margaret@thingmagic.com ; ted.goddard@icesoft.com ; = dromasca@avaya.com=20 > ; rbonica@juniper.net ;bertietf@bwijnen.net ; mehmet.ersue@nsn.com > Cc: pasi.eronen@nokia.com ; rfc-editor@rfc-editor.org > Sent: Thursday, December 04, 2008 7:20 PM > Subject: [Technical Errata Reported] RFC4742 (1628) > > > The following errata report has been submitted for RFC4742, > "Using the NETCONF Configuration Protocol over Secure SHell (SSH)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4742&eid=3D1628 > > -------------------------------------- > Type: Technical > Reported by: Pasi Eronen > > Section: 7 > > Original Text > ------------- > IANA is also requested to assign "netconf" as an SSH Service Name as > defined in [RFC4250], as follows: > > Service Name Reference > ------------- --------- > netconf RFC 4742 > > > Corrected Text > -------------- > IANA is also requested to assign "netconf" as an SSH Connection > Protocol Subsystem Name as defined in [RFC4250], as follows: > > Subsystem Name Reference > ------------- --------- > netconf RFC 4742 > > > Notes > ----- > The IANA registry (http://www.iana.org/assignments/ssh-parameters) > also needs to be fixed. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4742 (draft-ietf-netconf-ssh-06) > -------------------------------------- > Title : Using the NETCONF Configuration Protocol over = > Secure SHell (SSH) > Publication Date : December 2006 > Author(s) : M. Wasserman, T. Goddard > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG -------------------------------------------------------------------------= ----- _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_0553_01C9A26C.EC5A0520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Wg participants,
 
I have not seen/heard any oobjections to the below. = I will now=20 request RFC-Editor
to mark the reported errata/erratum as a formal = errata/erratum=20 (I believe the
correct latin is erratum if it is a single one) and = use the=20 text as provided by Margaret.
I will ask Dan to confirm that to RFC-Editor and I = will then=20 also ask Dan to instruct
IANA to make the according change to the=20 registry.
 
Bert and Mehmet
----- Original Message -----
From:=20 Bert Wijnen=20 (IETF)
To: Netconf
Sent: Thursday, February 26, = 2009 5:28=20 PM
Subject: [Netconf] WG Last = Call: Pls=20 review proposed text change regarding:[Technical Errata Reported] = RFC4742=20 (1628)

WG participants,
 
Please review the below proposed text replacement = to address=20 a reported Errata.
Deadline is March 11th, so that (if needed... = probabl;y not,=20 but just in case) we
can try to get it on IESG agenda on=20 12th.
Propably it is just OK if Dan approves it onces we = as a WG=20 have consensus.
 
Bert and Mehmet
----- Original Message -----=20
From: Margaret = Wasserman
Cc: Ted Goddard ; mehmet.ersue@nsn.com
Sent: Wednesday, February 25, 2009 6:16 PM
Subject: Re: [Technical Errata Reported] RFC4742=20 (1628)


Hi Bert,

This errata is correct, and netconf = should=20 be listed as an SSN 
subsystem name, not an SSH service = name. =20 However, we need to change 
more than the RFC text, as the = IANA=20 registry is also incorrect.

The text change in the correct = format would=20 look like this...

On page 7 (in Section 7. IANA Considerations) = please=20 replace:

IANA is also requested to assign "netconf" as an SSH = Service=20 Name as
defined in [RFC4250], as=20 follows:

          = Service=20 = Name           &nb= sp;     =20 Reference
         =20 = -------------          =       =20 ---------
         =20 = netconf           =            =20 RFC 4742

With:

Corrected Text
--------------
IANA = is also=20 requested to assign "netconf" as an SSH Connection
Protocol = Subsystem Name=20 as defined in [RFC4250], as=20 follows:

          = Subsystem=20 = Name           &nb= sp;=20 Reference
         =20 = -------------          =       =20 ---------
         =20 = netconf           =            =20 RFC 4742

However, I don' t think we should make this change=20 unless/until we can 
make a corresponding change with = IANA. =20 What is the procedure for=20 that?

Thanks,
Margaret





> On Feb = 25, 2009,=20 at 10:41 AM, Bert Wijnen (IETF) wrote:

> Could the = authors/editors=20 PLEASE report/respond/vent their opinion?
>
> = Thanks,
> Bert=20 and Mehmet
>
> ----- Original Message -----
> From: = Pasi.Eronen@nokia.com
> = To: ted.goddard@icesoft.com ; = mrw@lilacglade.org
> Cc: = mehmet.ersue@nsn.com ; bertietf@bwijnen.net
> = Sent:=20 Monday, February 23, 2009 2:23 PM
> Subject: RE: [Technical = Errata=20 Reported] RFC4742 (1628)
>
> Ted, Margaret, Bert, and=20 Mehmet,
>
> Has there been any progress on this? (I'm not = on the=20 NETCONF mailing 
> list, but quick look at the archive = didn't find=20 anything)
>
> Best regards,
> Pasi
>
> = From: ext=20 Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net]
> Sent: 09 = December,=20 2008 11:18
> To: Netconf; Ted Goddard; Margaret = Wasserman
> Cc:=20 Eronen Pasi (Nokia-NRC/Helsinki)
> Subject: Fw: [Technical = Errata=20 Reported] RFC4742 (1628)
>
> NETCONF WG = members,
>
>=20 We have received the following reported Technical errata.
> We = have had=20 a few interactions between the authors, WG chairs, AD 
> = and=20 Pasi.
> It seems that the Errata report is indeed = correct.
> It=20 also seems a bit heavy to issue a new RFC just for this.
> So we = (WG=20 chairs) are suggesting that Ted and Margaret compose a fix  =
> (can=20 be
> based mainly on the text that Pasi already provided) in the = form=20 of:
>
> on page xxxx=20 replace
>
>     old = text
>
>=20 with
>
>    new text
>
> And = that we=20 all get a chance on the mailing list to review and 
>=20 comment.
> Once we're OK with the text, we can pass it to the=20 RFC-Editor.
> And also put it in our queue for the time that = rfc4742=20 needs revision.
> Maybve... while we do rfc4741 revision we find = other=20 things that 
> could also
> have an impact on 4742, = and we=20 can then decide if that is serious 
> enough to
> = also=20 reissue rfc4742.
>
> So Ted and Marageret, pls send = proposed=20 text.
>
> Bert and Mehmet
>
>
> ----- = Original=20 Message -----
> From: RFC Errata System
> To: margaret@thingmagic.com ; = ted.goddard@icesoft.com ; = dromasca@avaya.com =
>  ; rbonica@juniper.net=20 ;bertietf@bwijnen.net ; mehmet.ersue@nsn.com
> = Cc: pasi.eronen@nokia.com ; rfc-editor@rfc-editor.org>=20 Sent: Thursday, December 04, 2008 7:20 PM
> Subject: [Technical = Errata=20 Reported] RFC4742 (1628)
>
>
> The following errata = report=20 has been submitted for RFC4742,
> "Using the NETCONF = Configuration=20 Protocol over Secure SHell (SSH)".
>
>=20 --------------------------------------
> You may review the = report below=20 and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D4742&eid=3D16= 28
>
>=20 --------------------------------------
> Type: Technical
> = Reported by: Pasi Eronen <pasi.eronen@nokia.com>
&g= t;
>=20 Section: 7
>
> Original Text
> -------------
> = IANA is=20 also requested to assign "netconf" as an SSH Service Name as
> = defined=20 in [RFC4250], as=20 = follows:
>
>        &= nbsp;=20 Service=20 = Name           &nb= sp;     =20 = Reference
>         =20 = -------------          =       =20 = ---------
>         =20 = netconf           =            =20 RFC 4742
>
>
> Corrected Text
> = --------------
>=20 IANA is also requested to assign "netconf" as an SSH = Connection
>=20 Protocol Subsystem Name as defined in [RFC4250], as=20 = follows:
>
>        &= nbsp;=20 Subsystem=20 = Name           &nb= sp;   =20 = Reference
>         =20 = -------------          =       =20 = ---------
>         =20 = netconf           =            =20 RFC 4742
>
>
> Notes
> -----
> The IANA = registry=20 (http://www.iana.o= rg/assignments/ssh-parameters)
>=20 also needs to be fixed.
>
> Instructions:
>=20 -------------
> This errata is currently posted as "Reported". = If=20 necessary, please
> use "Reply All" to discuss whether it should = be=20 verified or
> rejected. When a decision is reached, the = verifying party=20 (IESG)
> can log in to change the status and edit the report, if = necessary.
>
> = --------------------------------------
>=20 RFC4742 (draft-ietf-netconf-ssh-06)
>=20 --------------------------------------
>=20 = Title           &n= bsp;  =20 : Using the NETCONF Configuration Protocol over 
> Secure = SHell=20 (SSH)
> Publication Date    : December = 2006
>=20 Author(s)           = : M.=20 Wasserman, T. Goddard
>=20 = Category           = ; :=20 PROPOSED STANDARD
>=20 = Source           &= nbsp; =20 : Network Configuration
>=20 = Area           &nb= sp;   =20 : Operations and Management
>=20 = Stream           &= nbsp; =20 : IETF
> Verifying Party     : IESG

_______________________________________________
Netconf = mailing=20 = list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf=
------=_NextPart_000_0553_01C9A26C.EC5A0520-- From bertietf@bwijnen.net Wed Mar 11 09:21:52 2009 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 01BD03A6955 for ; Wed, 11 Mar 2009 09:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.281 X-Spam-Level: X-Spam-Status: No, score=-0.281 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKgBqTNarQZ1 for ; Wed, 11 Mar 2009 09:21:50 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 0E24028C158 for ; Wed, 11 Mar 2009 09:21:49 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1LhRCL-0004a3-Ck for netconf@ietf.org; Wed, 11 Mar 2009 17:22:25 +0100 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Wed, 11 Mar 2009 17:21:46 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0580_01C9A26D.DAC15C90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: [Netconf] Fw: [Technical Errata Reported] RFC4742 (1628) 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, 11 Mar 2009 16:21:52 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0580_01C9A26D.DAC15C90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI ----- Original Message -----=20 From: Bert Wijnen (IETF)=20 To: RFC Editor ; IANA@iana.org=20 Cc: Romascanu, Dan (Dan) ; Ron Bonica ; Ersue, Mehmet (NSN - DE/Munich)=20 Sent: Wednesday, March 11, 2009 5:20 PM Subject: Re: [Technical Errata Reported] RFC4742 (1628) RFC-editor,=20 The authors/editors and the NETCONF WG have discussed and checked the = reported erratum (errata?). We agree that there was/is an error in RFC4742. Can you make/mark the erratum/errata as valid and provide the text as = give by Margareth in the below email.=20 Once the erratum is properly marked, IANA should make a change = accordingly in their registry.=20 Dan, pls approve both actions. Bert and Mehmet co-chairs for NETCONF WG ----- Original Message -----=20 From: Margaret Wasserman=20 To: Bert Wijnen (IETF)=20 Cc: Ted Goddard ; mehmet.ersue@nsn.com=20 Sent: Wednesday, February 25, 2009 6:16 PM Subject: Re: [Technical Errata Reported] RFC4742 (1628) Hi Bert, This errata is correct, and netconf should be listed as an SSN =20 subsystem name, not an SSH service name. However, we need to change =20 more than the RFC text, as the IANA registry is also incorrect. The text change in the correct format would look like this... On page 7 (in Section 7. IANA Considerations) please replace: IANA is also requested to assign "netconf" as an SSH Service Name as defined in [RFC4250], as follows: Service Name Reference ------------- --------- netconf RFC 4742 With: Corrected Text -------------- IANA is also requested to assign "netconf" as an SSH Connection Protocol Subsystem Name as defined in [RFC4250], as follows: Subsystem Name Reference ------------- --------- netconf RFC 4742 However, I don' t think we should make this change unless/until we can =20 make a corresponding change with IANA. What is the procedure for that? Thanks, Margaret > On Feb 25, 2009, at 10:41 AM, Bert Wijnen (IETF) wrote: > Could the authors/editors PLEASE report/respond/vent their opinion? > > Thanks, > Bert and Mehmet > > ----- Original Message ----- > From: Pasi.Eronen@nokia.com > To: ted.goddard@icesoft.com ; mrw@lilacglade.org > Cc: mehmet.ersue@nsn.com ; bertietf@bwijnen.net > Sent: Monday, February 23, 2009 2:23 PM > Subject: RE: [Technical Errata Reported] RFC4742 (1628) > > Ted, Margaret, Bert, and Mehmet, > > Has there been any progress on this? (I'm not on the NETCONF mailing =20 > list, but quick look at the archive didn't find anything) > > Best regards, > Pasi > > From: ext Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net] > Sent: 09 December, 2008 11:18 > To: Netconf; Ted Goddard; Margaret Wasserman > Cc: Eronen Pasi (Nokia-NRC/Helsinki) > Subject: Fw: [Technical Errata Reported] RFC4742 (1628) > > NETCONF WG members, > > We have received the following reported Technical errata. > We have had a few interactions between the authors, WG chairs, AD =20 > and Pasi. > It seems that the Errata report is indeed correct. > It also seems a bit heavy to issue a new RFC just for this. > So we (WG chairs) are suggesting that Ted and Margaret compose a fix =20 > (can be > based mainly on the text that Pasi already provided) in the form of: > > on page xxxx replace > > old text > > with > > new text > > And that we all get a chance on the mailing list to review and =20 > comment. > Once we're OK with the text, we can pass it to the RFC-Editor. > And also put it in our queue for the time that rfc4742 needs revision. > Maybve... while we do rfc4741 revision we find other things that =20 > could also > have an impact on 4742, and we can then decide if that is serious =20 > enough to > also reissue rfc4742. > > So Ted and Marageret, pls send proposed text. > > Bert and Mehmet > > > ----- Original Message ----- > From: RFC Errata System > To: margaret@thingmagic.com ; ted.goddard@icesoft.com ; = dromasca@avaya.com=20 > ; rbonica@juniper.net ;bertietf@bwijnen.net ; mehmet.ersue@nsn.com > Cc: pasi.eronen@nokia.com ; rfc-editor@rfc-editor.org > Sent: Thursday, December 04, 2008 7:20 PM > Subject: [Technical Errata Reported] RFC4742 (1628) > > > The following errata report has been submitted for RFC4742, > "Using the NETCONF Configuration Protocol over Secure SHell (SSH)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4742&eid=3D1628 > > -------------------------------------- > Type: Technical > Reported by: Pasi Eronen > > Section: 7 > > Original Text > ------------- > IANA is also requested to assign "netconf" as an SSH Service Name as > defined in [RFC4250], as follows: > > Service Name Reference > ------------- --------- > netconf RFC 4742 > > > Corrected Text > -------------- > IANA is also requested to assign "netconf" as an SSH Connection > Protocol Subsystem Name as defined in [RFC4250], as follows: > > Subsystem Name Reference > ------------- --------- > netconf RFC 4742 > > > Notes > ----- > The IANA registry (http://www.iana.org/assignments/ssh-parameters) > also needs to be fixed. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4742 (draft-ietf-netconf-ssh-06) > -------------------------------------- > Title : Using the NETCONF Configuration Protocol over =20 > Secure SHell (SSH) > Publication Date : December 2006 > Author(s) : M. Wasserman, T. Goddard > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG ------=_NextPart_000_0580_01C9A26D.DAC15C90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
FYI
 
----- Original Message -----=20
From: Bert = Wijnen=20 (IETF)
Cc: Romascanu, Dan (Dan) ; Ron = Bonica ; Ersue, = Mehmet (NSN=20 - DE/Munich)
Sent: Wednesday, March 11, 2009 5:20 PM
Subject: Re: [Technical Errata Reported] RFC4742 = (1628)

RFC-editor,
 
The authors/editors and the NETCONF = WG have=20 discussed and checked the reported
erratum (errata?). We agree that there was/is an = error in=20 RFC4742.
 
Can you make/mark the erratum/errata as valid and = provide the=20 text as give by Margareth
in the below email.
 
Once the erratum is properly marked, IANA should = make a change=20 accordingly in
their registry.
 
Dan, pls approve both actions.
 
Bert and Mehmet
co-chairs for NETCONF WG
 
----- Original Message -----=20
From: Margaret = Wasserman=20
Cc: Ted Goddard ; mehmet.ersue@nsn.com
Sent: Wednesday, February 25, 2009 6:16 PM
Subject: Re: [Technical Errata Reported] RFC4742 = (1628)


Hi Bert,

This errata is correct, and netconf = should be=20 listed as an SSN 
subsystem name, not an SSH service = name. =20 However, we need to change 
more than the RFC text, as the IANA = registry is also incorrect.

The text change in the correct format = would=20 look like this...

On page 7 (in Section 7. IANA Considerations) = please=20 replace:

IANA is also requested to assign "netconf" as an SSH = Service=20 Name as
defined in [RFC4250], as=20 follows:

          = Service=20 Name           &nb= sp;     =20 Reference
         =20 -------------          =       =20 ---------
         =20 netconf           =            =20 RFC 4742

With:

Corrected Text
--------------
IANA is = also=20 requested to assign "netconf" as an SSH Connection
Protocol Subsystem = Name as=20 defined in [RFC4250], as=20 follows:

          = Subsystem=20 Name           &nb= sp;=20 Reference
         =20 -------------          =       =20 ---------
         =20 netconf           =            =20 RFC 4742

However, I don' t think we should make this change = unless/until=20 we can 
make a corresponding change with IANA.  What is = the=20 procedure for = that?

Thanks,
Margaret





> On=20 Feb 25, 2009, at 10:41 AM, Bert Wijnen (IETF) wrote:

> Could = the=20 authors/editors PLEASE report/respond/vent their = opinion?
>
>=20 Thanks,
> Bert and Mehmet
>
> ----- Original Message=20 -----
> From: Pasi.Eronen@nokia.com
> = To: ted.goddard@icesoft.com ; mrw@lilacglade.org
> Cc: mehmet.ersue@nsn.com ; bertietf@bwijnen.net
> = Sent:=20 Monday, February 23, 2009 2:23 PM
> Subject: RE: [Technical Errata = Reported] RFC4742 (1628)
>
> Ted, Margaret, Bert, and=20 Mehmet,
>
> Has there been any progress on this? (I'm not on = the=20 NETCONF mailing 
> list, but quick look at the archive = didn't find=20 anything)
>
> Best regards,
> Pasi
>
> = From: ext=20 Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net]
> Sent: 09 = December, 2008=20 11:18
> To: Netconf; Ted Goddard; Margaret Wasserman
> Cc: = Eronen=20 Pasi (Nokia-NRC/Helsinki)
> Subject: Fw: [Technical Errata = Reported]=20 RFC4742 (1628)
>
> NETCONF WG members,
>
> We = have=20 received the following reported Technical errata.
> We have had a = few=20 interactions between the authors, WG chairs, AD 
> and = Pasi.
>=20 It seems that the Errata report is indeed correct.
> It also seems = a bit=20 heavy to issue a new RFC just for this.
> So we (WG chairs) are = suggesting=20 that Ted and Margaret compose a fix 
> (can be
> based = mainly=20 on the text that Pasi already provided) in the form of:
>
> = on page=20 xxxx replace
>
>     old = text
>
>=20 with
>
>    new text
>
> And that = we all=20 get a chance on the mailing list to review and 
> = comment.
>=20 Once we're OK with the text, we can pass it to the RFC-Editor.
> = And also=20 put it in our queue for the time that rfc4742 needs revision.
> = Maybve...=20 while we do rfc4741 revision we find other things that 
> = could=20 also
> have an impact on 4742, and we can then decide if that is=20 serious 
> enough to
> also reissue = rfc4742.
>
>=20 So Ted and Marageret, pls send proposed text.
>
> Bert and=20 Mehmet
>
>
> ----- Original Message -----
> = From: RFC=20 Errata System
> To: margaret@thingmagic.com ; ted.goddard@icesoft.com ; dromasca@avaya.com
>  = ; rbonica@juniper.net = ;bertietf@bwijnen.net=20 ; mehmet.ersue@nsn.com
> = Cc: pasi.eronen@nokia.com ; rfc-editor@rfc-editor.org>=20 Sent: Thursday, December 04, 2008 7:20 PM
> Subject: [Technical = Errata=20 Reported] RFC4742 (1628)
>
>
> The following errata = report has=20 been submitted for RFC4742,
> "Using the NETCONF Configuration = Protocol=20 over Secure SHell (SSH)".
>
>=20 --------------------------------------
> You may review the report = below=20 and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D4742&eid=3D16= 28
>
>=20 --------------------------------------
> Type: Technical
> = Reported=20 by: Pasi Eronen <pasi.eronen@nokia.com>
&g= t;
>=20 Section: 7
>
> Original Text
> -------------
> = IANA is=20 also requested to assign "netconf" as an SSH Service Name as
> = defined in=20 [RFC4250], as=20 follows:
>
>        &= nbsp;=20 Service=20 Name           &nb= sp;     =20 Reference
>         =20 -------------          =       =20 ---------
>         =20 netconf           =            =20 RFC 4742
>
>
> Corrected Text
> = --------------
>=20 IANA is also requested to assign "netconf" as an SSH Connection
> = Protocol=20 Subsystem Name as defined in [RFC4250], as=20 follows:
>
>        &= nbsp;=20 Subsystem=20 Name           &nb= sp;   =20 Reference
>         =20 -------------          =       =20 ---------
>         =20 netconf           =            =20 RFC 4742
>
>
> Notes
> -----
> The IANA = registry=20 (http://www.iana.o= rg/assignments/ssh-parameters)
>=20 also needs to be fixed.
>
> Instructions:
>=20 -------------
> This errata is currently posted as "Reported". If=20 necessary, please
> use "Reply All" to discuss whether it should = be=20 verified or
> rejected. When a decision is reached, the verifying = party=20 (IESG)
> can log in to change the status and edit the report, if=20 necessary.
>
> = --------------------------------------
>=20 RFC4742 (draft-ietf-netconf-ssh-06)
>=20 --------------------------------------
>=20 Title           &n= bsp;  =20 : Using the NETCONF Configuration Protocol over 
> Secure = SHell=20 (SSH)
> Publication Date    : December 2006
> = Author(s)           : = M.=20 Wasserman, T. Goddard
>=20 Category           = ; :=20 PROPOSED STANDARD
>=20 Source           &= nbsp; =20 : Network Configuration
>=20 Area           &nb= sp;   =20 : Operations and Management
>=20 Stream           &= nbsp; =20 : IETF
> Verifying Party     :=20 IESG

------=_NextPart_000_0580_01C9A26D.DAC15C90-- From mehmet.ersue@nsn.com Wed Mar 11 10:13:23 2009 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 274573A69A0 for ; Wed, 11 Mar 2009 10:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.565 X-Spam-Level: X-Spam-Status: No, score=-5.565 tagged_above=-999 required=5 tests=[AWL=1.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Aj6TJJ9GA1J for ; Wed, 11 Mar 2009 10:13:22 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 98F2C3A6881 for ; Wed, 11 Mar 2009 10:13:21 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n2BHDunY020361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Mar 2009 18:13:56 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n2BHDtEe014480; Wed, 11 Mar 2009 18:13:55 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Mar 2009 18:13:29 +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, 11 Mar 2009 18:13:28 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS: draft-ietf-netconf-tls Thread-Index: AcmiZ3bLaxXBeySUTzuzbSdcDKWBkwAA2Nag From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 11 Mar 2009 17:13:29.0177 (UTC) FILETIME=[B2818490:01C9A26C] Subject: [Netconf] FW: DISCUSS: draft-ietf-netconf-tls X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 17:13:23 -0000 =20 Hi All, FYI. This was the first DISCUSS for the TLS draft we solved.=20 Please state if you cannot live with the solution. Cheers,=20 Mehmet -----Original Message----- From: ext Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Wednesday, March 11, 2009 5:36 PM To: Ersue, Mehmet (NSN - DE/Munich) Cc: netconf-chairs@tools.ietf.org; badra@isima.fr; ext Badra; Romascanu, Dan (Dan) Subject: Re: DISCUSS: draft-ietf-netconf-tls This would clear my issue. Thanks for a fast response. Jari Ersue, Mehmet (NSN - DE/Munich) wrote: > > Hi Jari, > > thank you for uncovering this issue. > > It is correct that according to RFC 4741 the identity of each > end of a NETCONF session is expected to be available to the > other side and an authentication must be done also "on the server > side" to enjure that the incoming client request is legitimate. > > We suggest to change the text in chapter 3.2. as following: > > "3.2. Client Identity > > The server MUST verify and authenticate the identity of the > client according to local policy to ensure that the incoming > client request is legitimate before any configuration or state > data is sent to or received from the client." > > > Would this change be sufficient for you? > > Thank you for your support. > > Mehmet > =20 > > > -----Original Message----- > > From: ext Jari Arkko [_mailto:jari.arkko@piuha.net_] > > Sent: Wednesday, March 11, 2009 3:13 PM > > To: iesg@ietf.org > > Cc: netconf-chairs@tools.ietf.org; > > draft-ietf-netconf-tls@tools.ietf.org; badra@isima.fr > > Subject: DISCUSS: draft-ietf-netconf-tls > > > > Discuss: > > > > I expected to ballot Yes on this but at the end I found I was missing > > some fundamental information. My understanding of RFC 4741 is that > > authentication/authorization is something left to the protocol that > > carries NETCONF messages. RFC 4742 (NETCONF over SSH) for > > instance says: > > > > The identity of the server MUST be verified and > > authenticated by the > > client according to local policy ... > > > > The identity of the client MUST also be verified and > > authenticated by the server according to local policy ... > > > > However, the current document has explicit guidance about server side > > authentication, but not much about clients: > > > > The server may have no external knowledge on client's identity and > > identity checks might not be possible (unless the client has a > > certificate chain rooted in an appropriate CA). If a server has > > knowledge on client's identity (typically from some source external > > to NETCONF or TLS) it MUST check the identity as described above. > > > > This seems to be in violation of RFC 4741 thinking: > > > > It is further > > expected that the identity of each end of a NETCONF session will be > > available to the other in order to determine authorization for any > > given request. > > > > But I can't think that the authors would have missed client side > > authentication; its so fundamental to configuration operations > > to network devices. What am I missing? Is there some other > > authentication > > layer for client/user side somewhere? If there is not, I cannot see > > how you can allow one-side TLS authentication except maybe for reading > > information. > > > > > > > From andy@netconfcentral.com Wed Mar 11 11:01:07 2009 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 520A83A6BA6 for ; Wed, 11 Mar 2009 11:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.088, 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 7hyQ9JwPRpri for ; Wed, 11 Mar 2009 11:01:06 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 95E6B3A6BA1 for ; Wed, 11 Mar 2009 11:01:06 -0700 (PDT) Received: (qmail 18718 invoked from network); 11 Mar 2009 18:01:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.224.251 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 11 Mar 2009 18:01:42 -0000 X-YMail-OSG: nt1FZ3oVM1l8y.OgKNO1x5mEQXMUvcYk6I6dPCy_JzY0mcs7Q80ky8dCzLhhj8fs4lpxL4UuT4xWRGCpT3N.zC.cF551NBkMZFfG4KTY0f9SwIDkI3lIHclxliFJeopYIqJr7RaEZzLpmxSQ9iDp2LFX X-Yahoo-Newman-Property: ymail-3 Message-ID: <49B7FC85.5040801@netconfcentral.com> Date: Wed, 11 Mar 2009 11:01:41 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Netconf] comments on netconf-monitoring-04 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 18:01:07 -0000 Hi, There are several bugs introduced in this draft. - ToC IDs do not match real name (netconf-state vs. ietf-netconf-state) - typo in 1.1 - def. of username: s/likely be/likely to be/ - statistics diagram shows 'managementStatistics' as a child node; It is just the complexType name for the 'statistics' node - examples wrong (netconf-state vs. ietf-netconf-state) - YANG module has 'container netconf' (not ietf-netconf-state) Comments: - Abstract says what this data model module provides, but no mention why anybody should want to retrieve it. (e.g., is it for debugging NETCONF protocol errors?) - Introduction: says a NETCONF agent can change capabilities in the middle of a session. IMO, 4741-bis needs to define this behavior, not netconf-monitoring. It is not clear at all that this should be supported. - sec. 3.1 should mention that the operation is optional, and only supported if the :schema-retrieval capability is advertised by the agent. - :netconf-monitoring capability: Are we going to have a generic module capability AND a YANG module capability for every NETCONF data model? Can't we just use the YANG capability URI? The only YANG-ish detail is the 'deviations' parameter, which can be ignored if not used. - since many of my previous comments were not addressed, I can only assume this is the data model the WG wants and thinks is useful. IMO these statistics are mostly useful for comparing subtree/xpath filtering behavior on different agents. It is not clear to me what sort of protocol problems can be debugged with this data. (Keep in mind the session-id of the lock holder is returned in a failed reply, so don't count that one :-) Andy From andy@netconfcentral.com Wed Mar 11 11:51:58 2009 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 87D513A684C for ; Wed, 11 Mar 2009 11:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.084, 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 1Bi6q4Zvs97w for ; Wed, 11 Mar 2009 11:51:57 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id CB3D33A6358 for ; Wed, 11 Mar 2009 11:51:57 -0700 (PDT) Received: (qmail 96021 invoked from network); 11 Mar 2009 18:52:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.224.251 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 11 Mar 2009 18:52:34 -0000 X-YMail-OSG: fRnMGDcVM1msBqMS2sesnXwtanwSNXG8x2Pu54raD3IdToERVkHa5u3AbYV2Q0Ds49TAfIV62OG2vk7rCoztl1ntr0y.3Nzoq3ql0CG8EJZgYgeeLFW5Bds14lS2ZjWnQxo4L.9z7b6ei7jeJF0hcdAgWxa4D8Ud1HjR2PcAaLuxj0Kg2K6VJZE. X-Yahoo-Newman-Property: ymail-3 Message-ID: <49B80870.1020206@netconfcentral.com> Date: Wed, 11 Mar 2009 11:52:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETCONF References: <49B7FC85.5040801@netconfcentral.com> In-Reply-To: <49B7FC85.5040801@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] comments on netconf-monitoring-04 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 18:51:58 -0000 Andy Bierman wrote: > Hi, > > There are several bugs introduced in this draft. > add 1 more: - the new contact info in the YANG module got pasted inside the SessionId type-stmt, which breaks the module > - ToC IDs do not match real name (netconf-state vs. ietf-netconf-state) > - typo in 1.1 > - def. of username: s/likely be/likely to be/ > - statistics diagram shows 'managementStatistics' as a > child node; It is just the complexType name for the 'statistics' node > - examples wrong (netconf-state vs. ietf-netconf-state) > - YANG module has 'container netconf' (not ietf-netconf-state) > > Comments: > > - Abstract says what this data model module provides, but > no mention why anybody should want to retrieve it. > (e.g., is it for debugging NETCONF protocol errors?) > > - Introduction: says a NETCONF agent can change capabilities > in the middle of a session. IMO, 4741-bis needs to define > this behavior, not netconf-monitoring. It is not clear at > all that this should be supported. > > - sec. 3.1 should mention that the operation > is optional, and only supported if the :schema-retrieval > capability is advertised by the agent. > > - :netconf-monitoring capability: > Are we going to have a generic module capability AND a > YANG module capability for every NETCONF data model? > Can't we just use the YANG capability URI? > The only YANG-ish detail is the 'deviations' parameter, > which can be ignored if not used. > > - since many of my previous comments were not addressed, > I can only assume this is the data model the WG wants > and thinks is useful. IMO these statistics are mostly > useful for comparing subtree/xpath filtering behavior > on different agents. It is not clear to me what > sort of protocol problems can be debugged with this data. > (Keep in mind the session-id of the lock holder is returned > in a failed reply, so don't count that one :-) > > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From lhotka@cesnet.cz Fri Mar 13 08:08:43 2009 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 07D4028C119 for ; Fri, 13 Mar 2009 08:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.976 X-Spam-Level: X-Spam-Status: No, score=-0.976 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 fnWwZoWO5oZ4 for ; Fri, 13 Mar 2009 08:08:37 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E596428C174 for ; Fri, 13 Mar 2009 08:07:31 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id E7EC4D800C5 for ; Fri, 13 Mar 2009 16:08:09 +0100 (CET) From: Ladislav Lhotka To: NETCONF WG Content-Type: text/plain Organization: CESNET Date: Fri, 13 Mar 2009 16:08:10 +0100 Message-Id: <1236956890.6391.44.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Subject: [Netconf] comments on -with-defaults-00 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, 13 Mar 2009 15:08:43 -0000 Hi, here are my comments on draft-ietf-netconf-with-defaults-00: 1. I strongly support removing the sentence "However, an agent MUST accept it even if no namespace is used." at the end of sec. 2.5. 2. What happens if a subtree filter explicitly selects or matches the content of the leaf affected by default substitution when with-defaults is false? Using the example from the draft: false or false 1500 Does the result in either case depend on server's "basic" behaviour and if so, how? 3. Along the same lines, I think this capability in fact interacts with :xpath. Continuing the example, the results for the following expressions should be specified when with-defaults is false and for the different "basic" behaviours: //interfaces/interface/mtu //interfaces/interface[mtu='1500'] 4. Typos: - page 4, line 4: "its" instead of "it's" - first sentence in sec. 2.1.1: All three commas should IMO be removed, the word "device" probably too. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From balazs.lengyel@ericsson.com Fri Mar 13 09:16:21 2009 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 4D26B28C189 for ; Fri, 13 Mar 2009 09:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.993 X-Spam-Level: X-Spam-Status: No, score=-5.993 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVGGX7OYxGtX for ; Fri, 13 Mar 2009 09:16:20 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2DCC13A65A5 for ; Fri, 13 Mar 2009 09:16:20 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D88AF21872; Fri, 13 Mar 2009 17:16:57 +0100 (CET) X-AuditID: c1b4fb3e-af0a0bb0000023da-cf-49ba86f9c6ed Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B244B201E7; Fri, 13 Mar 2009 17:16:57 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 17:16:57 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 17:16:57 +0100 Message-ID: <49BA86F8.9010101@ericsson.com> Date: Fri, 13 Mar 2009 17:16:56 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ladislav Lhotka References: <1236956890.6391.44.camel@missotis> In-Reply-To: <1236956890.6391.44.camel@missotis> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2009 16:16:57.0505 (UTC) FILETIME=[21BCF110:01C9A3F7] X-Brightmail-Tracker: AAAAAA== Cc: NETCONF WG Subject: Re: [Netconf] comments on -with-defaults-00 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, 13 Mar 2009 16:16:21 -0000 Ladislav Lhotka wrote: > Hi, > > here are my comments on draft-ietf-netconf-with-defaults-00: > > 1. I strongly support removing the sentence "However, an agent MUST > accept it even if no namespace is used." at the end of sec. 2.5. BALAZS: OK, will be removed. BALAZS> > 2. What happens if a subtree filter explicitly selects or matches the > content of the leaf affected by default substitution when with-defaults > is false? Using the example from the draft: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns:wd="urn:ietf:params:xml:ns:netconf:with-defaults:1.0"> > > false > > > > > > > > > > > or > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns:wd="urn:ietf:params:xml:ns:netconf:with-defaults:1.0"> > > false > > > > 1500 > > > > > > > Does the result in either case depend on server's "basic" behaviour and if so, how? BALAZS: I don't know, but my opinion: If the manager explicitly asks for mtu=1500=default, then he should always get what he wants, all interfaces with mtu=1500 irrespective of how 1500 got there. If he just asks for interfaces with an MTU, we should follow the default behavior as described by the draft. If defaults are sent back the whole interface shall be sent back, if defaults are not sent back any interface with a default mtu=1500 should be absent from the reply. > > 3. Along the same lines, I think this capability in fact interacts > with :xpath. Continuing the example, the results for the following > expressions should be specified when with-defaults is false and for the > different "basic" behaviours: > > //interfaces/interface/mtu > > //interfaces/interface[mtu='1500'] BALAZS: Same as for subtree > > 4. Typos: > - page 4, line 4: "its" instead of "it's" > - first sentence in sec. 2.1.1: All three commas should IMO be > removed, the word "device" probably too. > BALAZS: OK. From balazs.lengyel@ericsson.com Fri Mar 13 09:19:20 2009 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 AEDD13A68F9 for ; Fri, 13 Mar 2009 09:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.005 X-Spam-Level: X-Spam-Status: No, score=-6.005 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7a157CeEnATF for ; Fri, 13 Mar 2009 09:19:20 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E53723A65A5 for ; Fri, 13 Mar 2009 09:19:19 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4A050213EC for ; Fri, 13 Mar 2009 17:19:57 +0100 (CET) X-AuditID: c1b4fb3c-af00dbb000001b43-e1-49ba87ad46b5 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 37075212BD for ; Fri, 13 Mar 2009 17:19:57 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 17:19:56 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 17:19:56 +0100 Message-ID: <49BA87AC.1090304@ericsson.com> Date: Fri, 13 Mar 2009 17:19:56 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2009 16:19:56.0776 (UTC) FILETIME=[8C978680:01C9A3F7] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Comment to 4741bis 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, 13 Mar 2009 16:19:20 -0000 8.8.5.1. The :url capability modifies the operation to accept the element as an alternative to the parameter. If the element is specified, then it should identify a local configuration file. This states that the URL may identify an external location. Is this correct? Should this be clarified? There is a similar - the url should identify a local file - statement for delete-config, but not for copy-config or for validate. Is this correct? Balazs From andy@netconfcentral.com Fri Mar 13 09:39:09 2009 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 D6D3E3A687F for ; Fri, 13 Mar 2009 09:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.202, 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 Y1E6fXCoUV71 for ; Fri, 13 Mar 2009 09:39:09 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 13DD23A65A5 for ; Fri, 13 Mar 2009 09:39:09 -0700 (PDT) Received: (qmail 7235 invoked from network); 13 Mar 2009 16:39:48 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.224.251 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 13 Mar 2009 16:39:47 -0000 X-YMail-OSG: r_aeACAVM1kaoCihoNsNZNrRbzdSrzHE01swmxYpMfVvou46kvZkFoIt4Q37kDa7yuxIRkyUwOXjJ5fMPVbUg2yZ2FLqAAOl8UkWPKYgYgr662UY2hUNzOwhAEX0vuOykWC6X8LNDc_vrTKWdFdmfXlGLsBZlTljboKQOTboHR_ipbVXNLgz9RtJw8Up X-Yahoo-Newman-Property: ymail-3 Message-ID: <49BA8C52.9010301@netconfcentral.com> Date: Fri, 13 Mar 2009 09:39:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Balazs Lengyel References: <1236956890.6391.44.camel@missotis> <49BA86F8.9010101@ericsson.com> In-Reply-To: <49BA86F8.9010101@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETCONF WG Subject: Re: [Netconf] comments on -with-defaults-00 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, 13 Mar 2009 16:39:09 -0000 Balazs Lengyel wrote: > > > Ladislav Lhotka wrote: >> Hi, >> >> here are my comments on draft-ietf-netconf-with-defaults-00: >> >> 1. I strongly support removing the sentence "However, an agent MUST >> accept it even if no namespace is used." at the end of sec. 2.5. > > BALAZS: OK, will be removed. > > BALAZS> >> 2. What happens if a subtree filter explicitly selects or matches the >> content of the leaf affected by default substitution when with-defaults >> is false? Using the example from the draft: >> >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" >> xmlns:wd="urn:ietf:params:xml:ns:netconf:with-defaults:1.0"> >> >> false >> >> >> >> >> >> >> >> >> >> >> or >> >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" >> xmlns:wd="urn:ietf:params:xml:ns:netconf:with-defaults:1.0"> >> >> false >> >> >> >> 1500 >> >> >> >> >> >> >> Does the result in either case depend on server's "basic" behaviour >> and if so, how? > > BALAZS: I don't know, but my opinion: > If the manager explicitly asks for mtu=1500=default, then he should > always get what he wants, all interfaces with mtu=1500 irrespective of > how 1500 got there. If he just asks for interfaces with an MTU, we > should follow the default behavior as described by the draft. If > defaults are sent back the whole interface shall be sent back, if > defaults are not sent back any interface with a default mtu=1500 should > be absent from the reply. > 1) The node will not be returned in any of the retrieved values, depending on how the agent handles defaults. Currently, the manager may have no idea which nodes will be returned. See my previous mail on with/without vs. basic=report-all. The current URI scheme is deficient. This is why. 2) The subtree/select filters are applied first. All the entries with an CURRENTLY equal to 1500 match this test. 3) The with-defaults test is applied to all the leafs/leaf-lists selected by the filter. If was set explicitly by any manager, or was present in the startup config, it will match for 'basic=explicit'. If the has a default of '1500', it will match for 'basic=trim'. This test is skipped for all key leafs. 4) Only the 'default' node is removed from the . All the entries that matched are still returned. Only the node (and any other default nodes) are omitted. >> >> 3. Along the same lines, I think this capability in fact interacts >> with :xpath. Continuing the example, the results for the following >> expressions should be specified when with-defaults is false and for the >> different "basic" behaviours: >> >> //interfaces/interface/mtu >> >> //interfaces/interface[mtu='1500'] > > BALAZS: Same as for subtree > >> >> 4. Typos: >> - page 4, line 4: "its" instead of "it's" >> - first sentence in sec. 2.1.1: All three commas should IMO be >> removed, the word "device" probably too. >> > BALAZS: OK. > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > Andy From lhotka@cesnet.cz Fri Mar 13 09:50:58 2009 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 B45CB3A6B19 for ; Fri, 13 Mar 2009 09:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.932 X-Spam-Level: X-Spam-Status: No, score=-0.932 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 5EPNZED0k7yN for ; Fri, 13 Mar 2009 09:50:58 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A9F8D28C0DF for ; Fri, 13 Mar 2009 09:50:57 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 0DC08D800C7; Fri, 13 Mar 2009 17:51:36 +0100 (CET) From: Ladislav Lhotka To: Balazs Lengyel In-Reply-To: <49BA86F8.9010101@ericsson.com> References: <1236956890.6391.44.camel@missotis> <49BA86F8.9010101@ericsson.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 13 Mar 2009 17:51:36 +0100 Message-Id: <1236963097.6391.92.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: NETCONF WG Subject: Re: [Netconf] comments on -with-defaults-00 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, 13 Mar 2009 16:50:58 -0000 Balazs Lengyel píše v Pá 13. 03. 2009 v 17:16 +0100: > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > > xmlns:wd="urn:ietf:params:xml:ns:netconf:with-defaults:1.0"> > > > > false > > > > > > > > > > > > > > > > > > > > > > or > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > > xmlns:wd="urn:ietf:params:xml:ns:netconf:with-defaults:1.0"> > > > > false > > > > > > > > 1500 > > > > > > > > > > > > > > Does the result in either case depend on server's "basic" behaviour and if so, how? > > BALAZS: I don't know, but my opinion: > If the manager explicitly asks for mtu=1500=default, then he should always get what he wants, > all interfaces with mtu=1500 irrespective of how 1500 got there. If he just asks for I think the idea of the "explicit" behaviour is that the value is not in the configuration unless explicitly set. So strictly speaking it hasn't got there. > interfaces with an MTU, we should follow the default behavior as described by the draft. If The case with message-id="103" doesn't ask for interfaces with mtu but for the mtu leaf itself. So the reply could contain either 8192 1500 or 8192 or even 8192 Which one is correct? Lada > defaults are sent back the whole interface shall be sent back, if defaults are not sent back > any interface with a default mtu=1500 should be absent from the reply. > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Fri Mar 13 10:16:38 2009 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 9B6D028C271 for ; Fri, 13 Mar 2009 10:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.917 X-Spam-Level: X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 18C9ydwS2g1U for ; Fri, 13 Mar 2009 10:16:37 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4190228C26C for ; Fri, 13 Mar 2009 10:16:37 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id B3F5ED800C8; Fri, 13 Mar 2009 18:17:15 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <49BA8C52.9010301@netconfcentral.com> References: <1236956890.6391.44.camel@missotis> <49BA86F8.9010101@ericsson.com> <49BA8C52.9010301@netconfcentral.com> Content-Type: text/plain; charset=utf-8 Organization: CESNET Date: Fri, 13 Mar 2009 18:17:16 +0100 Message-Id: <1236964636.6391.115.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Cc: NETCONF WG Subject: Re: [Netconf] comments on -with-defaults-00 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, 13 Mar 2009 17:16:38 -0000 I think it is necessary to precisely define the XML documents that various operations work with. While the document "with defaults" is probably unambiguous, the one "without defaults" is fuzzy and depends on the "basic" behaviour. One way for resolving this would be to define two documents that can be mapped to each other in both directions given a full specification of default values: (1) Configuration with all defaults (2) Configuration without defaults, meaning that ALL leaves having the same (value-space) value as the default spec are removed. Then by definition with-default=true will operate of the tree (1) whereas with-default=false on (2). The results will then be quite predictable. Agents could work internally with either (1) or (2), or even something in between, but must be prepared to derive either tree if necessary and do the right thing. Lada Andy Bierman píše v Pá 13. 03. 2009 v 09:39 -0700: > Balazs Lengyel wrote: > > > > > > Ladislav Lhotka wrote: > >> Hi, > >> > >> here are my comments on draft-ietf-netconf-with-defaults-00: > >> > >> 1. I strongly support removing the sentence "However, an agent MUST > >> accept it even if no namespace is used." at the end of sec. 2.5. > > > > BALAZS: OK, will be removed. > > > > BALAZS> > >> 2. What happens if a subtree filter explicitly selects or matches the > >> content of the leaf affected by default substitution when with-defaults > >> is false? Using the example from the draft: > >> > >> >> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > >> xmlns:wd="urn:ietf:params:xml:ns:netconf:with-defaults:1.0"> > >> > >> false > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> or > >> > >> >> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > >> xmlns:wd="urn:ietf:params:xml:ns:netconf:with-defaults:1.0"> > >> > >> false > >> > >> > >> > >> 1500 > >> > >> > >> > >> > >> > >> > >> Does the result in either case depend on server's "basic" behaviour > >> and if so, how? > > > > BALAZS: I don't know, but my opinion: > > If the manager explicitly asks for mtu=1500=default, then he should > > always get what he wants, all interfaces with mtu=1500 irrespective of > > how 1500 got there. If he just asks for interfaces with an MTU, we > > should follow the default behavior as described by the draft. If > > defaults are sent back the whole interface shall be sent back, if > > defaults are not sent back any interface with a default mtu=1500 should > > be absent from the reply. > > > > 1) The node will not be returned in any of the > retrieved values, depending on how the agent handles defaults. > Currently, the manager may have no idea which nodes will be returned. > See my previous mail on with/without vs. basic=report-all. > The current URI scheme is deficient. This is why. > > 2) The subtree/select filters are applied first. > All the entries with an CURRENTLY equal > to 1500 match this test. > > 3) The with-defaults test is applied to all the leafs/leaf-lists > selected by the filter. If was set explicitly by any manager, > or was present in the startup config, it will match > for 'basic=explicit'. If the has a default of '1500', > it will match for 'basic=trim'. This test is skipped > for all key leafs. > > 4) Only the 'default' node is removed from the . > All the entries that matched are still returned. > Only the node (and any other default nodes) are omitted. > > > > > >> > >> 3. Along the same lines, I think this capability in fact interacts > >> with :xpath. Continuing the example, the results for the following > >> expressions should be specified when with-defaults is false and for the > >> different "basic" behaviours: > >> > >> //interfaces/interface/mtu > >> > >> //interfaces/interface[mtu='1500'] > > > > BALAZS: Same as for subtree > > > >> > >> 4. Typos: > >> - page 4, line 4: "its" instead of "it's" > >> - first sentence in sec. 2.1.1: All three commas should IMO be > >> removed, the word "device" probably too. > >> > > BALAZS: OK. > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > Andy > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.com Fri Mar 13 10:55:41 2009 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 3DC463A68FB for ; Fri, 13 Mar 2009 10:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.350, 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 kESPfWDK3XT7 for ; Fri, 13 Mar 2009 10:55:40 -0700 (PDT) Received: from n6.bullet.mud.yahoo.com (n6.bullet.mud.yahoo.com [216.252.100.57]) by core3.amsl.com (Postfix) with SMTP id EDF7A3A6A7A for ; Fri, 13 Mar 2009 10:55:39 -0700 (PDT) Received: from [68.142.194.244] by n6.bullet.mud.yahoo.com with NNFMP; 13 Mar 2009 17:56:18 -0000 Received: from [68.142.201.244] by t2.bullet.mud.yahoo.com with NNFMP; 13 Mar 2009 17:56:18 -0000 Received: from [127.0.0.1] by omp405.mail.mud.yahoo.com with NNFMP; 13 Mar 2009 17:56:18 -0000 X-Yahoo-Newman-Id: 581466.86560.bm@omp405.mail.mud.yahoo.com Received: (qmail 29363 invoked from network); 13 Mar 2009 17:56:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.224.251 with plain) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 13 Mar 2009 17:56:17 -0000 X-YMail-OSG: BUoiC9IVM1mWKGmOLfUBGNoKgCsTrp5E_eFQghQBjNQ8oPA03STI.7z55uG8cqDia2ziWO2KKb6nMA7WkrPj.XIAVI3mgzwyqjo_j0TgCu_ag9IrLwyas1G5RSomxqaah6QBawADpUIIOSbvwHvSkHjaSUHT1gkQYpqcThuR83kHIo8_G7jOnOmFptSo X-Yahoo-Newman-Property: ymail-3 Message-ID: <49BA9E3F.2090800@netconfcentral.com> Date: Fri, 13 Mar 2009 10:56:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ladislav Lhotka References: <1236956890.6391.44.camel@missotis> <49BA86F8.9010101@ericsson.com> <49BA8C52.9010301@netconfcentral.com> <1236964636.6391.115.camel@missotis> In-Reply-To: <1236964636.6391.115.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: NETCONF WG Subject: Re: [Netconf] comments on -with-defaults-00 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, 13 Mar 2009 17:55:41 -0000 Ladislav Lhotka wrote: > I think it is necessary to precisely define the XML documents that > various operations work with. While the document "with defaults" is > probably unambiguous, the one "without defaults" is fuzzy and depends on > the "basic" behaviour. One way for resolving this would be to define two > documents that can be mapped to each other in both directions given a > full specification of default values: > IMO the correct approach is to specify in the capability URI which behavior will be used for with-defaults=false. > (1) Configuration with all defaults > > (2) Configuration without defaults, meaning that ALL leaves having the > same (value-space) value as the default spec are removed. > > Then by definition with-default=true will operate of the tree (1) > whereas with-default=false on (2). The results will then be quite > predictable. > > Agents could work internally with either (1) or (2), or even something > in between, but must be prepared to derive either tree if necessary and > do the right thing. > The 'right thing', according to your POV. One of the significant differences between SNMP and NETCONF it the design goal in NETCONF to accommodate common practices and implementation strategies, instead of ignoring them or picking 1 way to do something. (e.g., :candidate vs. :writable-running). There is another definition of 'default' in use, which is called 'explicit' in the draft. In this definition, the value of default-stmt (or any other schema form of default-stmt) is irrelevant. The only thing that matters is whether the operator set the value or the agent set the value. There is no schema validation possible for this 'mode', but that is not really important. This is just another hard-wired retrieval filtering mechanism, like vs. . I understand that an operator expecting the filtering to be more predictable will not be happy, but the NETCONF behavior will be consistent with the native CLI behavior. The main behavior this draft mandates is what happens when with-defaults=true. All leafs are returned, no matter what internal implementation strategy is used. That feature is currently missing from the protocol. > Lada Andy > > Andy Bierman píše v Pá 13. 03. 2009 v 09:39 -0700: >> Balazs Lengyel wrote: >>> >>> Ladislav Lhotka wrote: >>>> Hi, >>>> >>>> here are my comments on draft-ietf-netconf-with-defaults-00: >>>> >>>> 1. I strongly support removing the sentence "However, an agent MUST >>>> accept it even if no namespace is used." at the end of sec. 2.5. >>> BALAZS: OK, will be removed. >>> >>> BALAZS> >>>> 2. What happens if a subtree filter explicitly selects or matches the >>>> content of the leaf affected by default substitution when with-defaults >>>> is false? Using the example from the draft: >>>> >>>> >>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" >>>> xmlns:wd="urn:ietf:params:xml:ns:netconf:with-defaults:1.0"> >>>> >>>> false >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> or >>>> >>>> >>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" >>>> xmlns:wd="urn:ietf:params:xml:ns:netconf:with-defaults:1.0"> >>>> >>>> false >>>> >>>> >>>> >>>> 1500 >>>> >>>> >>>> >>>> >>>> >>>> >>>> Does the result in either case depend on server's "basic" behaviour >>>> and if so, how? >>> BALAZS: I don't know, but my opinion: >>> If the manager explicitly asks for mtu=1500=default, then he should >>> always get what he wants, all interfaces with mtu=1500 irrespective of >>> how 1500 got there. If he just asks for interfaces with an MTU, we >>> should follow the default behavior as described by the draft. If >>> defaults are sent back the whole interface shall be sent back, if >>> defaults are not sent back any interface with a default mtu=1500 should >>> be absent from the reply. >>> >> 1) The node will not be returned in any of the >> retrieved values, depending on how the agent handles defaults. >> Currently, the manager may have no idea which nodes will be returned. >> See my previous mail on with/without vs. basic=report-all. >> The current URI scheme is deficient. This is why. >> >> 2) The subtree/select filters are applied first. >> All the entries with an CURRENTLY equal >> to 1500 match this test. >> >> 3) The with-defaults test is applied to all the leafs/leaf-lists >> selected by the filter. If was set explicitly by any manager, >> or was present in the startup config, it will match >> for 'basic=explicit'. If the has a default of '1500', >> it will match for 'basic=trim'. This test is skipped >> for all key leafs. >> >> 4) Only the 'default' node is removed from the . >> All the entries that matched are still returned. >> Only the node (and any other default nodes) are omitted. >> >> >> >> >>>> 3. Along the same lines, I think this capability in fact interacts >>>> with :xpath. Continuing the example, the results for the following >>>> expressions should be specified when with-defaults is false and for the >>>> different "basic" behaviours: >>>> >>>> //interfaces/interface/mtu >>>> >>>> //interfaces/interface[mtu='1500'] >>> BALAZS: Same as for subtree >>> >>>> 4. Typos: >>>> - page 4, line 4: "its" instead of "it's" >>>> - first sentence in sec. 2.1.1: All three commas should IMO be >>>> removed, the word "device" probably too. >>>> >>> BALAZS: OK. >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> >> Andy >> From MARKSCOT@nortel.com Fri Mar 13 13:44:46 2009 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 76E083A682D for ; Fri, 13 Mar 2009 13:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGr-iGv51aDk for ; Fri, 13 Mar 2009 13:44:43 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 32C083A6AA3 for ; Fri, 13 Mar 2009 13:44:42 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2DKiQ406572; Fri, 13 Mar 2009 20:44:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9A41C.8AB60362" Date: Fri, 13 Mar 2009 16:44:43 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC02620D24@zcarhxm0.corp.nortel.com> In-Reply-To: <20090309234501.9601128C286@core3.amsl.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Netconf] I-D Action:draft-ietf-netconf-monitoring-04.txt Thread-Index: AcmhEcB/rCaD0qfnTQmbygWzQsNHDwDBguIA References: <20090309234501.9601128C286@core3.amsl.com> From: "Mark Scott" To: "Juergen Schoenwaelder" , "Balazs Lengyel" , "Andy Bierman" , "Washam Fan" Cc: netconf@ietf.org Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-monitoring-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 20:44:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A41C.8AB60362 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, The updated draft below addresses the comments received in the WGLC of draft-ietf-netconf-monitoring-03. I have attached a document containing the responses to all comments indicating: - updated in v04 where applicable - open item to be discussed at IETF74 - item to be followed up on the mailing list If any comments on v03 were (unintentionally) missed please raise them to my attention again. They will be addressed in v05 along with others comments received on v04 (incl. those already raised by Andy - thanks!). Mark -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, March 09, 2009 7:45 PM To: i-d-announce@ietf.org Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Monitoring Schema Author(s) : M. Scott, et al. Filename : draft-ietf-netconf-monitoring-04.txt Pages : 46 Date : 2009-03-09 This document defines a NETCONF data model (in XML Schema) to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF datastores, sessions, locks, subscriptions, and statistics. This data facilitates the management of a NETCONF server. This document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new NETCONF operation to retrieve them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C9A41C.8AB60362 Content-Type: text/plain; name="WGLC review of draft-ietf-netconf-monitoring-03 [Reponses - v4].txt" Content-Transfer-Encoding: base64 Content-Description: WGLC review of draft-ietf-netconf-monitoring-03 [Reponses - v4].txt Content-Disposition: attachment; filename="WGLC review of draft-ietf-netconf-monitoring-03 [Reponses - v4].txt" Q29tbWVudHMgcmVjZWl2ZWQgZHVyaW5nIFdHTEMgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLW1vbml0 b3JpbmctMDMuDQoNCg0KSnVlcmdlbiBDb21tZW50cw0KLS0tLS0tLS0tLS0tLS0tLQ0KDQphKSBU aGUgYWJzdHJhY3QgZG9lcyAoYSkgbm90IHN1bW1hcml6ZSBhbGwgdGhlIHRoaW5ncyBjb3ZlcmVk IGluIHRoZQ0KICAgZGF0YSBtb2RlbCBhbmQgKGIpIGlzIHRvbyBsb25nIGFuIGRldGFpbGVkIGZv ciB0aGUgdGhpbmdzDQogICBjb3ZlcmVkLiBJIHByb3Bvc2UgdG8gY29tcG9zZSBhIG5ldyBzaG9y dCBhYnN0cmFjdCBhbmQgdG8gbW92ZSBtb3N0DQogICBvZiB0aGUgZXhpc3RpbmcgdGV4dCBpbnRv IHNlY3Rpb24gMSBiZWZvcmUgMS4xLCBleHRlbmRpbmcgaXQgYXMNCiAgIG5lZWRlZC4NCg0KW1Jl c3BvbnNlXSAgVXBkYXRlIGluIHYwNC4NCg0KDQpiKSBUaGUgZG9jdW1lbnQgYXNzdW1lcyB0aGF0 IGNhcGFiaWxpdGllcyAvIHNjaGVtYXMgY2FuIGR5bmFtaWNhbGx5DQogICBjaGFuZ2UgYW5kIGl0 IGtpbmQgb2YgYXNzdW1lcyB0aGF0IGFwcGxpY2F0aW9ucyBwb2xsIHRoZQ0KICAgL25ldGNvbmYv c2NoZW1hIHRyZWUuIEkgYW0gd29uZGVyaW5nIHdoZXJlIHRoZXJlIGlzIG5vdCBhDQogICBub3Rp ZmljYXRpb24gZGVmaW5lZCBzbyB0aGF0IEkgY2FuIHN1YnNjcmliZSBhbmQgZ2V0IG5vdGlmaWVk DQogICBpZiB0aGUgY2FwYWJpbGl0aWVzIC8gc2NoZW1hcyBjaGFuZ2UuDQoNCltSZXNwb25zZV0g VGhlIHNjaGVtYSBsaXN0IGlzIG9wZXJhdGlvbmFsIGRhdGEgc28gZXhpc3RpbmcgTkVUQ09ORg0K Y29uZmlndXJhdGlvbiB1cGRhdGUgbm90aWZpY2F0aW9ucyB3b3VsZCBzdWZmaWNlIHRvIG5vdGlm eSB0aGF0IHRoZQ0KY29uZmlndXJhdGlvbiBoYXMgYmVlbiB1cGRhdGVkLiAgTm90aW5nIHRoYXQg dGhlIHN0YW5kYXJkIGV2ZW50IA0KdHlwZXMgYXJlIG5vdCBhZ3JlZWQgeWV0IGJ1dCB0aGlzIGNv dWxkIGJlIGNvdmVyZWQgaW4gdGhhdCB3b3JrIGlmIA0KYSBzcGVjaWZpYyAiY2FwYWJpbGl0aWVz L3NjaGVtYSBjaGFuZ2UiIG5vdGlmaWNhdGlvbiBpcyByZXF1aXJlZCAoc2VlbXMNCmxpa2UgYSBn b29kIGlkZWEgdG8gbWUpLiAgDQoNClRoZSBuZWVkIGZvciBzdWNoIGEgbm90aWZpY2F0aW9uIGRl cGVuZHMgb24gaG93IHdlIGRlY2lkZSANCk5FVENPTkYgc2VydmVyIHNob3VsZCBiZWhhdmUgaW4g ZXZlbnQgb2YgZHluYW1pYyBjYXBhYmlsaXRpZXMgY2hhbmdlLg0KDQpMaWtlbHkgbmVlZHMgdG8g YmUgYWRkcmVzc2VkIGluIDQ3NDFiaXMgZmlyc3QuDQoNCg0KYykgVGVybWlub2xvZ3k6DQoNCiAg IE9wZXJhdGlvbjogIFRoaXMgdGVybSBpcyB1c2VkIHRvIHJlZmVyIHRvIE5FVENPTkYgcHJvdG9j b2wNCiAgICAgIG9wZXJhdGlvbnMuICBTcGVjaWZpY2FsbHkgd2l0aGluIHRoaXMgZG9jdW1lbnQs IG9wZXJhdGlvbiByZWZlcnMNCiAgICAgIHRvIE5FVENPTkYgcHJvdG9jb2wgb3BlcmF0aW9ucyBk ZWZpbmVkIGluIHN1cHBvcnQgb2YgTkVUQ09ORg0KICAgICAgbW9uaXRvcmluZy4NCg0KICAgSSBm YWlsIHRvIHNlZSB2YWx1ZSBpbiBnaXZpbmcgdGhlIHRlcm0gb3BlcmF0aW9uIGEgbW9yZQ0KICAg Y29uc3RyYWludGVkIG1lYW5pbmcuIEkgcHJlZmVyIHRvIGhhdmUgdGhlIHRlcm0gdXNlZCB3aXRo IHRoZQ0KICAgbm9ybWFsIFJGQyA0NzQxIG1lYW5pbmcuDQoNCltSZXNwb25zZV0gQWdyZWVkLiAg Tm8gZnVydGhlciBkZWZpbml0aW9uIHJlcXVpcmVkIGhlcmUuICBSZW1vdmVkIGZyb20gdjA0Lg0K DQoNCmQpIFRlcm1pbm9sb2d5Og0KDQogICBTY2hlbWE6ICBUaGlzIHRlcm0gaXMgdXNlZCB0byBy ZWZlciB0byBhIGRhdGEgbW9kZWwgZnJhZ21lbnQsDQogICAgICBpbmRlcGVuZGVudCBvZiB3aGlj aCBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlIGlzIHVzZWQgaW4gdGhlIGRhdGENCiAgICAgIG1vZGVs Lg0KDQogICBXaGF0IGlzIGEgImRhdGEgbW9kZWwgZnJhZ21lbnQiPyBJIHN1Z2dlc3QgdG8gcmVw bGFjZSB0aGlzIHBocmFzZQ0KICAgd2l0aCAiYSBtYWNoaW5lIHJlYWRhYmxlIGRhdGEgbW9kZWwg ZGVmaW5pdGlvbiIuDQoNCltSZXNwb25zZV0gIFVwZGF0ZSBpbiB2MDQuDQoNCg0KZSkgSSB3b3Vs ZCBwcmVmZXIgaWYgc2VjdGlvbiAyLiB3b3VsZCBmb2N1cyBvbiB0aGUgWE1MIGluc3RhbmNlDQog ICBkb2N1bWVudCBzdHJ1Y3R1cmUgYW5kIGJlIG1vcmUgZGF0YSBtb2RlbGluZyBsYW5ndWFnZSBh Z25vc3RpYy4gSQ0KICAgYmVsaWV2ZSB0aGlzIGltcHJvdmVzIHJlYWRhYmlsaXR5IHNpbmNlIGlu c3RhbmNlIGRvY3VtZW50IHN0cnVjdHVyZQ0KICAgaXMgcmVhbGx5IHRoZSBtb3N0IGltcG9ydGFu dCB0byBnZXQgcmlnaHQuIEkgd2lsbCBkZXRhaWwgY29uY3JldGUNCiAgIGNoYW5nZXMgaW4gdGhl IGZvbGxvd2luZyBjb21tZW50cy4NCg0KW1Jlc3BvbnNlXSAgU3BlY2lmaWMgaXRlbXMgYWRkcmVz c2VkIGJlbG93Lg0KDQpmKSBDaGFuZ2UgdGl0bGUgb2YgMi4xIHRvOiBUaGUgL25ldGNvbmYgU3Vi dHJlZQ0KDQpbUmVzcG9uc2VdIFVwZGF0ZSBpbiB2MDQuDQoNCmcpIFR1cm4gdGhlIGZpcnN0IHR3 byBzZW50ZW5jZSBmcmFnZW1lbnRzIGludG8gZnVsbCBzZW50ZW5jZXM6DQoNCiAgIFRoZSAvbmV0 Y29uZiBzdWJ0cmVlIGlzIHRoZSByb290IG9mIHRoZSBtb25pdG9yaW5nIGRhdGEgbW9kZWwuICBJ dA0KICAgYWN0cyBhcyBhIGNvbnRhaW5lciBmb3IgdGhlIG90aGVyIG1vbml0b3JlZCBkYXRhLg0K DQpbUmVzcG9uc2VdIFVwZGF0ZSBpbiB2MDQuDQoNCmgpIEkgc3VnZ2VzdGVkIHRvIHJlbmFtZSAi Y29uZmlndXJhdGlvbnMiIHRvICJkYXRhc3RvcmVzIiBzaW5jZSB0aGlzDQogICBzZWVtcyB0byBi ZSB0aGUgbW9yZSBhcHByb3ByaWF0ZSB0ZXJtLiBTbyB0aGluZ3MgYmVjb21lOg0KDQogICBkYXRh c3RvcmVzOiAodHlwZTogIENvbmZpZ3VyYXRpb25EYXRhc3RvcmUpDQogICAgTGlzdCBvZiBORVRD T05GIGRhdGFzdG9yZXMgb24gdGhlIHNlcnZlci4NCiAgICBJbmNsdWRlcyBhbGwgc3VwcG9ydGVk IGRhdGFzdG9yZSB0eXBlcyAocnVubmluZywgY2FuZGlkYXRlLCBzdGFydHVwKS4NCg0KW1Jlc3Bv bnNlXSBVcGRhdGUgaW4gdjA0LiAgWFNEIGFuZCBZQU5HIHVwZGF0ZWQgdG8gcmVmbGVjdCB0aGUg Y2hhbmdlLg0KDQppKSBXb3JkaW5nIGNoYW5nZSAodXNlIHBsdXJhbCkuIE9MRDoNCg0KICBzY2hl bWFzICh0eXBlOiAgU2NoZW1hRW50cnkpDQogICAgTGlzdCBvZiBzY2hlbWFzIHN1cHBvcnRlZCBv biB0aGUgc2VydmVyLg0KICAgIEluY2x1ZGVzIGFsbCB0aGUgaW5mb3JtYXRpb24gcmVxdWlyZWQg dG8gaWRlbnRpZnkgdGhlIHNjaGVtYSBhbmQNCiAgICB0byBzdXBwb3J0IGl0cyByZXRyaWV2YWwu DQoNCiAgIE5FVzoNCg0KICBzY2hlbWFzICh0eXBlOiAgU2NoZW1hRW50cnkpDQogICAgTGlzdCBv ZiBzY2hlbWFzIHN1cHBvcnRlZCBvbiB0aGUgc2VydmVyLg0KICAgIEluY2x1ZGVzIGFsbCB0aGUg aW5mb3JtYXRpb24gcmVxdWlyZWQgdG8gaWRlbnRpZnkgc2NoZW1hcyBhbmQNCiAgICB0byBzdXBw b3J0IHRoZWlyIHJldHJpZXZhbC4NCg0KW1Jlc3BvbnNlXSBVcGRhdGUgaW4gdjA0Lg0KDQpqKSBD bGFyaWZpY2F0aW9uIG5lZWRlZDoNCg0KICBzZXNzaW9ucyAodHlwZTogIE1hbmFnZW1lbnRTZXNz aW9uKQ0KICAgIExpc3Qgb2YgYWxsIGFjdGl2ZSBzZXNzaW9ucyBvbiB0aGUgZGV2aWNlIGluY2x1 ZGluZyBORVRDT05GDQogICAgYW5kIG90aGVyIHNlc3Npb25zIChlZzogQ0xJKS4NCg0KICAgSSB0 aGluayB0aGlzIG5lZWRzIGNsYXJpZmljYXRpb24uIEkgZG91YnQgeW91IHdhbnQgdG8gcmVwb3J0 IGENCiAgIG5vcm1hbCB1c2VyIGxvZ2luIG9uIGEgVW5peCBzZXJ2ZXIsIG9yIHdhcyB0aGF0IHRo ZSBpbnRlbnRpb24/DQoNCltSZXNwb25zZV0gIEludGVudGlvbiBpcyB0byBjb3ZlciBhbnkgbG9n aW4gd2hpY2ggYSBjb25maWd1cmF0aW9uIA0KY2xpZW50IG1heSBiZSBpbnRlcmVzdGVkIGluIChp ZS4gdGhhdCBjYW4gY2hhbmdlIHRoZSBjb25maWd1cmF0aW9uDQpvciBvcGVyYXRpb25hbCBzdGF0 ZSBvZiB0aGUgZGV2aWNlKS4gIEZvciBwdXJwb3NlcyBvZiB0aGlzIGRvY3VtZW50DQp0aGUgZGVm aW5pdGlvbiBpcyBuYXJyb3dlZCB0byBhbGwgIk5FVENPTkYgY2xpZW50IHNlc3Npb25zIGFjcm9z cw0KYWxsIHByb3RvY29scyIgYXMgZGVmaW5lZCBpbiBNYW5hZ2VtZW50U2Vzc2lvbkluZm8uUHJv dG9jb2xUeXBlLg0KDQprKSBDaGFuZ2UgdGl0bGUgb2YgMi4xLjEgdG86IFRoZSAvbmV0Y29uZi9j YXBhYmlsaXRpZXMgU3VidHJlZQ0KDQpbUmVzcG9uc2VdIFVwZGF0ZSBpbiB2MDQuDQoNCmwpIENh biBjYXBhYmlsaXRpZXMgYW5ub3VuY2VkIGR1cmluZyA8aGVsbG8+IGJlIGRyb3BwZWQgd2l0aG91 dA0KICAgY2xvc2luZyB0aGUgc2Vzc2lvbj8gSWYgbm90LCB0aGVuIHRoZSB0ZXh0IHNob3VsZCBi ZSBjaGFuZ2VkLg0KDQogICBPTEQ6DQoNCiAgIFRoZSBsaXN0IE1VU1QgaW5jbHVkZSBhbGwgY2Fw YWJpbGl0aWVzIGV4Y2hhbmdlZCBkdXJpbmcgc2Vzc2lvbg0KICAgc2V0dXAgc3RpbGwgYXBwbGlj YWJsZSBhdCB0aGUgdGltZSBvZiB0aGUgcmVxdWVzdC4NCg0KICAgTkVXOg0KDQogICBUaGUgbGlz dCBNVVNUIGluY2x1ZGUgYWxsIGNhcGFiaWxpdGllcyBleGNoYW5nZWQgZHVyaW5nIHNlc3Npb24g c2V0dXAuDQoNCltSZXNwb25zZV0gVGhpcyBuZWVkcyB0byBiZSBhZGRyZXNzZWQgaW4gNDc0MSBi aXMuDQoNCkkgdGhpbmsgdGhlIGV4aXN0aW5nIHF1YWxpZnlpbmcgdGV4dDogICJUaGUgbGlzdCBN VVNUIGluY2x1ZGUNCiAgYWxsIGNhcGFiaWxpdGllcyBleGNoYW5nZWQgZHVyaW5nIHNlc3Npb24g c2V0dXAgc3RpbGwgYXBwbGljYWJsZQ0KICBhdCB0aGUgdGltZSBvZiB0aGUgcmVxdWVzdC4gVGhp cyBlbnN1cmVzIGNvbnNpc3RlbmN5IHdpdGggdGhlDQogIGluaXRpYWwgY2FwYWJpbGl0aWVzIGV4 Y2hhbmdlZCB3aGlsZSBhbGxvd2luZyBmb3IgcG90ZW50aWFsDQogIG1vZGlmaWNhdGlvbnMgZHVy aW5nIGEgc2Vzc2lvbi4iDQpzdWZmaWNlcyBmb3IgdGhpcyBkb2N1bWVudC4NCg0KDQptKSBDaGFu Z2UgdGl0bGUgb2YgMi4xLjIgdG86IFRoZSAvbmV0Y29uZi9kYXRhc3RvcmVzIFN1YnRyZWUNCg0K W1Jlc3BvbnNlXSBVcGRhdGUgaW4gdjA0Lg0KDQpuKSBNYWtlIHRoZSBmaXJzdCBzZW50ZW5jZSBp biAyLjEuMiBhIGZ1bGwgc2VudGVuY2UuDQoNCltSZXNwb25zZV0gVXBkYXRlIGluIHYwNC4NCg0K bykgU2VjdGlvbiAyLjEuMiBuZWVkcyB0byBiZSBleHBhbmRlZC4gSXQgdGFsa3MgYWJvdXQgbG9j a2VkTm9kZXMgYW5kDQogICBzdWNoIHRoaW5ncyBhbmQgdGhpcyByZXF1aXJlcyB0byBmaXJzdCBy ZWFkIHRoZSBkYXRhIG1vZGVsIGluIG9yZGVyDQogICB0byB1bmRlcnN0YW5kIHRoaXMgdGV4dC4g VGhpcyBtaWdodCByZXF1aXJlIHRvIGludHJvZHVjZSBhDQogICBzdWJzZWN0aW9uIGRlc2NyaWJp bmcgdGhlIC9uZXRjb25mL2RhdGFzdG9yZS9sb2NrcyBzdWJ0cmVlLg0KDQpbUmVzcG9uc2VdIFVw ZGF0ZSBpbiB2MDQuDQoNCg0KcCkgQ2hhbmdlIHRpdGxlIG9mIDIuMS4zIHRvOiBUaGUgL25ldGNv bmYvc2NoZW1hcyBTdWJ0cmVlDQoNCltSZXNwb25zZV0gVXBkYXRlIGluIHYwNC4NCg0KDQpxKSBJ IHN1Z2dlc3QgdG8gcmVuYW1lIHNjaGVtYS9pZGVudGlmaWVyIHRvIHNjaGVtYS9uYW1lLiBBZnRl ciBhbGwsDQogICBpdCBjb250YWlucyBhIG5hbWUuIFNlZSBhbHNvIHMpIGJlbG93Lg0KDQpbUmVz cG9uc2VdIEknZCBwcmVmZXIgdG8gbGVhdmUgdGhpcyBhcyBJZGVudGlmaWVyIHNpbmNlIHdlIHNw ZWNpZnkgdGhhdA0KaXQgbWF5IGNvbnRhaW4gYSBtb2R1bGUgbmFtZSwgZmlsZW5hbWUsIG9yIHNv bWUgb3RoZXIgaW1wbGVtZW5hdGlvbiANCnNwZWNpZmljIGlkZW50aWZpZXIuICBTZWUgcmVzcG9u c2UgdG8gcykgYmVsb3cgZm9yIGNoYW5nZXMuDQoNCg0KcikgVGVybWlub2xvZ3kgY29uc2lzdGVu Y3kgY2hhbmdlOg0KDQogICBPTEQ6DQoNCiAgIFRoZXkgYXJlIGFsc28gdXNlZCBpbiB0aGUgPGdl dC1zY2hlbWE+IFJQQy4NCg0KICAgTkVXOg0KDQogICBUaGV5IGFyZSBhbHNvIHVzZWQgaW4gdGhl IDxnZXQtc2NoZW1hPiBvcGVyYXRpb24uDQoNCltSZXNwb25zZV0gVXBkYXRlIGluIHYwNC4NCg0K cykgVGhlIGRlc2NyaXB0aW9uIGxlYXZlcyBpdCBvcGVuIHdoZXRoZXIgdGhlIGlkZW50aWZpZXIg KG9yIG5hbWUpDQogICBjb250YWlucyBhIG1vZHVsZSBuYW1lIG9yIGEgZmlsZSBuYW1lLiBUaGlz IGlzIG5vdCBnb29kIGZvcg0KICAgaW50ZXJvcGVyYWJpbGl0eS4gRnVydGhlcm1vcmUsIHRoZSBZ QU5HIGRlc2NyaXB0aW9uIHRlbGxzIG1lIGFnYWluDQogICBzb21ldGhpbmcgZGlmZmVyZW50LiBJ IHN1Z2dlc3QgdGhhdCBpdCBtdXN0IGJlIHRoZSBtb2R1bGUgbmFtZSBmb3INCiAgIGRhdGEgbW9k ZWxpbmcgbGFuZ3VhZ2VzIHRoYXQgaGF2ZSBhIGNvbmNlcHQgb2YgYSBtb2R1bGUgbmFtZSBhbmQg aXQNCiAgIG1heSBiZSBhIGZpbGVuYW1lIGluIG90aGVyIGNhc2VzLg0KDQpbUmVzcG9uc2VdIERv bmUuICBDbGFyaWZpZWQgdGhhdCB0aGlzIG11c3QgYmUgYSBtb2R1bGUgbmFtZSAoaWYgc3VwcG9y dGVkDQpvciByZXF1aXJlZCBieSB0aGUgRE1MKSBvdGhlcndpc2UgY2FuIGNvbnRhaW4gc29tZSBv dGhlciBpZGVudGlmaWVyDQpzdWNoIGFzIGEgZmlsZW5hbWUuDQoNCg0KdCkgRWRpdG9yaWFsOg0K DQogICBPTEQ6DQoNCiAgIEVhY2ggTVVTVCBiZSByZXBvcnRlZA0KDQogICBORVc6DQoNCiAgIEVh Y2ggdmVyc2lvbiBNVVNUIGJlIHJlcG9ydGVkDQoNCltSZXNwb25zZV0gVXBkYXRlIGluIHYwNC4N Cg0KDQp1KSBZb3UgbWFrZSB0aGUgYXNzdW1wdGlvbiB0aGF0IGEgc2NoZW1hIGNhbiBvbmx5IGRl ZmluZSBvbmUNCiAgIG5hbWVzcGFjZS4gIFRoaXMgbWlnaHQgYmUgT0sgYnV0IEkgd2FudGVkIHRv IHNwZWxsIHRoaXMgb3V0IHNvIHRoYXQNCiAgIHRoZSBXRyB0YWtlcyB0aGlzIGRlc2lnbiBkZWNp c2lvbiBub3QgYnkgYWNjaWRlbnQuDQoNCltSZXNwb25zZV0gIFRoaXMgaXMgY29uc2lzdGVudCB3 aXRoIHRoZSBoZWxsbyBtZXNzYWdlLg0KDQpuZXRtb2QgbWF5IHdhbnQgdG8gYWRkcmVzcyB3aGV0 aGVyIG9yIG5vdCB0byBzdXBwb3J0IG11bHRpcGxlDQpuYW1lc3BhY2UgaW4gYSBzaW5nbGUgc2No ZW1hLiAgT3V0Y29tZSBvZiB3aGljaCBzaG91bGQgYmUgcmVmbGVjdGVkDQppbiA0NzQxYmlzLg0K DQoNCnYpIFRoZSBsb2NhdGlvbiBkZXNjcmlwdGlvbiBpcyBub3QgY29uc2lzdGVudCB3aXRoIHRo ZSBzY2hlbWFzIGFuZCB0aGUNCiAgIGV4YW1wbGVzIHNpbmNlIGl0IGlzIGFjdHVhbGx5IGEgbGlz dC4gV2VsbCwgdGhlIFlBTkcgc2F5cyBpdCBpcyBhDQogICBsZWFmIGJ1dCB0aGUgZXhhbXBsZSBz aG93cyB0aGUgZW5jb2Rpbmcgb2YgYSBsZWFmLWxpc3QuIFRoaXMgaXMNCiAgIHNjcmV3ZWQgdXAg KGFuZCBwcm9iYWJseSB0aGUgZXhhbXBsZSBpcyByaWdodCkuDQoNCltSZXNwb25zZV0gVXBkYXRl IGluIHYwNC4NCg0KDQp3KSBUaGUgdW5pb24gb2YgYSBzdHJpbmcgd2l0aCB0aGUgbWFnaWMgdmFs dWUgIk5FVENPTkYiIGFuZCBhIFVSSQ0KICAgbG9va3MgcmVhbGx5IHVnbHkuIEkgc3VnZ2VzdCB0 aGF0IGEgbG9jYXRpb24gbGVhZiBhbHdheXMgY29udGFpbnMgYQ0KICAgVVJJLiAgSWYgeW91IG5l ZWQgYSBtZWNoYW5pc20gdG8gaW5kaWNhdGUgcmV0cmlldmFsIHZpYSBnZXQtc2NoZW1hLA0KICAg Y3JlYXRlIGFub3RoZXIgZW1wdHkgbGVhZiB0aGF0IGlzIG9ubHkgcHJlc2VudCBpZiByZXRyaWV2 YWwgaXMNCiAgIHBvc3NpYmxlIHZpYSBORVRDT05GIGdldC1zY2hlbWEuDQoNCngpIENoYW5nZSB0 aXRsZSBvZiAyLjEuNCB0bzogVGhlIC9uZXRjb25mL3Nlc3Npb25zIFN1YnRyZWUNCg0KW1Jlc3Bv bnNlXSBVcGRhdGUgaW4gdjA0Lg0KDQp5KSBJIGJlbGlldmUgdGhpcyBuZWVkcyBiZXR0ZXIgd29y ZGluZzoNCg0KICAgdXNlcm5hbWUgKHR5cGU6IHhzOnN0cmluZykNCiAgICAgU2Vzc2lvbiBvd25l ci4NCg0KICAgSSBkbyBub3QgdGhpbmsgTkVUQ09ORiBoYXMgYSBub3Rpb24gb2Ygc2Vzc2lvbiBv d25lcnNoaXAuIEkgdGhpbmsgSQ0KICAga25vdyB3aGF0IHlvdSBtZWFuIGJ1dCBpdCBuZWVkcyB0 byBiZSB3cml0dGVuIGRvd24gcHJvcGVybHkgKGFuZCBJDQogICBhbSBub3Qgc3VyZSB0byB3aGF0 IGV4dGVuZCB0aGUgdXNlcm5hbWUgaXMgbm90IHRyYW5zcG9ydCBzcGVjaWZpYykuDQoNCltSZXNw b25zZV0gIFNvbWUgYWRkaXRpb25hbCB0ZXh0IGFkZGVkIHRvIHYwNCB0byBjb3ZlciBpbnRlbnQu DQoNCnopIEkgZmFpbCB0byBzZWUgd2h5IHNvdXJjZUhvc3QgaXMgaW5jbHVkZWQgYXQgYWxsLiBU aGUgSVAgYWRkcmVzcyBvcg0KICAgYSBETlMgbmFtZSBpcyBub3Qgc3VmZmljaWVudCB0byBpZGVu dGlmeSBhIGNsaWVudCBpbiBhbGwgY2FzZXMgYW5kDQogICB0aGUgdmFsdWUgb2YgdGhpcyBkaW1p bmlzaGVzIGdyZWF0bHkgaWYgeW91IGhhdmUgTkFUcyBhbmQgc28gb24uDQogICBCdXQgdGhlIG1v c3QgaW1wb3J0YW50IHByb2JsZW0gSSBoYXZlIGlzIHRoYXQgYW4gSVAgYWRkcmVzcyBpcyBub3QN CiAgIGEgdHJhbnNwb3J0IGVuZHBvaW50Lg0KDQpBKSBDaGFuZ2UgdGl0bGUgb2YgMi4xLjUgdG86 IFRoZSAvbmV0Y29uZi9zdWJzY3JpcHRpb25zIFN1YnRyZWUNCg0KW1Jlc3BvbnNlXSBVcGRhdGUg aW4gdjA0Lg0KDQpCKSBUaGUgZGVzY3JpcHRpb24gb2YgU2VzaW9uSWQgaXMgc2NyZXdlZCB1cDoN Cg0KICAgc2Vzc2lvbklkICh0eXBlOiBTZXNzaW9uSWQpDQogICAgIFVuaXF1ZSBpZGVudGlmaWVy IGZvciB0aGUgbm90aWZpY2F0aW9ucy4NCiAgICAgTVVTVCByZXR1cm4gdGhlIHNhbWUgdmFsdWUg YXMgcmV0dXJuZWQgaW4NCiAgICAgJ3Nlc3Npb25zJyB0byBhbGxvdyBjb3JyZWxhdGlvbi4NCg0K ICAgVGhpcyBpcyBub3QgYW4gaWRlbnRpZmllciBmb3Igbm90aWZpY2F0aW9ucy4gWW91IHByb2Jh Ymx5IHdhbnQNCiAgIHNvbWV0aGluZyBsaWtlIHRoaXM6DQoNCiAgIHNlc3Npb25JZCAodHlwZTog U2Vzc2lvbklkKQ0KICAgICBBIHVuaXF1ZSBpZGVudGlmaWVyIGZvciBhIHNlc3Npb24gY2Fycnlp bmcgbm90aWZpY2F0aW9ucy4NCiAgICAgVGhlIHZhbHVlIG9mIHNlc3Npb25JZCBNVVNUIGJlIHRo ZSBzYW1lIGFzIHRoZSB2YWx1ZSBvZg0KICAgICB0aGUgY29ycmVzcG9uZGluZyAvbmV0Y29uZi9z ZXNzaW9ucy9zZXNzaW9uSWQgdG8gYWxsb3cNCiAgICAgY29ycmVsYXRpb24uDQoNCltSZXNwb25z ZV0gVXBkYXRlIGluIHYwNC4NCg0KDQpDKSBGb3IgbWUsIG1lc3NhZ2VzU2VudCBkb2VzIG5vdCBi ZWxvbmcgaW50byAvbmV0Y29uZi9zdWJzY3JpcHRpb25zDQogICBzaW5jZSBpdCBpcyBhIHN0YXRp c3RpY3MgY291bnRlci4gSSBrbm93LCBpdCBpcyByaWdodCBub3cgdGhlIG9ubHkNCiAgIHNlc3Np b24gc3BlY2lmaWMgY291bnRlciBidXQgdGhhdCBpcyBub3QgYSBnb29kIGFyZ3VtZW50IHRvIGJl DQogICBpbmNvbnNpc3RlbnQgaW4gdGhlIG9yZ2FuaXphdGlvbiBvZiB0aGUgdHJlZS4gT3RoZXIg c2Vzc2lvbg0KICAgY291bnRlcnMgbWlnaHQgYmUgYWRkZWQgaW4gdGhlIGZ1dHVyZS4NCg0KW1Jl c3BvbnNlXSBJZiB3ZSBhZGQgb3RoZXIgc2Vzc2lvbiBzcGVjaWZpYyBzdGF0aXN0aWNzIEkgYXNz dW1lIHdlIA0Kd291bGQgYWRkIHRoZW0gaW4gdGhlIHNlc3Npb24gc3BlY2lmaWMgcG9ydGlvbiBv ZiB0aGUgdHJlZS4NCg0KU28gSSB3b3VsZCBsaWtlIHRvIGxlYXZlIHRoaXMgd2hlcmUgaXQgaXMg YnV0IGhhdmUgcmVuYW1lZCBpdCB0bw0KcmVmbGVjdCB0aGF0IGlzIHRoZSBzZXNzaW9uIHNwZWNp ZmljIHN1YnNldCBvZiB0aGUgdG90YWwgaW4gDQovbmV0Y29uZi9zdGF0aXN0aWNzL291dE5vdGlm aWNhdGlvbnMuICBJIGFsc28gdXBkYXRlZCB0aGUgZGVzY3JpcHRpb24NCm9mIGVhY2ggdG8gcmVm bGVjdCB0aGlzLg0KDQpEKSBDaGFuZ2UgdGl0bGUgb2YgMi4xLjYgdG86IFRoZSAvbmV0Y29uZi9z dGF0aXN0aWNzIFN1YnRyZWUNCg0KW1Jlc3BvbnNlXSBVcGRhdGUgaW4gdjA0Lg0KDQpFKSBBZGQg YSB0cmVlIGxheW91dCBmaWd1cmUgc2ltaWxhciB0byBhbGwgdGhlIG90aGVyIHNlY3Rpb25zLg0K DQpbUmVzcG9uc2VdIFVwZGF0ZSBpbiB2MDQuDQoNCg0KRikgVGhlIGRvY3VtZW50IGFzc3VtZXMg emVyby1iYXNlZCBjb3VudGVycyBhbmQgbm8gcm9sbG92ZXJzIGV2ZXINCiAgIGhhcHBlbjoNCg0K ICAgSWU6ICBjdXJyZW50IHRpbWUgLSBzdGFydFRpbWUgZGVmaW5lcyB0aGUgY29sbGVjdGlvbiBp bnRlcnZhbCBmb3IgdGhlDQogICBtZXRyaWNzIGFsbG93aW5nIGZvciBjYWxjdWxhdGlvbnMgc3Vj aCBhcyBhdmVyYWdlcy4NCg0KICAgU05NUCBwZW9wbGUgbWlnaHQgZmluZCB0aGlzIGFwcHJvYWNo IGJyb2tlbi4NCg0KW1Jlc3BvbnNlXSBXZSBkaWRuJ3Qgc3BlY2lmeS4gIEFja25vd2xlZGdpbmcg aXQncyBub3QgZ29vZCBmb3IgaW50ZXJvcCwNCmNvdW50ZXIgYmVoYXZpb3VyIChlc3AuIHJvbGxv dmVyLCByZXNldCBpbnRlcnZhbHMpIHdpbGwgbGlrZWx5IGJlIHNlcnZlciBzcGVjaWZpYy4NCg0K RykgSSB0cmllZCB0byBkcmF3IGEgY2FzZSBkaWFncmFtIGZvciB0aGUgY291bnRlcnMgYW5kIEkg ZmFpbGVkLiBJDQogICBiZWxpZXZlIHRoZSBjb3VudGVycyBhcmUgbm90IHdlbGwgdGhvdWdodCBv dXQuIFBlcmhhcHMgaXQgaGVscHMNCiAgIHRvIGRyYXcgY2FzZSBkaWFncmFtcyBhbmQgdG8gb3Jn YW5pemUgc3VpdGFibGUgY291bnRlcnMgYWxvbmcNCiAgIHRoZSBuZXRjb25mIHByb3RvY29sIGxh eWVycy4NCg0KW1Jlc3BvbnNlXSAgRGlzY3Vzc2lvbiBmb3IgbWFpbGluZyBsaXN0IGFuZCBJRVRG NzQgcGVyIGNvbW1lbnRzDQpmcm9tIG90aGVycyBsaWtlIEFuZHkgYXMgd2VsbC4NCg0KSCkgQ2hh bmdlIHRpdGxlIG9mIDMuMSB0bzogVGhlIDxnZXQtc2NoZW1hPiBPcGVyYXRpb24NCg0KW1Jlc3Bv bnNlXSBVcGRhdGUgaW4gdjA0Lg0KDQpJKSBDaGFuZ2UgdGhlIGZpcnN0IGlucHV0IGFyZ3VtZW50 IHRvIG5hbWUgKHNlZSBhYm92ZSkgYW5kIHRoZQ0KICAgZGVzY3JpcHRpb24gYXMgZm9sbG93czoN Cg0KICAgbmFtZSAodHlwZTogeHM6c3RyaW5nKTogTmFtZSBvZiB0aGUgc2NoZW1hIHRvIGJlIHJl dHJpZXZlZC4NCiAgIFR5cGljYWxseSB0aGUgbW9kdWxlIG5hbWUgb3IgZmlsZW5hbWUgb2YgdGhl IHNjaGVtYS4NCg0KW1Jlc3BvbnNlXSAgUGVyIHJlc3BvbnNlIGFib3ZlLCBrZWVwaW5nIGlkZW50 aWZpZXIuIFJlbW92ZWQgdGhlDQpyZXBlYXRlZCBkZXNjcmlwdGlvbiBoZXJlLCBpdCdzIGNvdmVy ZWQgZWFybGllci4NCg0KSikgV29yZGluZyBjaGFuZ2U6DQoNCiAgIE9MRDoNCg0KICAgZm9ybWF0 ICh0eXBlOiBTY2hlbWFGb3JtYXQpOiBUaGUgZGF0YSBtb2RlbGluZyBsYW5ndWFnZSBvZiB0aGUg ZmlsZS8NCiAgIG1vZHVsZS4NCg0KICAgTkVXOg0KDQogICBmb3JtYXQgKHR5cGU6IFNjaGVtYUZv cm1hdCk6IFRoZSBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlIG9mIHRoZSBzY2hlbWEuDQoNCltSZXNw b25zZV0gVXBkYXRlIGluIHYwNC4NCg0KSykgV2h5IGlzIHRoZSBzY2hlbWEgaW4gdGhlIGV4YW1w bGUgcmV0dXJuZWQgaW4gQ0RBVEE/Pw0KDQpbUmVzcG9uc2VdICBUZWNobmljYWxseSB0aGlzIGlz IHZhbGlkLCBidXQgaXQncyBiZWVuIHJlbW92ZWQuDQoNCkwpIFJld29yZGluZzoNCg0KICAgT0xE Og0KDQogICBBIE5FVENPTkYgY2xpZW50IHJldHJpZXZlcyB0aGUgbGlzdCBvZiBzdXBwb3J0ZWQg WE1MIFNjaGVtYSBmcm9tIGENCiAgIE5FVENPTkYgc2VydmVyIHVzaW5nIHRoZSA8Z2V0PiBSUEMg cmVxdWVzdC4gVGhlIGxpc3Qgb2YgYXZhaWxhYmxlDQogICBYTUwgU2NoZW1hIGlzIHJldHJpZXZl ZCBieSByZXF1ZXN0aW5nIHRoZSA8c2NoZW1hPiBzdWJ0cmVlIHZpYSBhDQogICA8Z2V0PiBvcGVy YXRpb24uDQoNCiAgIE5FVzoNCg0KICAgQSBORVRDT05GIGNsaWVudCByZXRyaWV2ZXMgdGhlIGxp c3Qgb2Ygc3VwcG9ydGVkIHNjaGVtYSBmcm9tIGENCiAgIE5FVENPTkYgc2VydmVyIHVzaW5nIHRo ZSA8Z2V0PiBvcGVyYXRpb24gYnkgcmV0cmlldmluZyB0aGUNCiAgIC9uZXRjb25mL3NjaGVtYSBz dWJ0cmVlIHZpYSBhIDxnZXQ+IG9wZXJhdGlvbi4NCg0KW1Jlc3BvbnNlXSBVcGRhdGUgaW4gdjA0 Lg0KDQpNKSBFZGl0b3JpYWwgY2hhbmdlczoNCg0KICAgT0xEOg0KICAgDQogICBpZS4NCg0KICAg TkVXOg0KDQogICBpLmUuLA0KDQogICBPTEQ6DQoNCiAgIGh0dHAuaQ0KDQogICBORVc6DQoNCiAg IGh0dHANCg0KICAgT0xEOg0KDQogICA8Z2V0LXNjaGVtYT4gUlBDDQoNCiAgIE5FVzoNCg0KICAg PGdldC1zY2hlbWE+IG9wZXJhdGlvbg0KDQpbUmVzcG9uc2VdIFVwZGF0ZSBpbiB2MDQuDQoNCg0K TikgSSBkaWQgbm90IHJldmlldyB0aGUgWE1MIHNjaGVtYSBkZWZpbml0aW9ucy4gVGhlIHBhdHRl cm4gaW4gdGhlDQogICBpcEFkZHJlc3Mgc2NoZW1hIGRpZmZlciBmcm9tIHRoZSBwYXR0ZXJuIGlu IHlhbmctdHlwZXMsIEkgYW0gbm90DQogICBzdXJlIGF0IHRoZSBtb21lbnQgdGhpcyBpbXBhY3Rz IHNlbWFudGljcy4gU2luY2UgdGhlIHNvdXJjZUhvc3QNCiAgIGRlZmluaXRpb24gc2VlbXMgbm90 IHZlcnkgdXNlZnVsIGluIHRoZSBmaXJzdCBwbGFjZSwgbXkgc3VnZ2VzdGlvbg0KICAgd291bGQg YmUgdG8gbnVrZSBzb3VyY2VIb3N0IGFuZCB3aXRoIGl0IHRoZSB3aG9sZSBYTUwgU2NoZW1hDQog ICBkZWZpbml0aW9uIG9mIGFuIElQIGFkZHJlc3MgdHlwZS4NCg0KW1Jlc3BvbnNlXSBQZXIgbWFp bGluZyBsaXN0IGRpc2N1c3Npb24gd2UgZGVjaWRlZCB0byBrZWVwIHRoaXMgaGVyZSBhdA0KbGVh c3QgdW50aWwgYSBzZXQgb2YgY29tbW9uIE5FVENPTkYgZGF0YXR5cGVzIChYU0QgZGVmcykgaXMg YXZhaWxhYmxlLg0KDQpPKSBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMganVzdCBzYXkgImJl IGNhcmVmdWwiIHdoaWNoIEkgdGhpbmsNCiAgIHdpbGwgbm90IGJlIHN1ZmZpY2llbnQgdG8gcGFz cyB0aGUgc2VjdXJpdHkgYXJlYS4NCg0KW1Jlc3BvbnNlXSBBZ3JlZWQuICBUb3BpYyBmb3IgZGlz Y3Vzc2lvbiBhdCBJRVRGLTc0Lg0KDQpQKSBBY2tub3dsZWRnZW1lbnRzOiBJIHRoaW5rIHRoZSBw aHJhc2UgImVhcmxpZXIgZHJhZnQgb2YgU2NoZW1hIg0KICAgbmVlZHMgdG8gYmUgcmV3cml0dGVu IGFuZCBJIHRoaW5rIGl0IGlzIG1vcmUgYXBwcm9wcmlhdGUgdG8NCiAgIGFja25vd2xlZGdlIHRo ZSBhdXRob3JzIG9mIHRoZSBlYXJsaWVyIHNjaGVtYSBkcmFmdHMgcmF0aGVyIHRoYW4NCiAgIHRo ZSB3aG9sZSBXRy4NCg0KW1Jlc3BvbnNlXSBSZXdvcmRlZC4gIFVwZGF0ZSBpbiB2MDQuDQoNClEp IEFwcGVuZGl4IEEgaW50cm9kdWN0aW9uIHJld3JpdGU6DQoNCiAgIE9MRA0KDQogICBUaGUgZm9s bG93aW5nIFlBTkcgbW9kdWxlIGlzIGluY2x1ZGVkIGFzIGEgcmVmZXJlbmNlIG9ubHkuICBJdCBp cw0KICAgYmFzZWQgb24gWUFORyBkZWZpbml0aW9uIGF0IHRoZSB0aW1lIG9mIHB1Ymxpc2hpbmcg YW5kIGlzIHN1YmplY3QgdG8NCiAgIGNoYW5nZSBhcyBhIHJlc3VsdCBvZiBuZXRtb2Qgd29yayB1 bmRlcndheSB0byByZWZpbmUgWUFORy4gIEZ1cnRoZXINCiAgIGRldGFpbHMgb24gWUFORyBhbmQg dXBkYXRlZCBub24tbm9ybWF0aXZlIHJlZmVyZW5jZSB0byB0aGlzIG1vZGVsIGFyZQ0KICAgYXZh aWxhYmxlIGF0Og0KICAgaHR0cDovL3d3dy55YW5nLWNlbnRyYWwub3JnL3R3aWtpL2Jpbi92aWV3 L01haW4vWWFuZ0V4YW1wbGVzLg0KDQogICBORVcNCg0KICAgVGhlIGZvbGxvd2luZyBZQU5HIG1v ZHVsZSBpcyBpbmNsdWRlZCBhcyBhIHJlZmVyZW5jZSBvbmx5LiAgSXQgaXMNCiAgIGJhc2VkIG9u IFlBTkcgc3BlY2lmaWNhdGlvbiBhdCB0aGUgdGltZSBvZiBwdWJsaXNoaW5nIGFuZCBpcyBzdWJq ZWN0IHRvDQogICBjaGFuZ2UgYXMgYSByZXN1bHQgb2YgTkVUTU9EIHdvcmsgdW5kZXJ3YXkgdG8g cmVmaW5lIFlBTkcuDQoNCiAgIEkgc3VnZ2VzdCB0byByZW1vdmUgdGhlIG9ubGluZSByZWZlcmVu Y2Ugc2luY2UgaXQgaXMgaGFyZCB0bw0KICAgZ3VhcmFudGVlIHRoYXQgdGhpcyBpcyBrZXB0IHVw ZGF0ZWQuDQoNCltSZXNwb25zZV0gIFVwZGF0ZSBpbiB2MDQuDQoNCg0KUikgWWFuZyBtZXRhIGlu Zm9ybWF0aW9uIHNob3VsZCBpbiBzcHJpcml0IGZvbGxvdyBSRkMgNDE4MS4gDQoNCltSZXNwb25z ZV0gIFVwZGF0ZSBpbiB2MDQuDQoNClMpIEkgdGhpbmsgaXQgaXMgdXNlZnVsIHRvIHdyaXRlIHJl ZmVyZW5jZSBzdGF0ZW1lbnRzIGluIHRoZSBmb2xsb3dpbmcNCiAgIGZvcm1hdDoNCg0KICAgICAg cmVmZXJlbmNlICJSRkMgNDc0MTogTkVUQ09ORiBDb25maWd1cmF0aW9uIFByb3RvY29sIg0KDQog ICBOb3QgZXZlcnkgcmVhZGVyIGtub3dzIFJGQyBudW1iZXJzIGJ5IGhlYXJ0Lg0KDQpbUmVzcG9u c2VdIFVwZGF0ZSBpbiB2MDQuDQoNClQpIEkgYW0gY29uY2VybmVkIGFib3V0IHRoZSBleHRlbnNp YmlsaXR5IG9mIHNvbWUgb2YgdGhlIHR5cGUNCiAgIGRlZmluaXRpb25zLiBTb21lIHNob3VsZCBw cm9iYWJseSBiZSBtYWludGFpbmVkIGJ5IElBTkEuICBBbmR5DQogICByZWNlbnRseSBwdWJsaXNo ZWQgYSBZQU5HIG1vZHVsZSBmb3IgTkVUQ09ORiBhbmQgaW4gdGhlIGlkZWFsDQogICB3b3JsZCwg dGhpcyBkb2N1bWVudCB3b3VsZCBpbXBvcnQgc29tZSBvZiB0aGUgbmVlZGVkIHR5cGUgZnJvbSAN CiAgIHRoZSBZQU5HIG1vZHVsZSBmb3IgTkVUQ09ORi4NCg0KW1Jlc3BvbnNlXSBOb3RlZCBidXQg dGhpbmsgd2UgYWdyZWVkIGZvciBub3cgaW4gdGhlIGFic2VuY2Ugb2YgYWdyZWVkDQpORVRDT05G IHdpZGUgZGF0YXR5cGVzIHdlIHdvdWxkIGdvIHdpdGggdGhlc2UuDQoNClUpIFNTTCBzaG91bGQg YmUgVExTDQoNCltSZXNwb25zZV0gVXBkYXRlIGluIHYwNC4NCg0KVikgV2hhdCBpcyBXZWJVST8g SG93IGRvZXMgYSBORVRDT05GIHNlcnZlciBkZXRlcm1pbmUgd2hldGhlciBhIGNsaWVudA0KICAg aXMgYSBDTEksIE5FVENPTkYsIG9yIFdlYlVJPz8NCg0KW1Jlc3BvbnNlXSBEaXNjdXNzaW9uIHRv IG1haWxpbmcgbGlzdC4gIFdoYXQgaXMgdGhlIGNvbW1vbiBzZXQgdnMuDQp3aGF0IHdlIHNob3Vs ZCBsZWF2ZSBhcyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyBhdWdtZW50cz8gIElmIHdlIHJlbW92 ZQ0KcHJvdG9jb2wgd2Ugc2hvdWxkIHVwZGF0ZSB0cmFuc3BvcnR0eXBlIHRvIG1hcCB0byB0aGUg c3VwcG9ydGVkDQpSRkNzIChlLmcuIFNTSCwgVExTKT8NCg0KVykgVGhlcmUgYXJlIG1hbnkgc3Rh dGVtZW50cyB3aXRob3V0IGRlc2NyaXB0aW9ucyBhbmQgSSBiZWxpZXZlIGl0DQogICB3b3VsZCBi ZSB1c2VmdWwgdG8gcmVwZWF0IHRleHQgZnJvbSBzZWN0aW9uIDIgaW4gdGhlIGRhdGEgbW9kZWwg c28NCiAgIHRoYXQgaXQgYmVjb21lcyBzZWxmY29udGFpbmVkLg0KDQpbUmVzcG9uc2VdIFdlIGNh biBlbWJlZCBzZWMgMiBkZXNjcmlwdGlvbnMgaW50byB0aGUgbW9kZWwgb25jZSBXR0xDDQpjb21w bGV0ZXMgYW5kIHRoZSB0ZXh0IGlzIHN0YXRpYy4NCg0KWCkgSSBwcmVmZXIgYSBuYW1pbmcgc3R5 bGUgd2hlcmUgc2hvcnQgbmFtZXMgdGhhdCBhcmUgbWVhbmluZ2Z1bCBpbg0KICAgdGhlIGNvbnRl eHQgb2YgYW4gaW5zdGFuY2UgZG9jdW1lbnQgYXJlIHVzZWQuIEZvciBleGFtcGxlLCBJIGxpa2UN Cg0KICAgPGxvY2tzPg0KICAgICA8Z2xvYmFsPg0KICAgICAgICA8c2Vzc2lvbklkPjQyPC9zZXNz aW9uSWQ+DQoJPHRpbWU+Li48L3RpbWU+DQogICAgIDwvZ2xvYmFsPg0KICAgPC9sb2Nrcz4NCg0K ICAgPGxvY2tzPg0KICAgICA8cGFydGlhbD4NCiAgICAgICAgPGxvY2staWQ+MTI8L2xvY2staWQ+ DQoJPHNlc3Npb25JZD40Mjwvc2Vzc2lvbklkPg0KCTx0aW1lPi4uPC90aW1lPg0KCTxzZWxlY3Q+ L25ldGNvbmY8L3NlbGVjdD4NCgk8bm9kZT4uLjwvbm9kZT4NCgk8bm9kZT4uLjwvbm9kZT4NCgk8 bm9kZT4uLjwvbm9kZT4NCiAgICAgPC9wYXJ0aWE+DQogICA8L2xvY2tzPg0KDQogICBvdmVyIHdo YXQgdGhlIGRvY3VtZW50IGFjdHVhbGx5IHByb2R1Y2VzLg0KDQpbUmVzcG9uc2VdICBOb3RlZC4g IFByZWZlciB0byBzdGljayB3aXRoIHRoZSBuYW1pbmcgYXMgaXMgYXQgdGhpcw0Kc3RhZ2UgdGhv dWdoLg0KDQpZKSBBIGRlc2NyaXB0aW9uIG9mIGxvY2tJZCBpcyBuZWVkZWQgdG8gbWFrZSBpdCBj bGVhciB0aGF0IGl0IGlzIHRoZQ0KICAgdmFsdWUgcmV0dXJuZWQgYnkgPHBhcnRpYWwtbG9jaz4g YW5kIHRoZSBwYXJ0aWFsIGxvY2tpbmcgZHJhZnQgbXVzdA0KICAgYmUgY2xhcmlmaWVkIHRoYXQg dGhlIGxvY2sgaWQgaXMgZ2xvYmFsbHkgdW5pcXVlIHdpdGhpbiBhIE5FVENPTkYNCiAgIHNlcnZl ciBzbyB0aGF0IGl0IGNhbiBhY3R1YWxseSBzZXJ2ZSBhcyBhIGtleSBoZXJlIHdpdGhvdXQgaGF2 aW5nDQogICB0byBzY29wZSBpdCBieSB0aGUgc2Vzc2lvbklkLg0KDQpbUmVzcG9uc2VdICBVcGRh dGVkIHRleHQsIFhTRCBhbmQgWUFORyB0byBiZSBjbGVhcmVyLg0KQ29tbWVudCBvbiB1bmlxdWVu ZXNzIHNlbnQgdG8gbWFpbGluZyBsaXN0IGZvciBwYXJ0aWFsIGxvY2tpbmcgZHJhZnQNCmNvbW1l bnQuDQoNClopIEkgc2VlIGFub3RoZXIgY2FzZSB3aGVyZSBhIGNvbW1vbiB4cGF0aCBkYXRhIHR5 cGUgd291bGQgbWFrZSBzZW5zZS4NCg0KW1Jlc3BvbnNlXSAgVXBkYXRlIGluIHYwNC4NCg0KKykg SW4gdGhlIHN0YXRpc3RpY3Mgc2VjdGlvbiwgbGFuZ3VhZ2UgbmVlZHMgdG8gYmUgbW9yZSBwcmVj aXNlLiBXaGF0DQogICBpcyBhICJjb3JyZWN0bHkgc3RhcnRlZCBzZXNzaW9uIj8gV2hhdCBhcmUg InNlc3Npb25zIHN0YXJ0ZWQgdG93YXJkcw0KICAgdGhlIE5FVENPTkYgcGVlciI/IA0KDQpbUmVz cG9uc2VdICBEZXNjcmlwdGlvbnMgaGF2ZSBiZWVuIHVwZGF0ZWQuICBVcGRhdGUgaW4gdjA0Lg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KDQpBbmR5IENvbW1lbnRzDQotLS0tLS0tLS0tLS0tDQoNCltHZW5lcmFs IFJlc3BvbnNlXSAgVGhlIHJlc3BvbnNlcyBiZWxvdyBvbiB0aGUgc3BlY2lmaWMgY291bnRlcnMg d2lsbA0KYmUgZGlzY3Vzc2VkIGZ1cnRoZXIgYXQgSUVURjc0IGFuZCBvbiB0aGUgbWFpbGluZyBs aXN0LiAgTG9va3MgbGlrZQ0Kd2Ugc2hvdWxkIGJlIGdldHRpbmcgZ3JvdXAgY29uY2VuY3VzIG9u IHdoZXRoZXIgZWFjaCBjb3VudGVyIHNob3VsZA0KYmUgaW5jbHVkZWQgYW5kIHdoYXQgdGhlIGRl c2NyaXB0aW9uL2JlaGF2aW91ciBvZiBlYWNoIGlzIGludGVuZGVkIHRvDQpiZS4gIFN1YmplY3Qg dG8gZGlzY3Vzc2lvbiBhdCBJRVRGNzQgdGhlc2UgdXBkYXRlcyBjYW4gYmUgbWFkZSBpbiB2MDUu DQoNCg0KMSkgYnVnOiB0b3Agb2YgcGcgMTYsIGV4YW1wbGUNCiAgPHJwYz4gc3RhcnQtdGFnIHBh aXJlZCB3aXRoIDwvcnBjLXJlcGx5PiBlbmQtdGFnDQoNCltSZXNwb25zZV0gIFVwZGF0ZSBpbiB2 MDQuDQoNCg0KICAyKSBuZXRjb25mIGNvbnRhaW5lcg0KICAgICBXaGF0IGFib3V0IHJlbmFtaW5n IGl0IHRvICduZXRjb25mLXN0YXRlJz8NCiAgICAgSU1PIHRoaXMgc2V0cyBhIGNsZWFyIGFuZCB3 b3JrYWJsZSBwcmVjZWRlbnQuDQogICAgIFVzZSAxIHRvcC1sZXZlbCBlbGVtZW50IHdpdGggdGhl IHNhbWUgbmFtZSBhcw0KICAgICB0aGUgWUFORyBtb2R1bGUuICBJdCBhbHNvIHNvbHZlcyB0aGUg cHJvYmxlbSBvZg0KICAgICBhIHJlYWQtb25seSB2cy4gcmVhZC13cml0ZSAvbmV0Y29uZiBjb250 YWluZXIuDQoNCltSZXNwb25zZV0gUmVuYW1lZCB0byAvaWV0Zi1uZXRjb25mLXN0YXRlLy4NCg0K DQogIDMpIDxjYXBhYmlsaXRpZXM+DQogICAgIFNob3VsZCB0aGlzIGVsZW1lbnQgYmUgdGhlIGV4 YWN0IGNhcGFiaWxpdGllcyBnaXZlbg0KICAgICBpbiB0aGUgPGhlbGxvPiBvciBzaG91bGQgdGhl IG5ldGNvbmYgbmFtZXNwYWNlIGJlDQogICAgIGNoYW5nZWQgdG8gdGhlIG5ldGNvbmYtc3RhdGUg bmFtZXNwYWNlIChhcyB0aGUgZHJhZnQNCiAgICAgZGVmaW5lcyBub3cpPyBJTU8gaXQgaXMgY29u ZnVzaW5nIGFuZCBjb2RlIHdoaWNoDQogICAgIHVuZGVyc3RhbmRzIHRoZSA8aGVsbG8+IGNhbm5v dCBiZSByZXVzZWQgdG8gaGFuZGxlDQogICAgIHRoZSBuZXRjb25mLXN0YXRlIGRhdGEtbW9kZWwu DQoNCltSZXNwb25zZV0gIFRvcGljIGZvciBkaXNjdXNzaW9uIGF0IElFVEY3NC4NCg0KICA0KSBz dGF0aWMgPGNvbmZpZ3VyYXRpb24+IGVsZW1lbnRzDQogICAgIEkgYXNzdW1lIHRoZXJlIHdpbGwg YmUgYWx3YXlzIGJlIGFuIGVudHJ5IGZvciBlYWNoIG9mIHRoZQ0KICAgICAzIGRhdGFiYXNlcyBz dXBwb3J0ZWQgYnkgdGhlIGFnZW50LiBJLmUuLCBhdCBsZWFzdCBvbmUNCiAgICAgZW50cnkgZm9y IDxydW5uaW5nPi4gIEFkZGluZyBhbmQgZGVsZXRpbmcgdGhlc2UgYmFzZWQNCiAgICAgb24gdGhl IGN1cnJlbnQgc3RhdGUgb2YgdGhlIGxvY2tzIHdvdWxkIGNvbXBsaWNhdGUgdGhpbmdzLg0KDQpb UmVzcG9uc2VdIENvcnJlY3QuICBUaGVzZSBjYW4gYXBwZWFyIGV2ZW4gbm8gbG9ja3MgYXJlIHBy ZXNlbnQuDQoNCiAgNSkgZW1wdHkgPGxvY2tzLz4gT0s/DQogICAgIEl0IHNlZW1zIHVzZWZ1bCBh bmQgY29udmVuaWVudCB0byBiZSBhYmxlIHRvIHJldHVybg0KICAgICBhbiBlbXB0eSBsb2NrcyBj b250YWluZXIsIGVzcGVjaWFsbHkgaWYgdGhlcmUgYXJlDQogICAgIGxvdHMgb2YgcGFydGlhbCBs b2NrcyBvciBhIGJpZyBkYXRhYmFzZS4NCiAgICAgQW4gaW1wbGVtZW50YXRpb24gc2hvdWxkIG5v dCBuZWVkIHRvIHNlYXJjaCBvdXQgYWxsDQogICAgIHRoZSBwYXJ0aWFsIGxvY2tzIHR3aWNlICh3 LyBhZGRlZCByYWNlIGNvbmRpdGlvbikgdG8NCiAgICAgbWFrZSBzdXJlIHRoZXJlIHJlYWxseSBp cyBhdCBsZWFzdCAxIHBhcnRpYWwgbG9jayB0byByZXBvcnQuDQoNCltSZXNwb25zZV0gQXJlIHlv dSBzdWdnZXN0aW5nIHRoZSBsb2NrcyBiZSByZXR1cm5lZCBlbXB0eSBldmVuDQp3aGVuIHRoZXJl IGFyZSBsb2Nrcz8gIEllOiBiYXNlZCBvbiBzb21lIG1heCBudW1iZXIgb2YgbG9ja3MNCmFmdGVy IHdoaWNoIHRoZSBzZXJ2ZXIgd291bGQgc3VwcHJlc3MgcmVwb3J0aW5nIHRoZW0/DQoNCklmIHNv IHdlIHdvdWxkIG5lZWQgYW4gaW5kaWNhdG9yIHRoYXQgdGhlcmUgYXJlIGxvY2tzIGRlc3BpdGUN CnRoZSBlbXB0eSBzZXQuICBJJ2QgcHJlZmVyIHRvIGF2b2lkIHRoaXMgZm9yIG5vdy4NCg0KDQog IDYpIHNlc3Npb24gZHJvcHMNCiAgICAgYSkgVGhlIGluQmFkSGVsbG9zIG9iamVjdCBzaG91bGQg bWVudGlvbiB0aGF0IHNlc3Npb25zDQogICAgICAgIGRyb3BwZWQgYmVjYXVzZSBhIDxoZWxsbz4g d2FzIG5ldmVyIHJlY2VpdmVkIGFyZSBhbHNvDQogICAgICAgIGluY2x1ZGVkIGluIHRoaXMgY291 bnRlci4NCiAgICAgYikgc2hvdWxkIHRoZXJlIGJlIGFuICdhYm5vcm1hbFRlcm1pbmF0aW9ucycg Y291bnRlcg0KICAgICAgICB0byBjb3VudCBhbnkgc2Vzc2lvbnMgdGVybWluYXRlZCBmb3IgYW4g YWJub3JtYWwNCiAgICAgICAgcmVhc29uIChpLmUuLCBvdGhlciB0aGFuIGNsb3NlLXNlc3Npb24s IGtpbGwtc2Vzc2lvbiwNCiAgICAgICAgYWxyZWFkeSBjb3VudGVkIGluIGluQmFkSGVsbG9zKQ0K ICAgICBjKSBzaG91bGQgdHJhbnNwb3J0IGNvbm5lY3Rpb24gZHJvcHMgYnkgdGhlIG1hbmFnZXIg YmUNCiAgICAgICAgY291bnRlZCBpbiBhbnkgd2F5Pw0KDQpbUmVzcG9uc2VdIE9wZW4gaXNzdWUg b24gY291bnRlcnMgZm9yIElFVEY3NC4NCg0KICA3KSB1c2FnZSBzdGF0aXN0aWNzDQogICAgIFRo ZXJlIGlzIG5vIHRvdGFsIGJ5dGVzIGNvdW50ZXJzLCBvbmx5IG1lc3NhZ2UgY291bnRlcnMuDQog ICAgIElzIHRoaXMgb24gcHVycG9zZT8gIFdlcmUgdXNhZ2Ugc3RhdGlzdGljcyByZWplY3RlZD8N Cg0KW1Jlc3BvbnNlXSAgTm8uICBJcyBpdCBmYWlyIHRvIGFzc3VtZSB0aGF0IHRoZSBwbGF0Zm9y bSBvbiB3aGljaA0KdGhlIE5FVENPTkYgc2VydmVyIGlzIGhvc3RlZCB3b3VsZCBhbHJlYWR5IGJl IGNvbGxlY3Rpbmcgc3VjaA0Kc3RhdHM/ICAoaWUuIHBhY2tldCBjb3VudGVycyBmb3Igc3BlY2lm aWMgcG9ydHMpDQoNCiAgOCkgcGVyLXNlc3Npb24gc3RhdGlzdGljcw0KICAgICBUaGVyZSBhcmUg bm9uZS4gIElzIGl0IHdvcnRoIGl0IHRvIGFkZCB0aGVtLCBwZXJoYXBzDQogICAgIGFzIGFuIGFk ZGl0aW9uYWwgY2FwYWJpbGl0eT8gIFBlcmhhcHMgbW9yZSB0aGFuIG9uZSBzZXNzaW9uDQogICAg IGlzIGFjdGl2ZSBhdCB0aGUgc2FtZSB0aW1lLiAgVGhlIGdsb2JhbCBjb3VudGVycw0KICAgICB3 aWxsIG5vdCBnaXZlIGEgY2xlYW4gdmlldyBvZiB0aGUgcHJvYmxlbSwgYW5kIGJlIHVzZWxlc3Mu DQoNCltSZXNwb25zZV0gVGhlIHN1YnNjcmlwdGlvbiBlbGVtZW50IGNvbnRhaW5zICdvdXROb3Rp ZmljYXRpb25zJw0Kd2hpY2ggYXJlIHBlciBzZXNzaW9uLiAgVGhpcyB3YXMgdG8gY29tcGxlbWVu dCB0aGUgc3Vic2NyaXB0aW9uDQp3b3JrIGFscmVhZHkgZG9uZSBtb3JlIHNvIHRoYW4gdG8gYWRk IHBlciBzZXNzaW9uIHN0YXRzIGF0IHRoaXMNCnN0YWdlLg0KDQoNCiAgOSkgZ2V0LXNjaGVtYSBS UEMgb3BlcmF0aW9uDQogICAgIFRoZSBwb3NpdGl2ZSBhbmQgbmVnYXRpdmUgcmVzcG9uc2UgcGFy dHMgb2YgdGhlIHRlbXBsYXRlIGFyZQ0KICAgICBtaXNzaW5nLiAgV2hhdCBlcnJvcnMgYXJlIHRv IGJlIGV4cGVjdGVkPyAgSXMgaXQgb3BlcmF0aW9uLWZhaWxlZA0KICAgICBpZiB0aGUgbW9kdWxl IG5hbWUvcmV2aXNpb24gYXJlIG5vdCBmb3VuZD8gIFdoYXQgaWYgdGhlIHJlcXVlc3RlZA0KICAg ICBmb3JtYXQgaXMgbm90IGF2YWlsYWJsZT8NCg0KW1Jlc3BvbnNlXSBBZGRlZC4gIE9wZXJhdGlv bi1mYWlsZWQgaXMgcmV0dXJuZWQgaW4gYWxsIGNhc2VzLiAgSWU6IGlmDQp0aGUgY29tYmluYXRp b24gb2YgaWRlbnRpZmllci92ZXJzaW9uL2Zvcm1hdCBpcyBub3QgZm91bmQuDQoNCg0KMTApIFVz ZXIgbmFtZQ0KICAgICBUaGlzIGZpZWxkIGlzIGZhaXJseSB2YWd1ZSwgd2hpY2ggbWF0Y2hlcyB0 aGUgTkVUQ09ORiBhcmNoaXRlY3R1cmUNCiAgICAgd3J0LyB0aGlzIHN1YmplY3QuICBXaGF0IGlz IHRoZSAnb3duZXInPyAgU2hvdWxkIHRoZXJlIGJlDQogICAgIHNvbWUgbW9yZSB0ZXh0IGhlcmU/ ICBUaGlzIGlzIGdvaW5nIHRvIHNob3cgdXAgbGF0ZXINCiAgICAgZm9yIGFjY2VzcyBjb250cm9s IHdvcmssIHNvIG1pZ2h0IGFzIHdlbGwgZ2V0IGl0IGNvcnJlY3Qgbm93Lg0KDQpbUmVzcG9uc2Vd IEFncmVlZCBidXQgSSB0aGluayBldmVuIHdoZW4vaWYgYWNjZXNzIGNvbnRyb2wgZGVmaW5lcw0K dGhpcyBpdCB3aWxsIGxpa2VseSBiZSBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyAoc2luY2UgaXQn cyBzdWJqZWN0IHRvDQp0aGUgc2VjdXJpdHkgcmVxcyBvZiB0aGUgdHJhbnNwb3J0IG1vcmUgc28g dGhhbiB0aGUgcHJvdG9jb2wpLg0KDQpTaW1pbGlhciB0byA0NzQxIEkndmUgYWRkZWQgc29tZSBj b25zaWRlcmF0aW9uIHRleHQgYnV0IG5vdCANCm1hbmRhdGVkIGFueSBzcGVjaWZpYyBkYXRhIGhl cmUuDQoNCg0KMTEpIERvY3VtZW50YXRpb24gc3R5bGUNCiAgICAgSSByZWFsbHkgbGlrZSB0aGUg J2luZm8tbW9kZWwnIHN0eWxlIG9mIGRvY3VtZW50YXRpb24gbXVjaA0KICAgICBiZXR0ZXIgdGhh biB0aGUgTUlCIHN0eWxlLiAgSXQgaXMgZWFzeSB0byByZWFkIGFuZCBlYXN5IHRvDQogICAgIGZp bmQgc3R1ZmYuICBJIGhvcGUgYWxsIE5FVENPTkYgZGF0YSBtb2RlbCBkcmFmdHMgZm9sbG93IHRo aXMgc3R5bGUuDQoNCltSZXNwb25zZV0gQWdyZWVkLg0KDQoxMikgVGhlIGV4YW1wbGUgb24gcGcg MTAgc2hvd3MgdGhlIHNjaGVtYSBiZWluZyByZXR1cm5lZA0KICAgIGluIGEgQ0RBVEEgc2VjdGlv bi4gIEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBuZWVkZWQsDQogICAgYmVjYXVzZSB0aGUgPGRhdGE+ IGVsZW1lbnQgYXMgdHlwZSAnYW55Jy4gIFdoYXRldmVyDQogICAgZm9ybWF0IGlzIGluc2VydGVk IHdpbGwgYmUgdmFsaWQgWE1MIChhbHRob3VnaCBZQU5HDQogICAgZmlsZXMgd2lsbCBoYXZlIHNv bWUgY2hhcnMgY29udmVydGVkIHRvIGNoYXJhY3RlciBlbnRpdGllcykuDQogICAgSW5zZXJ0aW5n IGEgdmFsaWQgWFNEIHNob3VsZCBiZSBPSyB3aXRob3V0IENEQVRBLCByaWdodD8NCg0KW1Jlc3Bv bnNlXSAgVXBkYXRlIGluIHYwNC4NCiANCjEzKSBUaGUga2V5LXN0bXQgZm9yIHRoZSBzY2hlbWEg bGlzdCBpbiB0aGUgWUFORyBtb2R1bGUNCiAgICBzZWVtcyB0byBiZSBpbiB0aGUgd3Jvbmcgb3Jk ZXIuICBUaGUgbGVhZiBvcmRlciBtYXRjaGVzDQogICAgdGhlIFhTRCAoaWRlbnRpZmllciwgdmVy c2lvbiwgZm9ybWF0KSBidXQgdGhlIGtleQ0KICAgIGlzIG9yZGVyZWQgImlkZW50aWZpZXIgZm9y bWF0IHZlcnNpb24iPyAgVGhpcyBpcyBhIGJ1ZywNCiAgICByaWdodD8gIFRoZSBrZXkgb3JkZXIg c2hvdWxkIG1hdGNoIHRoZSBsZWFmIG9yZGVyLg0KDQpbUmVzcG9uc2VdICBVcGRhdGUgaW4gdjA0 Lg0KDQoxNCkgVGhlIGNvdW50ZXIgY29uZGl0aW9ucyBhcmUgc3BlY2lmaWMgLS0gdGhhdCdzIGdv b2QsDQogICAgIGV4Y2VwdCBpbkJhZFJwY3MuICBUaGUgd29yZHMgJ3BhcnNlZCBjb3JyZWN0bHkn DQogICAgIGltcGxpZXMgd2VsbC1mb3JtZWQgWE1MLiAgSWYgc28sIHRoZW4gYW5vdGhlcg0KICAg ICBjb3VudGVyIHNob3VsZCBiZSBhZGRlZCBmb3IgaW52YWxpZCBYTUwgbWVzc2FnZXMgcmVjZWl2 ZWQuDQoNCltSc2Vwb25zZV0gVGhlcmUgaXMgb25lIC0gaW5YTUxQYXJzZUVycm9ycy4NCg0KMTUp IElzIGluUnBjcyA9PSBvdXRScGNSZXBsaWVzIGFsd2F5cyB0cnVlPw0KICAgICBJZiBub3QsIHdo eSBub3Q/ICAoSWYgeWVzLCB3aHkgZG8gYm90aCBjb3VudGVycyBleGlzdD8pDQoNCltSZXNwb25z ZV0gR29vZCBxdWVzdGlvbi4uLiBJIHRoaW5rIHRoYXQgaWYgdGhlc2UgY291bnRlcnMgZG8NCm5v dCBoYXZlIHRoZSBzYW1lIHZhbHVlLCB0aGVuIHRoYXQgaW5kaWNhdGVzIHNvbWUgYnVnIGluIHRo ZQ0KYWdlbnQgd2hpY2ggbWFkZSBpdCBjbG9zZSB0aGUgc2Vzc2lvbiBvciBzb21ldGhpbmcuDQoN ClNob3VsZCBvbmUgb2YgdGhlbSBiZSByZW1vdmVkPyAgKG5lZWRzIGZ1cnRoZXIgZGlzdWNzc2lv bg0KYXMgcGFydCBvZiBvcGVuIGNvdW50ZXIgaXNzdWVzKQ0KDQoNCjE2KSBJcyBpbkJhZFJwY3Mg PT0gb3V0UnBjRXJyb3JzIGFsd2F5cyB0cnVlPw0KICAgICBJZiBub3QsIHdoeSBub3Q/ICAoSWYg eWVzLCB3aHkgZG8gYm90aCBjb3VudGVycyBleGlzdD8pDQoNCltSZXNwb25zZV0gSWYgc2VydmVy cyByZWNlaXZlcyBhIG5vbiB3ZWxsLWZvcm1lZCBYTUwgbWVzc2FnZSwNCmJ1dCBnZXRzIHRoZSA8 cnBjPiBlbGVtZW50LCBzaG91bGQgdGhlIHJlcGx5IGJlIGFuIDxycGMtZXJyb3I+Pw0KSWYgc28s IHRoZW4gdGhlc2UgY291bnRlcnMgZG8gbm90IGhhdmUgdG8gYmUgdGhlIHNhbWUuDQoNCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KQmFsYXpzIENvbW1lbnRzDQotLS0tLS0tLS0tLS0tLS0N Cg0KMSkgIEdlbmVyYWwpIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyAyIGNhcGFiaWxpdGllcywgYnV0 IGRvZXMgbm90IGZvbGxvdyB0aGUgDQpjYXBhYmlsaXR5IHRlbXBsYXRlLiANClNvbWUgcG9pbnRz IHdoaWNoIEkgd291bGQgbGlrZSB0byBzZWUgZnJvbSB0aGF0IHRlbXBsYXRlOg0KLSB0aGUgY2Fw YWJpbGl0eSBVUk5zIHNob3VsZCBiZSBzcGVjaWZpZWQgaW4gdGhlIG1haW4gcGFydCBvZiB0aGUg ZG9jdW1lbnQgbm90IA0KanVzdCBpbiB0aGUgSUFOQSBjb25zaWRlcmF0aW9ucy4gSXQgc2hvdWxk IGJlIHZlcnkgY2xlYXJseSBzdGF0ZWQgd2hhdCB0aGUgdHdvIA0KY2FwYWJpbGl0aWVzIG1lYW46 IGUuZy4gdGhhdCB0aGUgdmFsdWUgTkVUQ09ORiBjYW4gYmUgdXNlZCBmb3Igc2NoZW1hIGxvY2F0 aW9uIA0KY2FuIG9ubHkgYmUgdXNlZCBpZiB0aGUgc2NoZW1hLXJldHJpZXZhbCBjYXBhYmlsaXR5 IGlzIHVzZWQsIC4uLg0KLSB0aGF0IHRoZXNlIGFwYWJpbGl0aWVzIGhhdmUgbm8gaW1wYWN0IG9u IGV4aXN0aW5nIGNhcGFiaWxpdGllcyBvciBvcGVyYXRpb25zDQoNCltSZXNwb25zZV0gIEFkZGlp dG9uYWwgdGV4dCBhZGRlZCB0byBTZWMgMiBpbnRyby4NCg0KMikgSSBhZ3JlZSB3aXRoIEp1cmdl biB0aGF0IDQ3NDFiaXMgTVVTVCBjbGVhcmx5IHN0YXRlIHdoZXRoZXIgbmV3IGNhcGFiaWxpdGll cyANCmNhbiBiZSBhZGRlZCBvciByZW1vdmVkIGR1cmluZyB0aGUgc2Vzc2lvbi4gRWFybGllciBB bmR5IHNhZCB0aGF0IHJlbW92aW5nIGEgDQpjYXBhYmlsaXR5IHdvdWxkIGJyZWFrIHRoZSBjb250 cmFjdCBzcGVjaWZpZWQgaW4gdGhlIGhlbGxvIG1lc3NhZ2UuDQoNCltSZXNwb25zZV0gIEFncmVl ZC4gIFNlZSBlYXJsaWVyIHJlc3BvbnNlIHRvIEp1ZXJnZW4ncy4gIE5lZWRzIGZ1cnRoZXINCmRp c2N1c3Npb24gYW5kIG11c3QgYmUgYWRkcmVzc2VkIGluIHRoZSA0NzQxYmlzLg0KDQozKSAyLjEu MikNCk9MRDoNCg0KICAgICAgLi4uICBUaGUgbG9ja2VkTm9kZXMgaXMgdGhlIGxpc3Qgb2YNCiAg ICAgIGFjdHVhbCBub2RlcyB3aGljaCB3ZXJlIGxvY2tlZCBhdCB0aGUgdGhlIHNlbGVjdGlvbiB3 YXMgZXZhbHVhdGVkLg0KICAgICAgVGhpcyBpcyBwcm92aWRlZCBmb3IgY29tcGxldGVuZXNzIG5v dGluZyB0aGF0IHRoZSBsaXN0IG9mIG5vZGVzDQogICAgICByZXR1cm5lZCBieSB0aGUgc2VsZWN0 aW9uIG1heSBkaWZmZXIgb3ZlciB0aW1lLg0KDQogICAgICBBZGRpdGlvbmFsbHkgcGFydGlhbCBs b2NrIGl0ZW1zIHdpbGwgY29udGFpbiBib3RoIHRoZSBzZWxlY3Rpb24NCiAgICAgIGFuZCB0aGUg bGlzdCBvZiBsb2NrZWROb2Rlcy4gIFRoZSBzZWxlY3Rpb24gaXMgdGhlIHhwYXRoIGV4cHJlc3Np b24NCiAgICAgIHdoaWNoIHdhcyB1c2VkIHRvIGV2YWx1YXRlIHRoZSBsaXN0IG9mIG5vZGVzIHRv IGxvY2suDQoNClRoZSBsb2NrZWROb2RlcyBsaXN0IGlzIGF2YWlsYWJsZSBvbmx5IGZvciBwYXJ0 aWFsLWxvY2tzLiAgVGhlIGxpc3QgaXMgdGhlIA0KcHJpbWFyeSB3YXkgb2YgbWFpbnRhaW5pbmcg YSBsb2NrIGl0IGlzIG5vdCBqdXN0IGZvciBjb21wbGV0ZW5lc3MuDQoNCk5FVzoNCg0KLi4uIEZv ciBwYXJ0aWFsIGxvY2tzIHRoZSBsaXN0IG9mIGxvY2tlZCBub2RlcyBpcyBhbHNvIHJldHVybmVk LiBUaGlzIGxpc3QgbWF5IA0KY2hhbmdlIG92ZXIgdGltZS4gRm9yIHBhcnRpYWwgbG9ja3MgdGhl IHNlbGVjdCBleHByZXNzaW9ucyBvcmlnaW5hbGx5IHVzZWQgdG8gDQpyZXF1ZXN0IHRoZSBsb2Nr IGFyZSBhbHNvIHJldHVybmVkLiBOb3RlIHRoYXQgdGhlIHNjb3BlIG9mIHRoZSBwYXJ0aWFsIGxv Y2sgaXMgDQpkZWZpbmVkIGJ5IHRoZSBsaXN0IG9mIGxvY2tlZCBub2Rlcy4gVGhlIHNlbGVjdCBl eHByZXNzaW9uLCBjYW4gaW5kaWNhdGVkIHRoZSANCm9yaWdpbmFsIGludGVuZGVkIHNjb3BlIG9m IHRoZSBsb2NrLg0KDQpbUmVzcG9uc2VdICBSZXdvcmRlZC4NCg0KNCkgMi4xLjMpDQpPTEQ6DQpB dCBsZWFzdCBvbmUgc2NoZW1hIGVudHJ5IFNIT1VMRCBiZSBhdmFpbGFibGUgdG8gc3VwcG9ydCBy ZXRyaWV2YWwuDQpORVc6DQpBdCBsZWFzdCBvbmUgbG9jYXRpb24gZW50cnkgU0hPVUxEIGJlIGF2 YWlsYWJsZSB0byBzdXBwb3J0IHJldHJpZXZhbC4NCg0KV2Ugc3Bva2UgYWJvdXQgZGlmZmVyZW50 aWF0aW5nIGJldHdlZW4gWUFORyBtb2R1bGVzLCBmcm9tIHdoaWNoIG9ubHkgdGhlIA0KZGF0YXR5 cGVzLCBncm91cGluZ3MgYXJlIHVzZWQgKHZpYSBpbXBvcnQpIGFuZCBZQU1zIHRoYXQgcmVhbGx5 IGRlZmluZSBkYXRhIA0Kbm9kZXMuIFRoaXMgaXMgbWlzc2luZyAhISEgVGhlIHNhbWUgcHJvYmxl bSBpcyB2YWxpZCBmb3Igb3RoZXIgWFNEIGFuZCBSTkcgYXMgDQp3ZWxsLiAgISEhISEhISEhISEh ISEhISEhISEhIQ0KDQpbUmVzcG9uc2VdICBVbnN1cmUgb2YgdGhlIGlzc3VlIGhlcmUuDQoNCjUp IDIuMS41KQ0KSSB0aGluayBzZXNzaW9uSWQgc2hvdWxkIGJlIGEga2V5Lg0KDQpbUmVzcG9uc2Vd ICBBZ3JlZWQuICBVcGRhdGVkLg0KDQo2KSAyLjEuNikNClRoZSBkZWZpbml0aW9ucyBvZiB0aGUg Y291bnRlcnMgYXJlIG5vdCBjbGVhciBlbm91Z2guIE1vcmUgZm9ybXVsYXMgbGlrZSB0aGUgDQpv bmUgaW4gdGhlIGRlZmluaXRpb24gb2YgaW5TZXNzaW9ucyBpbiB0aGUgWFNEIHdvdWxkIGJlIGdv b2QuDQoNCkRvIGluQmFkSGVsbG9zL2luQmFkUnBjcyBpbmNsdWRlIHBhcnNlIGVycm9ycz8gSSBh c3N1bWUgTm8NCg0KW1Jlc3BvbnNlXSAgU2VlIHJlc3BvbnNlIGFib3ZlLiAgQ291bnRlciBkZWZp bml0aW9ucyBuZWVkcyBmdXJ0aGVyIGRpc2N1c3Npb24uDQoNCjcpIDMuMikNCmluIHRoZSBzZW50 ZW5jZSBpbiB0aGUgcmVwbHkgY29udGFpbmluZyB0aGUgPGlkZW50aWZpZXI+ICw8dmVyc2lvbj4g YW5kDQogICAgPGxvY2F0aW9uPiBlbGVtZW50cy4NCmluY2x1ZGUgZm9ybWF0IGFzIHdlbGwuIEl0 cyBhIGNyaXRpY2FsIGJpdCBvZiBkYXRhLg0KDQogICAgVGhlIHJlc3BvbnNlIGRhdGEgY2FuIGJl IHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSBhdmFpbGFibGUgc2NoZW1hIGFuZA0KICAgIHRoZWlyIHZl cnNpb25zLiAgVGhlIHNjaGVtYSBpdHNlbGYgKGllLiBzY2hlbWEgY29udGVudCkgaXMgbm90DQog ICAgcmV0dXJuZWQgaW4gdGhlIHJlc3BvbnNlLiAgVGhlIGRldGFpbHMgcmV0dXJuZWQgaW4gdGhl IGxpc3QgU0hPVUxEDQogICAgZmFjaWxpdGF0ZSByZXRyaWV2YWwgZnJvbSBhIG5ldHdvcmsgbG9j YXRpb24gdmlhIGEgVVJMIHVzaW5nIGENCiAgICBzdXBwb3J0ZWQgbWVjaGFuaXNtIG9uIHRoZSBk ZXZpY2Ugc3VjaCBhcyBmdHAgb3IgaHR0cC5pDQoNCltSZXNwb25zZV0gIERvbmUuDQoNCjgpIFdo YXQgZG9lcyAic3VwcG9ydGVkIG1lY2hhbmlzbSBvbiB0aGUgZGV2aWNlIiBtZWFuPyBSZXdvcmQh DQoNCltSZXNwb25zZV0gIEl0IG1lYW5zIGFueSBzdXBwb3J0ZWQgbWVhbnMgYnkgd2hpY2ggdGhl IHNjaGVtYSBjb3VsZCBiZSANCnJldHJpZXZlZC4gIFNpbmNlIGZ0cCBhbmQgaHR0cCBhcmUgbW9z dCBsaWtlbHkgaXQncyBiZWVuIHJld29yZGVkIGFjY29yZGluZ2x5Lg0KDQo5KSANCiAgICBBZGRp dGlvbmFsbHkgdGhlIGFiaWxpdHkgdG8gcmV0cmlldmUgYSBzY2hlbWEgdmlhIE5FVENPTkYgU0hP VUxEIGJlDQogICAgc3VwcG9ydGVkLiAgV2hlbiBhIHNjaGVtYSBpcyBhdmFpbGFibGUgb24gdGhl IGRldmljZSBhbmQgdGhlIHNjaGVtYS0NCiAgICByZXRyaWV2YWwgY2FwYWJpbGl0eSBpcyBzdXBw b3J0ZWQgYnkgdGhlIE5FVENPTkYgc2VydmVyIGEgbG9jYXRpb24NCiAgICB2YWx1ZSBvZiAnTkVU Q09ORicgTVVTVCBiZSB1c2VkIHRvIGluZGljYXRlIHRoYXQgaXQgY2FuIGJlIHJldHJpZXZlZA0K ICAgIHZpYSBORVRDT05GIHVzaW5nIHRoZSA8Z2V0LXNjaGVtYT4gUlBDIGRlc2NyaWJlZCBpbiBz ZWN0aW9uIDMuMS4NCg0KVGhpcyBpcyB0aGUgZmlyc3QgcGxhY2Ugd2VyZSBpdCBpcyBtZW50aW9u ZWQgdGhhdCB0aGlzIGRyYWZ0IGlzIGRlZmVpbmluZyBhIA0KTkVUQ09ORiBjYXBhYmlsaXR5LiAN Ckl0IGlzIGEgYml0IHRvIGluZm9ybWFsIGlzbid0IGl0IDotKQ0KDQpbUmVzcG9uc2VdICBBZ3Jl ZWQuICBQZXIgYWJvdmUgcmVzcG9uc2UgdGhpcyB3YXMgYWRkZWQgdG8gU2VjdGlvbiAyIGludHJv Lg0KDQoxMCkgNS4xKQ0KVGhlIGRlZmF1bHQgbWluT2NjdXJzPSIxIiBtYXhPY2N1cnM9IjEiIHNo b3VsZCBiZSByZW1vdmVkLiBUaGV5IGp1c3QgY2x1dHRlciANCnRoZSB0ZXh0Lg0KDQotLS0NCiAg ICAgICAgIDx4czplbGVtZW50IG5hbWU9InNjaGVtYXMiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJz PSIxIj4NCg0KW1Jlc3BvbnNlXSAgUHJldmlvdXMgY29tbWVudHMgd2VyZSB0byBhZGQgdGhlbS4g IFByZWZlciB0byBiZSBzcGVjaWZpYyBoZXJlLg0KDQoxMSkgSSB0aGluayB0aGUgZWxlbWVudCBu YW1lIHNob3VsZCBiZSBpbiBzaW5ndWxhci4gbWluT2NjdXJzPSIwIiBpcyBub3QgbmVlZGVkLCAN CmFzIGF0IGxlYXN0IHRoaXMgcHJlc2VudCBzY2hlbWEgaXMgc3VwcG9ydGVkLg0KDQotLS0NCiAg ICAgICAgIDx4czplbGVtZW50IG5hbWU9InN0YXRpc3RpY3MiIHR5cGU9Ik1hbmFnZW1lbnRTdGF0 aXN0aWNzIg0KICAgICAgICAgICAgICAgICAgICAgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEi Pg0KDQptaW5PY2N1cnM9IjAiIHNlZW1zIHVubmVlZGVkLiBJcyBpdCByZWFsbHkgdGhlIGludGVu dCB0aGF0IHN0YXRpc3RpY3MgbWlnaHQgDQpzb21ldGltZXMgYmUgY29tcGxldGVseSBhYnNlbnQ/ IFNob3VsZG4ndCBpdCB0aGVuIHJhdGhlciBiZSBhIHNlcGFyYXRlIA0KY2FwYWJpbGl0eT8NCg0K W1Jlc3BvbnNlXSAgT24gc29tZSBkZXZpY2VzIHRoZSBnZW5lcmF0aW9uIG9mIHNwZWNpZmljIHN0 YXRpc3RpY3MgaXMgY29uZmlndXJhYmxlLg0KUHJlZmVyIHRvIGxlYXZlIHRoaXMgYXMgb3B0aW9u YWwuICBObyBjaGFuZ2UgbWFkZS4NCg0KMTIpIEdlbmVyYWxseSB0YWtlIGNhcmUgd2hldGhlciB0 aGUgcGx1cmFsIG9yIHNpbmd1bGFyIGZvcm0gb2YgZWxlbWVudHMgbmFtZXMgaXMgDQp1c2VkLiBF LmcuDQo8eHM6ZWxlbWVudCBuYW1lPSJwYXJ0aWFsTG9ja3MiDQoNCnBhcnRpYWxMb2NrcyBuZWVk cyBtaW5PY2N1cnM9IjAiDQoNCltSZXNwb25zZV0gIERvbmUuDQoNCjEzKSAtLS0tLSA8eHM6ZWxl bWVudCBuYW1lPSJ0cmFuc3BvcnQiDQpkZXNjcmlwdGlvbiBzaG91bGQgaW5jbHVkZSBTT0FQLCBC RUVQLCBUTFMNCg0KW1Jlc3BvbnNlXSBEb25lLg0KDQoxNCkgPHhzOmVsZW1lbnQgbmFtZT0idXNl cm5hbWUiDQpzL3VzZXJuYW1lL3VzZXJOYW1lLw0KDQpzZXNzaW9uIG93bmVyIGlzIGEgYmFkIHRl cm0uIE1hbmFnZW1lbnQgdXNlciBhdXRoZW50aWNhdGVkIGZvciB0aGUgc2Vzc2lvbi4NCg0KW1Jl c3BvbnNlXSAgU2VlIGVhcmxpZXIgcmVzcG9uc2UgcGVyIEFuZHkncyBjb21tZW50LiAgTmVlZHMg bW9yZSBkaXNjdXNzaW9uIGF0DQpJRVRGNzQuDQoNCjE1KSBGb3IgYm90aCBzdWJzY3JpcHRpb25z IGFuZCBwYXJ0aWFsIGxvY2tzIHRoZSBYU0QgYW5kIFlBTkcgc2hvdWxkIHJlZmVyIHRvIHRoZSAN ClJGQy4gRXNwZWNpYWxseSBhcyB0aGUgY29udGVudHMgb2YgTmV0Y29uZlN1YnNjcmlwdGlvbiBk b24ndCBoYXZlIGFueSANCmRlc2NyaXB0aW9uLg0KDQogICAgICAgPHhzOmVsZW1lbnQgbmFtZT0i ZmlsdGVyIiB0eXBlPSJuZXRjb25mOmZpbHRlcklubGluZVR5cGUiLz4gbWlzc2luZyANCm1pbk9j Y3Vycz0iMCINCg0KW1Jlc3BvbnNlXSAgQWRkZWQgcmVmZXJlbmNlIHRvIFJGQyA1Mjc3Lg0KDQox NikgPHhzOmVsZW1lbnQgbmFtZT0ic3RhcnR1cCIgdHlwZT0ieHM6c3RyaW5nIi8+IHNob3VsZCBi ZSByZXN0cmljdGVkIHRvIA0KbGVuZ3RoPTAiICBNaXNtYXRjaCB3aXRoIFlBTkcNCg0KW1Jlc3Bv bnNlXSBEb25lLg0KDQoxNykgSXQgaXMgbWVudGlvbmVkIGluIGEgY29tbWVudCB0aGF0IHN0b3BU aW5lIGlzIG9wdGlvbmFsLCBidXQgbm90IGZvciBzdGFydFRpbWUuIA0KQmUgY29uc2VxdWVudC4N Cg0KICAgICAgICAgICA8eHM6ZG9jdW1lbnRhdGlvbj4NCiAgICAgICAgICAgICBUaGUgc2Vzc2lv biBJZCB3aGljaCBob2xkcyB0aGUgbG9jay4NCiAgICAgICAgICAgPC94czpkb2N1bWVudGF0aW9u Pg0KDQpbUmVzcG9uc2VdIEJvdGggYXJlIG9wdGlvbmFsLg0KDQoxOCkgSXQgc2hvdWxkIGJlIG1l bnRpb25lZCB0aGF0IGZvciBub24tbmV0Y29uZiBsb2NrIHRoZSBzZXNzaW9uIGlkIGNvbnRhaW5z IC4uLiANCkRvIGl0IGZvciBib3RoIGdsb2JhbCBhbmQgcGFydGlhbCBsb2NrcyBhbmQgZm9yIFlB TkcgdG9vDQoNCltRdWVzdGlvbl0gIEFyZSBub24tTkVUQ09ORiBsb2NrcyBjb3ZlcmVkIGJ5IDQ3 NDEgb3IgdGhlIHBhcnRpYWwtbG9ja2luZyBkcmFmdD8NCg0KMTkpIFRyYW5zcG9ydFR5cGUgbXVz dCBubyBiZSByZXN0cmljdGVkIHRvIGEgZml4ZWQgc2V0IG9mIHZhbHVlcy4gSXQgbXVzdCBpbmNs dWRlIA0KU09BUCwgQkVFUCBhbmQgVExTLiBTYW1lIGNvbW1lbnQgZm9yIFlBTkcuDQoNCltSZXNw b25zZV0gRG9uZS4gIERhdGEgdHlwZSByZW1haW5zIGFuIGVudW0gdGhvdWdoLg0KDQoyMCkgUHJv dG9jb2xUeXBlIG11c3Qgbm8gYmUgcmVzdHJpY3RlZCB0byBhIGZpeGVkIHNldCBvZiB2YWx1ZXMu IFNhbWUgY29tbWVudCBmb3IgDQpZQU5HLg0KDQpbUmVzcG9uc2VdIERvbmUuICBEYXRhIHR5cGUg cmVtYWlucyBhbiBlbnVtIHRob3VnaC4NCg0KMjEpIFRoZSBkZXNjcmlwdGlvbiBjbGF1c2Ugb2Yg b2JqZWN0cyB1c2luZyB0aGUNCiAgICAgICAgICAgIGRvbWFpbk5hbWUgdHlwZSBNVVNUIGRlc2Ny aWJlIGhvdyAoYW5kIHdoZW4pDQogICAgICAgICAgICB0aGVzZSBuYW1lcyBhcmUgcmVzb2x2ZWQg dG8gSVAgYWRkcmVzc2VzLg0KDQpXZSBkbyBub3QgZGVzY3JpYmUgd2hhdHMgcmVxdWlyZWQgaGVy ZSAhDQoNCltRdWVzdGlvbl0gIE5vdCBjbGVhciBvbiB3aGF0IGlzIGJlaW5nIGFza2VkIGZvciBo ZXJlPyAgRG8geW91IG1lYW4gZGVzY3JpYmUgaG93DQpzb21ldGhpbmcgbGlrZSBETlMgd291bGQg YmUgdXNlZCB0byBkZXRlcm1pbmUgaG9zdG5hbWU/DQoNCjIyKSA4KQ0KVGhlIHJlZ2lzdHJhdGlv biByZXF1ZXN0IGZvciB0aGUgWE1MIG5hbWVzcGFjZSBpcyBtaXNzaW5nLiBTZWUgTm90aWZpY2F0 aW9uIA0KUkZDLg0KDQpbUmVzcG9uc2VdICBEb25lLiAgQWRkZWQgZXhwbGljaXQgcmVxdWVzdC4g IFRoZSBwcmV2aW91cyB0ZXh0IGluZGljYXRpbmcgInRoZSBmb2xsb3dpbmcgcmVnaXN0cmF0aW9u cw0KcmVxdWlyZSBjb25zaWRlcmF0aW9uIiBhbHNvIGxlZnQuDQoNCjIzKSA5KSBBZGQgbm9uLW5v cm1hdGl2ZSByZWZlcmVuY2UgdG8gWUFORw0KDQpQYXJ0aWFsIGxvY2sgaXMgYWxyZWFkeSBhdCBy ZXZpc2lvbi0wNg0KDQpbUmVzcG9uc2VdICBVcGRhdGVkIHRvIHJldmlzaW9uLTA3Lg0KDQoyNCkg QXBwZW5kaXggQQ0KDQogICAgICAgbGVhZi1saXN0IGNhcGFiaWxpdHkgew0KICAgICAgICAgbWlu LWVsZW1lbnRzIDE7DQoNCnRoZXJlIGFyZSBhdCBsZWFzdCAzIGNhcGFiaWxpdGllcyBpZiB0aGlz IG1vZGVsIGNhbiBiZSByZWFkLg0KDQpbUmVzcG9uc2VdIG1pbi1lbGVtZW50cyBoYXMgYmVlbiBy ZW1vdmVkLg0KDQoyNSkgVGhlIFhNTCBlbmNvZGluZyBmb3IgY29uZmlnIGRhdGFzdG9yZSBuYW1l c2lzIGRpZmZlcmVudCBmb3IgWFNEIGFuZCBZQU5HDQoNCltSZXNwb25zZV0gVW5jbGVhciBvbiBp c3N1ZSBoZXJlLg0KDQotLS0tDQogICAgICAgICBhbnl4bWwgZmlsdGVyIHsNCiAgICAgICAgICAg ZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAiVGhlIGZpbHRlcnMgYXNzb2NpYXRlZCB3aXRoIHRo aXMgc3Vic2NyaXB0aW9uLiI7DQogICAgICAgICB9DQoyNikgT25seSBvbmUgZmlsdGVyIGNhbiBi ZSB1c2VkLiBGb3IgdGhlIGNvbnRlbnQgb2YgYW55WE1MIGluY2x1ZGUgYSByZWZlcmVuY2UgDQp0 byA0NzQxLg0KDQpbUmVzcG9uc2VdIERvbmUuDQoNClRoZSBkZXNjcmlwdGlvbnMgb2YgdGhlIHN1 YnNjcmlwdGlvbiBjb250ZW50IGlzIG5vdCB0aGUgc2FtZSBpbiBZQU5HIGFuZCBYU0QuIA0KU3lu Y2hyb25pemUhDQoNCg0KMjcpIG5ldGNvbmZTdGFydFRpbWUNCg0KTWVudGlvbiB0aGF0IGF0IG5l dGNvbmZTdGFydFRpbWU9MCBhbGwgY291bnRlcnMgYXJlIHJlc2V0IHRvIHplcm8uDQoNCltSZXNw b25zZV0gUGVyIGVhcmxpZXIgcmVzcG9uc2UsIGNvdW50ZXIgcmVzZXQgYmVoYXZpb3VyIG1heSBi ZSBpbXBsZW1lbnRhdGlvbg0Kc3BlY2lmaWMuICBUb3BpYyBvZiBkaXNjdXNzaW9uIGZvciBJRVRG NzQuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpPdGhlciBjaGFuZ2Vz DQotLS0tLS0tLS0tLS0tDQoNCjEuICBBZGRlZCBJRVRGIGRpc2NsYWltZXIgcGVyIG5ldyB0ZW1w bGF0ZQ0KMi4gIE9wZW4gaXRlbSBvbiB3aGV0aGVyIGRpc2NsYWltZXJzIG5lZWQgdG8gYmUgaW5j bHVkZWQgaW4gbm9ybWF0aXZlIGFuZCBub24tbm9ybWF0aXZlDQptb2RlbHMgYXMgd2VsbC4= ------_=_NextPart_001_01C9A41C.8AB60362-- From Washam.Fan@huaweisymantec.com Fri Mar 13 17:40:23 2009 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 40AE63A69B8 for ; Fri, 13 Mar 2009 17:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hW5GbjW9VfgA for ; Fri, 13 Mar 2009 17:40:22 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id 190A13A6452 for ; Fri, 13 Mar 2009 17:40:21 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KGH008EX0K6HQ50@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 14 Mar 2009 08:40:56 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KGH00I9F0K4GS20@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 14 Mar 2009 08:40:54 +0800 (CST) Received: from [121.101.220.178] by hstml01-in.huaweisymantec.com (mshttpd) ; Sat, 14 Mar 2009 08:40:52 +0800 From: WashamFan To: Mark Scott Message-id: Date: Sat, 14 Mar 2009 08:40:52 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <238C6E77EA42504DA038BAEE6D1C11EC02620D24@zcarhxm0.corp.nortel.com> References: <20090309234501.9601128C286@core3.amsl.com> <238C6E77EA42504DA038BAEE6D1C11EC02620D24@zcarhxm0.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-monitoring-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2009 00:40:23 -0000 Hi, It seems this thread has been ignored http://www.ietf.org/mail-archive/web/netconf/current/msg04272.html PS: Mark, please update my address to washam.fan@huaweisymantec.com washam > Hello, > > The updated draft below addresses the comments received in the WGLC of > draft-ietf-netconf-monitoring-03. > > I have attached a document containing the responses to all comments > indicating: > - updated in v04 where applicable > - open item to be discussed at IETF74 > - item to be followed up on the mailing list > > If any comments on v03 were (unintentionally) missed please raise them > to my attention again. > > They will be addressed in v05 along with others comments received on v04 > (incl. those already raised by Andy - thanks!). > > Mark > > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Monday, March 09, 2009 7:45 PM > To: i-d-announce@ietf.org > Cc: netconf@ietf.org > Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-04.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Network Configuration Working Group of > the IETF. > > > Title : NETCONF Monitoring Schema > Author(s) : M. Scott, et al. > Filename : draft-ietf-netconf-monitoring-04.txt > Pages : 46 > Date : 2009-03-09 > > This document defines a NETCONF data model (in XML Schema) to be used > to > monitor the NETCONF protocol. The monitoring data model includes > information about NETCONF datastores, sessions, locks, subscriptions, > and statistics. This data facilitates the management of a NETCONF > server. This document also defines methods for NETCONF clients to > discover data models supported by a NETCONF server and defines a new > NETCONF operation to retrieve them. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From mehmet.ersue@nsn.com Sat Mar 14 17:37:16 2009 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 2DE663A699A for ; Sat, 14 Mar 2009 17:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.522 X-Spam-Level: X-Spam-Status: No, score=-5.522 tagged_above=-999 required=5 tests=[AWL=1.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnvC53Rv-+23 for ; Sat, 14 Mar 2009 17:37:15 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id AD3EA3A6822 for ; Sat, 14 Mar 2009 17:37:14 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n2F0bn80025245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 15 Mar 2009 01:37:49 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n2F0bnOA003609; Sun, 15 Mar 2009 01:37:49 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 15 Mar 2009 01:36:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A506.0E3E04B3" Date: Sun, 15 Mar 2009 01:36:18 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NETCONF over TLS Issue remaining from IESG chat Thread-Index: AcmkB45y9BqFnOoYQE2FmF/c24ZdMAA0sKVw From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 15 Mar 2009 00:36:23.0756 (UTC) FILETIME=[116DB8C0:01C9A506] Cc: ext Badra Subject: [Netconf] NETCONF over TLS Issue remaining from IESG chat 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, 15 Mar 2009 00:37:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A506.0E3E04B3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, we have one remaining issue from the IESG chat=20 for the NETCONF over TLS on the way to RFC. (see=20 the IESG ballot page for DISCUSSes from Jari Arkko=20 and Tim Polk and the text proposals before IESG chat:=20 https://datatracker.ietf.org/idtracker/ballot/2950/) There was an inconcistency between Ch 2.1. and=20 3.2. in v-07.=20 Ch 2.1 limits implementations to TLS cipher suites=20 that provide certificate-based mutual authentication,=20 where Ch 3.2 allows connections without verifying=20 the client identity. Jari would be fine with the changes we proposed=20 for Ch 3.2. before the IESG chat (see ballot page).=20 Tim would consider the issue as resolved if we clarify=20 that certificate-based client authentication is a=20 requirement and servers must authenticate the client.=20 Based on this considerations Badra prepared following=20 changes: Section 2.1: ----------- OLD: Implementation of the protocol specified in this document=20 MAY implement any TLS cipher suite that provides=20 certificate-based mutual authentication [RFC5246].=20 NEW: Implementation of the protocol specified in this document=20 MAY implement any TLS cipher suite that provides=20 certificate-based mutual authentication [RFC5246].=20 The server MUST support certificate-based client=20 authentication. Section 3.2: ----------- OLD: The server may have no external knowledge on client's=20 identity and identity checks might not be possible (unless=20 the client has a certificate chain rooted in an appropriate=20 CA). If a server has knowledge on client's identity (typically=20 from some source external to NETCONF or TLS) it MUST=20 check the identity as described above. NEW: "The server MUST verify the identity of the client with=20 certificate-based authentication and according to local=20 policy to ensure that the incoming client request is=20 legitimate before any configuration or state data is=20 sent to or received from the client." The WG co-chairs think the proposed change will=20 address Tim's DISCUSS. We believe this is a suitable=20 solution and assume the WG members will agree.=20 However, if anyone has STRONG OBJECTIONS, please=20 let us know BEFORE March 20, 2009. Mehmet ------_=_NextPart_001_01C9A506.0E3E04B3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NETCONF over TLS Issue remaining from IESG chat

Hi = All,

we have one = remaining issue from the IESG chat
for the NETCONF = over TLS on the way to RFC. (see
the IESG ballot = page for DISCUSSes from Jari Arkko
and Tim Polk and = the text proposals before IESG chat:
https://datatracker.ietf.org/idtracker/ballot/2950/)

There was an = inconcistency between Ch 2.1. and
3.2. in v-07. =
Ch 2.1 limits = implementations to TLS cipher suites
that provide = certificate-based mutual authentication,
where Ch 3.2 = allows connections without verifying
the client = identity.
Jari would be fine = with the changes we proposed
for Ch 3.2. before = the IESG chat (see ballot page).
Tim would consider = the issue as resolved if we clarify
that = certificate-based client authentication is a
requirement and = servers must authenticate the client.

Based on this = considerations Badra prepared following
changes:

Section = 2.1:
-----------
OLD:
Implementation of = the protocol specified in this document
MAY implement any = TLS cipher suite that provides
certificate-based = mutual   authentication [RFC5246].

NEW:
Implementation of = the protocol specified in this document
MAY implement any = TLS cipher suite that provides
certificate-based = mutual  authentication [RFC5246].
The server MUST = support certificate-based client
authentication.

Section = 3.2:
-----------
OLD:
The server may = have no external knowledge on client's
identity and = identity checks might not be possible (unless
the client has a = certificate chain rooted in an appropriate
CA). If a server = has knowledge on client's identity (typically
from some source = external to NETCONF or TLS) it MUST
check the identity = as described above.

NEW:
"The server = MUST verify the identity of the client with
certificate-based = authentication and according to local
policy to ensure = that the incoming client request is
legitimate before = any configuration or state data is
sent to or = received from the client."


The WG co-chairs = think the proposed change will
address Tim's = DISCUSS. We believe this is a suitable
solution and = assume the WG members will agree.
However, if anyone = has STRONG OBJECTIONS, please
let us know BEFORE = March 20, 2009.

Mehmet

------_=_NextPart_001_01C9A506.0E3E04B3-- From balazs.lengyel@ericsson.com Mon Mar 16 03:16:56 2009 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 B2FB43A6A91 for ; Mon, 16 Mar 2009 03:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cw4MmlePNE9L for ; Mon, 16 Mar 2009 03:16:55 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 989F63A6814 for ; Mon, 16 Mar 2009 03:16:55 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2F9E8206C8; Mon, 16 Mar 2009 11:17:36 +0100 (CET) X-AuditID: c1b4fb3e-ac89bbb0000023da-24-49be2740ebe9 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 124B1200FE; Mon, 16 Mar 2009 11:17:36 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Mar 2009 11:17:20 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Mar 2009 11:17:20 +0100 Message-ID: <49BE2730.6000107@ericsson.com> Date: Mon, 16 Mar 2009 11:17:20 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Mark Scott References: <20090309234501.9601128C286@core3.amsl.com> <238C6E77EA42504DA038BAEE6D1C11EC02620D24@zcarhxm0.corp.nortel.com> In-Reply-To: <238C6E77EA42504DA038BAEE6D1C11EC02620D24@zcarhxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2009 10:17:20.0807 (UTC) FILETIME=[64435B70:01C9A620] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org, Washam Fan Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-monitoring-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 10:16:56 -0000 Hello Mark, Some comments to your file. Balazs 18) It should be mentioned that for non-netconf lock the session id contains ... Do it for both global and partial locks and for YANG too [Question] Are non-NETCONF locks covered by 4741 or the partial-locking draft? BALAZS: 4741 or partial-lock does not define any non-Netconf locks. However both 4741 and partial-lock discuss and handle the case of foreign locks. All our locks are multiprotocol locks. In RFC4741 there is a specific eror code for foreign locks. So IMO we definitely should include them here. As some devices might not be able to provide this information, we should include something like: Information about non-NETCONF locks SHOULD also provided. The session ID should follow RFC4741: Session ID of session holding the lock, for non-NETCONF sessions this maybe zero. 19) TransportType must no be restricted to a fixed set of values. It must include SOAP, BEEP and TLS. Same comment for YANG. [Response] Done. Data type remains an enum though. BALAZS: MUST not be enum. One well known vendor uses TSP. So thats a violation of the standard. 20) ProtocolType must no be restricted to a fixed set of values. Same comment for YANG. [Response] Done. Data type remains an enum though. BALAZS: So you allow WebUIs but not JavaGUIs? MUST not be enum. 21) The description clause of objects using the domainName type MUST describe how (and when) these names are resolved to IP addresses. We do not describe whats required here ! [Question] Not clear on what is being asked for here? Do you mean describe how something like DNS would be used to determine hostname? BALAZS: Then remove your own text, that demands the description! From balazs.lengyel@ericsson.com Mon Mar 16 03:26:01 2009 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 E656D3A6A21 for ; Mon, 16 Mar 2009 03:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.027 X-Spam-Level: X-Spam-Status: No, score=-6.027 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfPxoZWaDxNh for ; Mon, 16 Mar 2009 03:26:01 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id B2A9E3A6803 for ; Mon, 16 Mar 2009 03:26:00 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D92B321791 for ; Mon, 16 Mar 2009 11:22:57 +0100 (CET) X-AuditID: c1b4fb3e-b00a2bb0000023da-e9-49be2881f25d Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AD09C20680 for ; Mon, 16 Mar 2009 11:22:57 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Mar 2009 11:21:42 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Mar 2009 11:21:42 +0100 Message-ID: <49BE2835.1060202@ericsson.com> Date: Mon, 16 Mar 2009 11:21:41 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2009 10:21:42.0351 (UTC) FILETIME=[0027CDF0:01C9A621] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] comments on netconf-monitoring-04 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 10:26:02 -0000 Hello, Comments: General: Some parts of the capability template should be followed. - The capability string should be defined not just in the IANA considerations, but before that separately - it should be explicitly stated that this does not change any existing operations or capabilities - it should be stated that this does not depend on other capabilities Introduction paragraph 2) I would just write: "This capability allows the client to query the Netconf servers capabilities during a session." This leaves the question whether capabilities can change during the session open. That should be answered by the 4741bis anyway. 1.1. Definition of Terms) d/lockedescribed - strange :-) 2.1. The /netconf-state Subtree) IMHO it would be good to list all OAM sessions not just NETCONF. Maybe add: "List of active management sessions on the device, MUST include all active NETCONF sessions and SHOULD include all active non-NETCONF management sessions." 2.1.2. The /netconf-state/datastores Subtree "The /netconf-state/datastores subtree contains configuration data for the NETCONF server" So there is something to configure here... I don't think so. s/ConfigurationDataStore instance/ConfigurationDataStore "Both a global lock and a partial lock MUST contain the sessionId." What if a non-NETCONF session locks a datastore? This possibility is acknowledged by 4741 and the partial-lock draft, so it should be handled here as well. We should provide information on those locks as well. "For partial locks the list of locked nodes is also returned. Since this list may change over time the select expressions originally used to request the lock are also returned. " This sentence is not correct. Change to: For partial locks the list of locked nodes and the select expressions originally used to request the lock are also returned. 3.2. NETCONF Schema List Retrieval ( monitoring data) If access control denies the partial lock, the will be 'access-denied'. How does partial-lock come here? 4.1) opening and closing tags don't match 5.1) XSD "1G" Remove !G The XSD definition of NETCONFDatastoreType does not match the YANG definition. It allows Hello this is a funny definition YANG does nto allow this. Instance-identifiers are never defined. a reference to the partial-lock draft should be included TransportType restricts the allowed values of transport, so if someone uses e.g. plain TCP that will mean he is violating the standard. I think this MUST be an extensible list. (in YANG too) The ProtocolType must also be extensible too. (in YANG too) domainName The description clause of objects using the domainName type MUST describe how (and when) these names are resolved to IP addresses. Is this described or remove the MUST from above 8. IANA Considerations reservations for the targetnamespace of the 2 XSDs are missing 9.References A non-normative YANG reference is missing Appendix A) YANG Reference statements should be included towards the Notification RFC and the Partial-lock draft. From kwatsen@juniper.net Mon Mar 16 09:39:17 2009 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 1FEDB3A699F for ; Mon, 16 Mar 2009 09:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuufKCPMXkxh for ; Mon, 16 Mar 2009 09:39:16 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 796ED3A6BC4 for ; Mon, 16 Mar 2009 09:39:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSb6A3TLaeuqFxRLGHGsSiabR7Oc2sRv4@postini.com; Mon, 16 Mar 2009 09:39:58 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 16 Mar 2009 09:36:40 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Mar 2009 09:36:40 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Mar 2009 09:36:40 -0700 Received: from antitop.jnpr.net ([172.24.15.27]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Mar 2009 09:36:39 -0700 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, 16 Mar 2009 09:36:38 -0700 Message-ID: In-Reply-To: <49B79B0A.3040505@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] issue with draft-ietf-netconf-partial-lock-07.txt Thread-Index: AcmiOVaPbiK3VIjaTCyYDXfV6zSQsQEFRrNQ References: <49B79B0A.3040505@ericsson.com> From: Kent Watsen To: "Balazs Lengyel" X-OriginalArrivalTime: 16 Mar 2009 16:36:39.0446 (UTC) FILETIME=[61781360:01C9A655] Cc: netconf@ietf.org Subject: Re: [Netconf] issue with draft-ietf-netconf-partial-lock-07.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: Mon, 16 Mar 2009 16:39:17 -0000 > As I see the basic problem is that one node needs to be handled by > multiple operators.=20 Yes > This > means that each operator should only touch part of the configuration. Not necessarily - for two reasons: 1) the device's configuration data model may not be hierarchically structured along "operator" boundaries and 2) customers may deploy more than one applications/scripts that having overlapping interest in the config > For the candidate this is more difficult as commit is global. Doesn't have to be - and, even if the device serializes the updates internally, that doesn't have exposed via the NetConf model > However the working group decided that we do not want to provide partial > versions of other > operations (commit, copy-config, delete-config, validate?). The workgroup > decided that partial > locking as an optional feature is useful without other (new/updated) > partial operations, so the > WG does not want other partial operations as that would be a too big > impact. Yes, we would need to have "partial-" variants of these other commands as well > I agree, partial-locking will be most useful for operators using the > writable-running > capability, but it can be used even for the candidate datastore. Yes, partial-lock can be used on a candidate datastore, but it never would. Think about it - apps need to be 100% sure that they don't commit unattended changes which, without a , means that they would have to lock the entire config, which they would do using NetConf's existing global-lock (not a bunch of partial-locks). So I conclude that if partial-lock is ever be used on a candidate datastore, it must be possible to do a partial-commit Thanks, Kent From mehmet.ersue@nsn.com Mon Mar 16 12:07:36 2009 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 CA46828C1C8 for ; Mon, 16 Mar 2009 12:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=-0.973, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EII2woovUHCg for ; Mon, 16 Mar 2009 12:07:36 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id A47E228C0E3 for ; Mon, 16 Mar 2009 12:07:35 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n2GJ8DgX011172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Mar 2009 20:08:13 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n2GJ8Cqq032561; Mon, 16 Mar 2009 20:08:13 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Mar 2009 20:08:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A66A.8BC94342" Date: Mon, 16 Mar 2009 20:08:09 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for IETF #74 NETCONF Session Thread-Index: AcmbQvoAww2K+4N3QkyOIAKlDQE82AADjyYgAV45pcABZ9P2AA== References: From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 16 Mar 2009 19:08:12.0748 (UTC) FILETIME=[8D7FD8C0:01C9A66A] Subject: [Netconf] Agenda for IETF #74 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 19:07:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A66A.8BC94342 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, =20 we uploaded the agenda for the IETF #74 NETCONF=20 session to the Meeting Materials site: http://www.ietf.org/proceedings/09mar/agenda/netconf.txt =20 Cheers, Mehmet=20 =20 NETCONF WG=20 IETF 74, San Francisco, CA, USA TUESDAY, March 24, 2009, 1300-1500=20 WG Chairs: Bert Wijnen Mehmet Ersue Scribes (IF no_volunteers THEN wait_forever)=20 Agenda bashing (2 minutes)=20 WG status review (5 minutes)=20 Chartered items: 1. Partial Lock RPC for NETCONF - Balazs Lengyel (5 minutes)=20 draft-ietf-netconf-partial-lock=20 2. NETCONF Monitoring Schema - Mark Scott (15 minutes) =20 draft-ietf-netconf-monitoring 3. With-defaults capability for NETCONF - B. Lengyel (20 minutes) draft-ietf-netconf-with-defaults 4. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20 minutes) draft-ietf-netconf-4741bis Non-Chartered items: 1. Generic solution for the message integrity issue (15 minutes) 2. Robust Configuration Management within NETCONF - R. Cole/D. = Romascanu (15 minutes) =20 draft-cole-netconf-robust-config-00 Open mike (15 minutes) Augmenting NETCONF protocol operations Any other topics to discuss?=20 AOB ------_=_NextPart_001_01C9A66A.8BC94342 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Draft Agenda for IETF #74 NETCONF Session
Hi All,
 
we uploaded the agenda for=20 the IETF #74 = NETCONF=20
session=20 to the Meeting Materials site:
http://= www.ietf.org/proceedings/09mar/agenda/netconf.txt
=
 
Cheers,
Mehmet =
 
NETCONF WG=20
IETF 74, San Francisco, CA, USA

TUESDAY, March 24, 2009, 1300-1500=20

   WG Chairs:
   Bert Wijnen <bertietf@bwijnen.net>
   Mehmet Ersue <mehmet.ersue@nsn.com>

   Scribes (IF no_volunteers THEN wait_forever)=20
   Agenda bashing (2 minutes)=20
   WG status review (5 minutes)=20

   Chartered items:

      1. Partial Lock RPC for NETCONF - Balazs Lengyel (5 minutes)=20
         draft-ietf-netconf-partial-lock=20
      2. NETCONF Monitoring Schema - Mark Scott (15 minutes) =20
         draft-ietf-netconf-monitoring
      3. With-defaults capability for NETCONF - B. Lengyel (20 minutes)
         draft-ietf-netconf-with-defaults
      4. 4741bis-draft - M. Bjorklund/J. Sch=F6nw=E4lder (20 minutes)
         draft-ietf-netconf-4741bis

   Non-Chartered items:

      1. Generic solution for the message integrity issue (15 minutes)
      2. Robust Configuration Management within NETCONF - R. Cole/D. =
Romascanu (15 minutes) =20
         draft-cole-netconf-robust-config-00

   Open mike (15 minutes)
      Augmenting NETCONF protocol operations
      Any other topics to discuss?=20

   AOB
------_=_NextPart_001_01C9A66A.8BC94342-- From Washam.Fan@huaweisymantec.com Mon Mar 16 13:47:09 2009 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 9DA2A3A6ADB for ; Mon, 16 Mar 2009 13:47:09 -0700 (PDT) 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 emeMwITq9MFd for ; Mon, 16 Mar 2009 13:47:08 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id C2B5D3A6987 for ; Mon, 16 Mar 2009 13:47:08 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KGK007QEYHAC460@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Mon, 16 Mar 2009 11:46:24 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KGK00K5XYH9NA00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Mon, 16 Mar 2009 11:46:22 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Mon, 16 Mar 2009 11:46:21 +0800 From: WashamFan To: Ladislav Lhotka Message-id: Date: Mon, 16 Mar 2009 11:46:21 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <1236963097.6391.92.camel@missotis> References: <1236956890.6391.44.camel@missotis> <49BA86F8.9010101@ericsson.com> <1236963097.6391.92.camel@missotis> Cc: NETCONF WG Subject: Re: [Netconf] comments on -with-defaults-00 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, 16 Mar 2009 20:47:09 -0000 > The case with message-id="103" doesn't ask for interfaces with mtu but > for the mtu leaf itself. So the reply could contain either > > > > 8192 > > > 1500 > > > > or > > > > 8192 > > > > > or even > > > > 8192 > > > > Which one is correct? In my opinion, the 2nd one makes more sense. To my understanding, with-default is not intended to deal with what you request but what I return. So the default data, if exists in reply, will be present or absent in depending on value or basic behavior. But I got a question. the basic behavior has three types (report-all, trim, explicit) whereas operation behavior on with-default has two types. (true or false). Why allowing for this inconsistency? washam From mbj@tail-f.com Mon Mar 16 14:05:35 2009 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 CCE7A3A68ED for ; Mon, 16 Mar 2009 14:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=0.085, 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 nvMeuQog9Awy for ; Mon, 16 Mar 2009 14:05:35 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0A6D63A688B for ; Mon, 16 Mar 2009 14:05:34 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 26C8F616004; Mon, 16 Mar 2009 22:06:16 +0100 (CET) Date: Mon, 16 Mar 2009 22:06:15 +0100 (CET) Message-Id: <20090316.220615.157083759.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <49BA87AC.1090304@ericsson.com> References: <49BA87AC.1090304@ericsson.com> X-Mailer: Mew version 6.0.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] Comment to 4741bis 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, 16 Mar 2009 21:05:35 -0000 Balazs Lengyel wrote: > 8.8.5.1. > > The :url capability modifies the operation to accept > the element as an alternative to the parameter. If > the element is specified, then it should identify a local > configuration file. The same text is also present in 7.2, where you also find this: This operation allows the new configuration to be expressed in several ways, such as using a local file, a remote file, or inline. Note the phrase "remote file". I think the sentence "If the element is specified, then it should identify a local configuration file." should be removed. > There is a similar - the url should identify a local file - statement for > delete-config, but not for copy-config or for validate. Is this correct? delete-config is different - IMO we should say that for delete-config, the url MUST identify a local file (i.e. have url scheme 'file'). I don't think it makes sense for NETCONF to function as a file deletion proxy... /martin From balazs.lengyel@ericsson.com Tue Mar 17 04:15:08 2009 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 965D528C102 for ; Tue, 17 Mar 2009 04:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzxXnwkc4-LL for ; Tue, 17 Mar 2009 04:15:07 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5D41A28C103 for ; Tue, 17 Mar 2009 04:15:03 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2A63F2625B; Tue, 17 Mar 2009 12:15:43 +0100 (CET) X-AuditID: c1b4fb3e-af8a1bb0000023da-74-49bf76af9db5 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 04FFA2626A; Tue, 17 Mar 2009 11:08:49 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Mar 2009 11:07:14 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Mar 2009 11:07:14 +0100 Message-ID: <49BF7651.5050405@ericsson.com> Date: Tue, 17 Mar 2009 11:07:13 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <49BA87AC.1090304@ericsson.com> <20090316.220615.157083759.mbj@tail-f.com> In-Reply-To: <20090316.220615.157083759.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Mar 2009 10:07:14.0659 (UTC) FILETIME=[25624330:01C9A6E8] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Comment to 4741bis 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, 17 Mar 2009 11:15:08 -0000 I would only allow copy config towards files where either the source or target is a real datastore. "I don't think it makes sense for NETCONF to function as a file deletion proxy..." You could make the same argument against a text-editor proxy or a file copy proxy. The question is really do we want to support file based (URL based) datastores. If yes all I need is a flat file and Confd :-) Edit/Delete/Validate/Copy will work towards a flat XML file as well. You could also ask the question, do we want to support, or at least allow support for such file based datastores? Balazs Martin Bjorklund wrote: > Balazs Lengyel wrote: >> 8.8.5.1. >> >> The :url capability modifies the operation to accept >> the element as an alternative to the parameter. If >> the element is specified, then it should identify a local >> configuration file. > > The same text is also present in 7.2, where you also find this: > > This > operation allows the new configuration to be expressed in several > ways, such as using a local file, a remote file, or inline. > > Note the phrase "remote file". > > I think the sentence "If the element is specified, then it > should identify a local configuration file." should be removed. > >> There is a similar - the url should identify a local file - statement for >> delete-config, but not for copy-config or for validate. Is this correct? > > delete-config is different - IMO we should say that for delete-config, > the url MUST identify a local file (i.e. have url scheme 'file'). I > don't think it makes sense for NETCONF to function as a file deletion > proxy... > > > /martin > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From j.schoenwaelder@jacobs-university.de Tue Mar 17 04:25:00 2009 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 344BA3A68BF for ; Tue, 17 Mar 2009 04:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=0.156, 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 K2gTVsLeoZTY for ; Tue, 17 Mar 2009 04:24:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 35A2D3A67D6 for ; Tue, 17 Mar 2009 04:24:59 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BBF13C0030; Tue, 17 Mar 2009 12:25:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zKsJJf5aQiEY; Tue, 17 Mar 2009 12:25:41 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CA624C002F; Tue, 17 Mar 2009 12:25:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8D223A0AEB4; Tue, 17 Mar 2009 12:25:28 +0100 (CET) Date: Tue, 17 Mar 2009 12:25:28 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20090317112528.GA11272@elstar.local> Mail-Followup-To: Balazs Lengyel , Martin Bjorklund , "netconf@ietf.org" References: <49BA87AC.1090304@ericsson.com> <20090316.220615.157083759.mbj@tail-f.com> <49BF7651.5050405@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49BF7651.5050405@ericsson.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Comment to 4741bis 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: Tue, 17 Mar 2009 11:25:00 -0000 On Tue, Mar 17, 2009 at 11:07:13AM +0100, Balazs Lengyel wrote: > The question is really do we want to support file based (URL based) > datastores. If yes all I need is a flat file and Confd :-) > Edit/Delete/Validate/Copy will work towards a flat XML file as well. > > You could also ask the question, do we want to support, or at least > allow support for such file based datastores? I find this part of RFC 4741 somewhat unclear and in particular I think we need to clarify (i) where URLs are allowed and make sense and (ii) where URLs are restricted to "local" file: URLs and where we like to see support for arbitrary "remote" URLs. And I think supporting remote URLs has some security implications that likely need to be discussed in the security considerations. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From balazs.lengyel@ericsson.com Tue Mar 17 04:34:57 2009 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 8FC1A3A68D2 for ; Tue, 17 Mar 2009 04:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.054 X-Spam-Level: X-Spam-Status: No, score=-6.054 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNz5RPAgOw7s for ; Tue, 17 Mar 2009 04:34:56 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7293C3A67D6 for ; Tue, 17 Mar 2009 04:34:56 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 28D6427F32; Tue, 17 Mar 2009 12:35:38 +0100 (CET) X-AuditID: c1b4fb3e-af0a0bb0000023da-23-49bf7945f10c Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5BB612396E; Tue, 17 Mar 2009 11:19:49 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Mar 2009 11:19:33 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Mar 2009 11:19:32 +0100 Message-ID: <49BF7932.7000209@ericsson.com> Date: Tue, 17 Mar 2009 11:19:30 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Kent Watsen References: <49B79B0A.3040505@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Mar 2009 10:19:32.0305 (UTC) FILETIME=[DD0E1C10:01C9A6E9] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] issue with draft-ietf-netconf-partial-lock-07.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: Tue, 17 Mar 2009 11:34:57 -0000 Kent Watsen wrote: >> As I see the basic problem is that one node needs to be handled by >> multiple operators. > > Yes > > >> This >> means that each operator should only touch part of the configuration. > > Not necessarily - for two reasons: 1) the device's configuration data > model may not be hierarchically structured along "operator" boundaries > and 2) customers may deploy more than one applications/scripts that > having overlapping interest in the config BALAZS: Yes, the data models/ applications might follow your comments, but exactly these situations are the ones that lead to problems like overlapping writes that mess up each others stuff. So that is what we try to limit with locking. > > >> For the candidate this is more difficult as commit is global. > > Doesn't have to be - and, even if the device serializes the updates > internally, that doesn't have exposed via the NetConf model > BALAZS: Yes and no. You are right it could be done, however the WG decided not to do a partial commit. > >> However the working group decided that we do not want to provide > partial >> versions of other >> operations (commit, copy-config, delete-config, validate?). The > workgroup >> decided that partial >> locking as an optional feature is useful without other (new/updated) >> partial operations, so the >> WG does not want other partial operations as that would be a too big >> impact. > > Yes, we would need to have "partial-" variants of these other commands > as well > > >> I agree, partial-locking will be most useful for operators using the >> writable-running >> capability, but it can be used even for the candidate datastore. > > Yes, partial-lock can be used on a candidate datastore, but it never > would. Think about it - apps need to be 100% sure that they don't > commit unattended changes which, without a , means that > they would have to lock the entire config, which they would do using > NetConf's existing global-lock (not a bunch of partial-locks). So I > conclude that if partial-lock is ever be used on a candidate datastore, > it must be possible to do a partial-commit > BALAZS: Not exactly. If all applications lock the objects they are working on both in the candidate AND in RUNNING, then an application can not commit unfinished changes, as the other application doing those changes is still holding the lock on the running datastore. Still I fully agree that the partial-lock will be used mostly for the running datastore. Balazs From balazs.lengyel@ericsson.com Tue Mar 17 04:41:55 2009 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 EF74B3A6B65 for ; Tue, 17 Mar 2009 04:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.062 X-Spam-Level: X-Spam-Status: No, score=-6.062 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oo7V9LJ4DjNI for ; Tue, 17 Mar 2009 04:41:55 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id EE6D93A6B6C for ; Tue, 17 Mar 2009 04:41:54 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 645581980C4 for ; Tue, 17 Mar 2009 12:38:49 +0100 (CET) X-AuditID: c1b4fb3e-ac09abb0000023da-0d-49bf79c1beb3 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5844422C51 for ; Tue, 17 Mar 2009 11:21:53 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Mar 2009 11:21:51 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Mar 2009 11:21:51 +0100 Message-ID: <49BF79BF.90303@ericsson.com> Date: Tue, 17 Mar 2009 11:21:51 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf mailing list References: <20090304171501.98D7F3A6BA0@core3.amsl.com> <20090304.182737.97731960.mbj@tail-f.com> <20090304.212117.91501539.mbj@tail-f.com> In-Reply-To: <20090304.212117.91501539.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Mar 2009 10:21:51.0784 (UTC) FILETIME=[3030EA80:01C9A6EA] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-4741bis-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: Tue, 17 Mar 2009 11:41:56 -0000 Hello Martin, Jurgen, Where is the list of open issues for the 4741bis stored? Balazs Martin Bjorklund wrote: > Hi, > > I forgot to mention (maybe the obvious) that rfcdiff works fine on > this draft: > > http://tools.ietf.org/rfcdiff?url1=http://www.ietf.org/rfc/rfc4741.txt&url2=http://tools.ietf.org/id/draft-ietf-netconf-4741bis-00.txt > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From phil@juniper.net Tue Mar 17 08:00:30 2009 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 4F7FD28C14F for ; Tue, 17 Mar 2009 08:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKXT6fzj2lEn for ; Tue, 17 Mar 2009 08:00:29 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 332673A6B60 for ; Tue, 17 Mar 2009 08:00:28 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSb+7N+VBeOlbwHv54KeapL9Y3ZUHkv23@postini.com; Tue, 17 Mar 2009 08:01:11 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 17 Mar 2009 07:58:14 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 07:58:14 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 07:58:14 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 07:58:13 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2HEwDM63274; Tue, 17 Mar 2009 07:58:13 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n2HEpHdl077387; Tue, 17 Mar 2009 14:51:17 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200903171451.n2HEpHdl077387@idle.juniper.net> To: Balazs Lengyel In-Reply-To: <49BF7932.7000209@ericsson.com> Date: Tue, 17 Mar 2009 10:51:17 -0400 From: Phil Shafer X-OriginalArrivalTime: 17 Mar 2009 14:58:13.0503 (UTC) FILETIME=[CBAA70F0:01C9A710] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] issue with draft-ietf-netconf-partial-lock-07.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: Tue, 17 Mar 2009 15:00:30 -0000 Balazs Lengyel writes: >Still I fully agree that the partial-lock will be used mostly for the running datastore. Does/should the draft say this? Or talk about the dangers of using partial locks with :candidate? Thanks, Phil From kwatsen@juniper.net Wed Mar 18 11:28:05 2009 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 AE3E63A67E4 for ; Wed, 18 Mar 2009 11:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4noyzyEgm0B for ; Wed, 18 Mar 2009 11:28:05 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id B86C828C1D6 for ; Wed, 18 Mar 2009 11:28:04 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKScE9YWfgZRn2Phikd6m5CL3Wh8f/LjTG@postini.com; Wed, 18 Mar 2009 11:28:49 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 18 Mar 2009 11:27:28 -0700 From: Kent Watsen To: 'Balazs Lengyel' Date: Wed, 18 Mar 2009 11:27:28 -0700 Thread-Topic: [Netconf] issue with draft-ietf-netconf-partial-lock-07.txt Thread-Index: Acmm9ICiTmFKVB/cSMepXJLqPEv/5QA/VgKA Message-ID: <84600D05C20FF943918238042D7670FD35A9426EB6@EMBX01-HQ.jnpr.net> References: <49B79B0A.3040505@ericsson.com> <49BF7932.7000209@ericsson.com> In-Reply-To: <49BF7932.7000209@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] issue with draft-ietf-netconf-partial-lock-07.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: Wed, 18 Mar 2009 18:28:05 -0000 > > Yes, partial-lock can be used on a candidate datastore, but it never > > would. Think about it - apps need to be 100% sure that they don't > > commit unintended changes which, without a , means that > > they would have to lock the entire config, which they would do using > > NetConf's existing global-lock (not a bunch of partial-locks). So I > > conclude that if partial-lock is ever be used on a candidate datastore, > > it must be possible to do a partial-commit > > >=20 > BALAZS: Not exactly. If all applications lock the objects they are workin= g > on both in the > candidate AND in RUNNING, then an application can not commit unfinished > changes, as the other > application doing those changes is still holding the lock on the running > datastore. I do not understand - how does your suggestion help an application be sure = it's not committing unintended changes? Also, is it even possible? I mean, can devices advertize both :candidate a= nd :writable-running? - aren't those capabilities mutually exclusive? Thanks, Kent From mbj@tail-f.com Wed Mar 18 13:39:33 2009 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 5C2CD28C22E for ; Wed, 18 Mar 2009 13:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.079, 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 1r3YhkCWVsxI for ; Wed, 18 Mar 2009 13:39:32 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8EE4C28C223 for ; Wed, 18 Mar 2009 13:39:32 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id C04F376C557; Wed, 18 Mar 2009 21:40:15 +0100 (CET) Date: Wed, 18 Mar 2009 21:40:13 +0100 (CET) Message-Id: <20090318.214013.200215854.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <84600D05C20FF943918238042D7670FD35A9426EB6@EMBX01-HQ.jnpr.net> References: <49BF7932.7000209@ericsson.com> <84600D05C20FF943918238042D7670FD35A9426EB6@EMBX01-HQ.jnpr.net> X-Mailer: Mew version 6.0.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] issue with draft-ietf-netconf-partial-lock-07.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: Wed, 18 Mar 2009 20:39:33 -0000 Hi, Kent Watsen wrote: > Also, is it even possible? I mean, can devices advertize both :candidate and > :writable-running? - aren't those capabilities mutually exclusive? There's nothing in 4741 that says that they are mutually exclusive. And I don't think they should be. Some devices already support this combination. A related issue (on our list for 4741bis) is if the combination of :startup and :candidate is allowed. And even more interesting, if :startup, :candidate, and :confirmed-commit is allowed. More on this later - we should discuss it in some other thread. /martin From mehmet.ersue@nsn.com Thu Mar 19 12:45:05 2009 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 4C17D3A6888 for ; Thu, 19 Mar 2009 12:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.529 X-Spam-Level: X-Spam-Status: No, score=-5.529 tagged_above=-999 required=5 tests=[AWL=1.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUx2aMAS7-bI for ; Thu, 19 Mar 2009 12:45:04 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 2DC553A6860 for ; Thu, 19 Mar 2009 12:45:04 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n2JJjm4v026088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Mar 2009 20:45:48 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n2JJjlDC006786; Thu, 19 Mar 2009 20:45:47 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Mar 2009 20:45:47 +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: Thu, 19 Mar 2009 20:45:45 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Preparations for IETF-74 Thread-Index: Acmoxr5nirW5jWROQpKSWGpMr7BWsAAAz7pA From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 19 Mar 2009 19:45:47.0699 (UTC) FILETIME=[4CCB5030:01C9A8CB] Subject: [Netconf] FW: Preparations for IETF-74 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: Thu, 19 Mar 2009 19:45:05 -0000 =20 Hi All, if you are going to participate in the NETCONF Session at=20 IETF #74 please send a note to the WG chairs and volunteer=20 as minute taker (we need two) or Jabber scribe.=20 Minute taker and scribe get one beer if they volunteer before=20 the meeting, FCFS ;) Cheers,=20 Mehmet -----Original Message----- From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Thursday, March 19, 2009 8:13 PM To: Al Morton; Mani, Mahalingam (Mani); dorothy.gellert@nokia.com; Margaret Wasserman; Hannes Tschofenig; dave@frascone.com; Victor Fajardo; Peter Koch; Rob Austein; Peter Schoenmaker; Christopher Morrow; Juergen Quittek; Nevil Brownlee; tme@multicasttech.com; gjshep@gmail.com; Leonard Giuliano; bertietf@bwijnen.net; Ersue, Mehmet (NSN - DE/Munich); David Partain; Kessens, David (NSN - US/Atlanta); Joe Abley; Joel Jaeggli; Alan Clark; Bernard Aboba; David B. Nelson; Fred Baker; Kurt Erik Lindqvist Cc: Ronald Bonica Subject: Preparations for IETF-74 OPS WG Chairs, In a few days we shall meet for IETF-74. Here are a few reminders important for the success of your meetings:=20 - ensure before the meeting that you have designated notes takers and jabber scribes. We expect a higher than usual rate of remote participants, let us try to help them by ensuring that they can participate in an interactive manner providing inputs or asking questions by jabber - on the same line, please instruct participants in the meetings to speak close to the microphones, identify themselves and refer the slide they are using (if they speak over presentations) - ask for presentations to be forwarded or uploaded on the meeting Web site BEFORE the meeting starts - after the meting send to me and Ron the one paragraph report on the meeting, with any important messages or achievements you want the IESG and IAB to hear at the end of the IETF week - make sure that minutes are distributed for comments and then sent in time to proceedings@ietf.org A successful meeting to us all. See you on the dock of the Bay.=20 Dan From MARKSCOT@nortel.com Thu Mar 19 13:11:58 2009 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 159AE28C132 for ; Thu, 19 Mar 2009 13:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.554 X-Spam-Level: X-Spam-Status: No, score=-5.554 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWjQH+pHmRIN for ; Thu, 19 Mar 2009 13:11:54 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 968B628C0FE for ; Thu, 19 Mar 2009 13:11:54 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2JKCDk19913; Thu, 19 Mar 2009 20:12:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A8CE.E6DF1A09" Date: Thu, 19 Mar 2009 16:11:32 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC02792900@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] comment from monitoring draft, may require update in partial lock draft Thread-Index: AcmozuV168wWB150SAaETDDO0FKNiQ== From: "Mark Scott" To: "Balazs Lengyel" Cc: netconf@ietf.org Subject: [Netconf] comment from monitoring draft, may require update in partial lock draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 20:11:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A8CE.E6DF1A09 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Balazs, =20 One of the comments raised for 'draft-ietf-netconf-monitoring-v04' may require an update in raft-partial-lock as well. =20 The comment: "A description of lockId is needed to make it clear that it is the value returned by and the partial locking draft must be clarified that the lock id is globally unique within a NETCONF server so that it can actually serve as a key here without having to scope it by the sessionId." =20 I have addressed the first concern in the monitoring draft (v-04) in the model documentation. =20 I could not find anything in the partial locking draft (v-07) that addresses the second concern though. I.e. no indication of the uniqueness of the lock-id. =20 Can you comment on this point? =20 Thank you, Mark ------_=_NextPart_001_01C9A8CE.E6DF1A09 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Balazs,

 

One of the comments raised for = ‘draft-ietf-netconf-monitoring-v04’ may require an update in raft-partial-lock as well.

 

The comment:  “A description of lockId = is needed to make it clear that it is the value returned by <partial-lock> = and the partial locking draft must be clarified that the lock id is globally = unique within a NETCONF server so that it can actually serve as a key here = without having to scope it by the sessionId.”

 

I have addressed the first concern in the = monitoring draft  (v-04) in the model documentation.

 

I could not find anything in the partial locking = draft (v-07) that addresses the second concern though.  I.e. no indication of = the uniqueness of the lock-id.

 

Can you comment on this point?

 

Thank you,

Mark

------_=_NextPart_001_01C9A8CE.E6DF1A09-- From andy@netconfcentral.com Thu Mar 19 13:33:17 2009 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 5122A3A6878 for ; Thu, 19 Mar 2009 13:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.077, 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 0qwjno00hnpg for ; Thu, 19 Mar 2009 13:33:16 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id A3E5128C163 for ; Thu, 19 Mar 2009 13:33:16 -0700 (PDT) Received: (qmail 4542 invoked from network); 19 Mar 2009 20:34:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.242.36 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 19 Mar 2009 20:34:02 -0000 X-YMail-OSG: X.slzuwVM1kDk7QA4qbRBLextF8DKcG.fNxb3af8n_jpn4kv0owXwMltdKWIgyNISFy8925eENTSdTqQ_TzT4FUIEfS6Wm6mdyBXxJgj7GbNlnLGQhQI2HtfJ0Rl2TAxdqpUsySIyPe9OpIBYS.1DWTY X-Yahoo-Newman-Property: ymail-3 Message-ID: <49C2AC37.8020909@netconfcentral.com> Date: Thu, 19 Mar 2009 13:33:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Mark Scott References: <20090309234501.9601128C286@core3.amsl.com> <238C6E77EA42504DA038BAEE6D1C11EC02620D24@zcarhxm0.corp.nortel.com> In-Reply-To: <238C6E77EA42504DA038BAEE6D1C11EC02620D24@zcarhxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-monitoring-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 20:33:17 -0000 Mark Scott wrote: > Hello, > > The updated draft below addresses the comments received in the WGLC of > draft-ietf-netconf-monitoring-03. > > I have attached a document containing the responses to all comments > indicating: > - updated in v04 where applicable > - open item to be discussed at IETF74 > - item to be followed up on the mailing list > > If any comments on v03 were (unintentionally) missed please raise them > to my attention again. > > They will be addressed in v05 along with others comments received on v04 > (incl. those already raised by Andy - thanks!). > Thank you for your extensive summary of changes. Definitely counts as 'extra credit'. The only response I will make now is regarding per-session statistics. The argument that somebody could use a Sniffer (or RMON2) to monitor the NETCONF agent traffic instead, could be used to eliminate almost any 'monitoring MIB'. It does not hold in this case, because each entry has an counter. There is a global counter for as well. The same feature is needed for the rest of the global counters. There are only 8 more counters in the set that apply to every session. These should be maintained in each entry. > Mark Andy From MARKSCOT@nortel.com Thu Mar 19 14:14:49 2009 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 507D23A6BBD for ; Thu, 19 Mar 2009 14:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.076 X-Spam-Level: X-Spam-Status: No, score=-6.076 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UX2HHAyJbr1 for ; Thu, 19 Mar 2009 14:14:46 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id D2A813A69E0 for ; Thu, 19 Mar 2009 14:14:45 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2JLF5k05596 for ; Thu, 19 Mar 2009 21:15:05 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A8D7.D301B7AE" Date: Thu, 19 Mar 2009 17:15:25 -0400 Message-ID: <238C6E77EA42504DA038BAEE6D1C11EC02792A11@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Discussion Item: monitoring draft: single namespace assumption Thread-Index: Acmo19Ja2CXPtujSTH6Ve0CX451W/Q== From: "Mark Scott" To: Subject: [Netconf] Discussion Item: monitoring draft: single namespace assumption 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: Thu, 19 Mar 2009 21:14:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A8D7.D301B7AE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 During WGLC of "draft-itef-netconf-monitoring-v03" an item which raised which requires further discussion/consensus on the mailing list. =20 Original comment: "You make the assumption that a schema can only define one namespace. This might be OK but I wanted to spell this out so that the WG takes this design decision not by accident." =20 At present the monitoring draft definition is consistent 4741 which assumes a single namespace per capability. =20 Question to WG: Are we OK with this assumption, or should we consider extending the monitoring definition now to accommodate future support of multiple namespaces per schema? - Since this would impact other NETCONF items is this something better handled in netmod or 4741bis? =20 thank you, Mark ------_=_NextPart_001_01C9A8D7.D301B7AE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

During WGLC of = “draft-itef-netconf-monitoring-v03“ an item which raised which requires further discussion/consensus on the = mailing list.

 

Original comment:  “You make the = assumption that a schema can only define one namespace.  This might be OK but I = wanted to spell this out so that the WG takes this design decision not by = accident.”

 

At present the monitoring draft definition is = consistent 4741 which  assumes a single namespace per capability.

 

Question to WG:   Are we OK with this = assumption, or should we consider extending the monitoring definition now to = accommodate future support of multiple namespaces per schema?

-          Since this would impact other NETCONF items is = this something better handled in netmod or 4741bis?

 

thank you,

Mark

------_=_NextPart_001_01C9A8D7.D301B7AE-- From balazs.lengyel@ericsson.com Fri Mar 20 03:28:32 2009 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 296793A6AC2 for ; Fri, 20 Mar 2009 03:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.075 X-Spam-Level: X-Spam-Status: No, score=-6.075 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-Wrdv1gzp3o for ; Fri, 20 Mar 2009 03:28:31 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 54D763A6AE3 for ; Fri, 20 Mar 2009 03:28:31 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 51F5D2042A; Fri, 20 Mar 2009 11:29:16 +0100 (CET) X-AuditID: c1b4fb3e-ad794bb000007f6c-f9-49c36ffcd4d6 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 35E3D203D0; Fri, 20 Mar 2009 11:29:16 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Mar 2009 11:29:16 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Mar 2009 11:29:15 +0100 Message-ID: <49C36FFB.4050407@ericsson.com> Date: Fri, 20 Mar 2009 11:29:15 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: WashamFan References: <238C6E77EA42504DA038BAEE6D1C11EC02792900@zcarhxm0.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2009 10:29:15.0514 (UTC) FILETIME=[B7E9FDA0:01C9A946] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] comment from monitoring draft, may require update in partial lock draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 10:28:32 -0000 Hello, I will add to the partial-lock draft, that the lock-id is unique for the Netconf server and not just for sessions. + see below. Balazs WashamFan wrote: >> Hi Balazs, >> >> >> >> One of the comments raised for 'draft-ietf-netconf-monitoring-v04' may >> require an update in raft-partial-lock as well. >> >> >> >> The comment: "A description of lockId is needed to make it clear that >> it is the value returned by and the partial locking draft >> must be clarified that the lock id is globally unique within a NETCONF >> server so that it can actually serve as a key here without having to >> scope it by the sessionId." > > How to handle lockId=0 which represents a lock acquired buy non-NETCONF client? > I mean, all non-NETCONF locks would share the same lockId. BALAZS: Where did you see lock-id=0 in the draft? Session-id zero has a special meaning, but not the lock-id=0. From balazs.lengyel@ericsson.com Fri Mar 20 08:22:44 2009 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 B560928C162 for ; Fri, 20 Mar 2009 08:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.081 X-Spam-Level: X-Spam-Status: No, score=-6.081 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cu+bGtFX2SIO for ; Fri, 20 Mar 2009 08:22:43 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A0E683A6893 for ; Fri, 20 Mar 2009 08:22:43 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2A36C20517; Fri, 20 Mar 2009 16:23:29 +0100 (CET) X-AuditID: c1b4fb3e-ae0a9bb00000053c-67-49c3b4f1da00 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0A80720FF3; Fri, 20 Mar 2009 16:23:29 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Mar 2009 16:23:28 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Mar 2009 16:23:28 +0100 Message-ID: <49C3B4EF.3010101@ericsson.com> Date: Fri, 20 Mar 2009 16:23:27 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: WashamFan References: <238C6E77EA42504DA038BAEE6D1C11EC02792900@zcarhxm0.corp.nortel.com> <49C36FFB.4050407@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2009 15:23:28.0579 (UTC) FILETIME=[D1F5F130:01C9A96F] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] comment from monitoring draft, may require update in partial lock draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 15:22:44 -0000 WashamFan wrote: >>>> The comment: "A description of lockId is needed to make it clear >> that >>>> it is the value returned by and the partial locking >> draft >>>> must be clarified that the lock id is globally unique within a NETCONF >>>> server so that it can actually serve as a key here without having >> to >>>> scope it by the sessionId." >>> How to handle lockId=0 which represents a lock acquired buy >> non-NETCONF client? >>> I mean, all non-NETCONF locks would share the same lockId. >> BALAZS: Where did you see lock-id=0 in the draft? >> Session-id zero has a special meaning, but not the lock-id=0. > > Yes, you're right, I made a mistake. > But I still want to ask, is there any intention to monitor non-NETCONF > locks which share the same sessionId and no lockId? > As I see the use-case: I try to modify something, but I get back a message: write denied due to locking. The next logical step is to check who or what locked it. I am interested in all entities that can lock the datastore, because my work is blocked both if the lock is owned by a Netconf session or if is owned by the CLI. If in 50% of the cases I do not get information about existing locks, the functionality is unreliable (unusable?). Rfc4741 speaks about multi-protocol locks, so the data model about locks should also handle locks from all protocols. I think that non-Netconf locks SHOULD definitely be listed in the monitoring schema. IMO non-netconf locks should also have a non-zero lock-id. Why is that a difficult problem? What is the reason not to provide one? I also think non-netconf session SHOULD also be listed (with an Id) in the monitoring schema. What is the reason to omit them? Obviously the user is interested. Balazs From Washam.Fan@huaweisymantec.com Mon Mar 23 15:12:13 2009 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 50DCC3A690E for ; Mon, 23 Mar 2009 15:12:13 -0700 (PDT) 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_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 a1aT1zpqEWp7 for ; Mon, 23 Mar 2009 15:12:12 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 46BFA3A67F5 for ; Mon, 23 Mar 2009 15:12:12 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KGT0033338SGY20@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Fri, 20 Mar 2009 21:10:06 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KGT00G6838Q0D10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Fri, 20 Mar 2009 21:10:04 +0800 (CST) Received: from [121.101.220.178] by hstml01-in.huaweisymantec.com (mshttpd) ; Fri, 20 Mar 2009 21:10:02 +0800 From: WashamFan To: Balazs Lengyel Message-id: Date: Fri, 20 Mar 2009 21:10:02 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <49C36FFB.4050407@ericsson.com> References: <238C6E77EA42504DA038BAEE6D1C11EC02792900@zcarhxm0.corp.nortel.com> <49C36FFB.4050407@ericsson.com> Cc: netconf@ietf.org Subject: Re: [Netconf] comment from monitoring draft, may require update in partial lock draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 22:12:13 -0000 > >> The comment: "A description of lockId is needed to make it clear > that > >> it is the value returned by and the partial locking > draft > >> must be clarified that the lock id is globally unique within a NETCONF > >> server so that it can actually serve as a key here without having > to > >> scope it by the sessionId." > > > > How to handle lockId=0 which represents a lock acquired buy > non-NETCONF client? > > I mean, all non-NETCONF locks would share the same lockId. > > BALAZS: Where did you see lock-id=0 in the draft? > Session-id zero has a special meaning, but not the lock-id=0. Yes, you're right, I made a mistake. But I still want to ask, is there any intention to monitor non-NETCONF locks which share the same sessionId and no lockId? washam From Washam.Fan@huaweisymantec.com Mon Mar 23 17:55:59 2009 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 AC36E3A6A43 for ; Mon, 23 Mar 2009 17:55:59 -0700 (PDT) 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 DB7lsFUFrBJo for ; Mon, 23 Mar 2009 17:55:58 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id A347B3A67D9 for ; Mon, 23 Mar 2009 17:55:58 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KGS003RFOLWGY00@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Fri, 20 Mar 2009 15:53:58 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KGS00GPYOLUWE00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Fri, 20 Mar 2009 15:53:56 +0800 (CST) Received: from [10.27.154.59] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 20 Mar 2009 15:53:54 +0800 From: WashamFan To: Mark Scott Message-id: Date: Fri, 20 Mar 2009 15:53:54 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <238C6E77EA42504DA038BAEE6D1C11EC02792900@zcarhxm0.corp.nortel.com> References: <238C6E77EA42504DA038BAEE6D1C11EC02792900@zcarhxm0.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] comment from monitoring draft, may require update in partial lock draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 00:55:59 -0000 > Hi Balazs, > > > > One of the comments raised for 'draft-ietf-netconf-monitoring-v04' may > require an update in raft-partial-lock as well. > > > > The comment: "A description of lockId is needed to make it clear that > it is the value returned by and the partial locking draft > must be clarified that the lock id is globally unique within a NETCONF > server so that it can actually serve as a key here without having to > scope it by the sessionId." How to handle lockId=0 which represents a lock acquired buy non-NETCONF client? I mean, all non-NETCONF locks would share the same lockId. washam > I have addressed the first concern in the monitoring draft (v-04) in > the model documentation. > > > > I could not find anything in the partial locking draft (v-07) that > addresses the second concern though. I.e. no indication of the > uniqueness of the lock-id. > > > > Can you comment on this point? > > > > Thank you, > > Mark > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From Washam.Fan@huaweisymantec.com Mon Mar 23 22:13:51 2009 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 F059B3A68F9 for ; Mon, 23 Mar 2009 22:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 yuSNIGjRIUMq for ; Mon, 23 Mar 2009 22:13:50 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id E4D233A67D2 for ; Mon, 23 Mar 2009 22:13:49 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KGU004M090EMR40@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Sat, 21 Mar 2009 12:12:16 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KGU00A6B90AJ700@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 21 Mar 2009 12:12:14 +0800 (CST) Received: from [121.101.220.178] by hstml01-in.huaweisymantec.com (mshttpd) ; Sat, 21 Mar 2009 12:12:10 +0800 From: WashamFan To: Balazs Lengyel Message-id: Date: Sat, 21 Mar 2009 12:12:10 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <49C3B4EF.3010101@ericsson.com> References: <238C6E77EA42504DA038BAEE6D1C11EC02792900@zcarhxm0.corp.nortel.com> <49C36FFB.4050407@ericsson.com> <49C3B4EF.3010101@ericsson.com> Cc: netconf@ietf.org Subject: Re: [Netconf] comment from monitoring draft, may require update in partial lock draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 05:13:51 -0000 Hi, I also think it is helpful to monitor all locks supported by a device. Actually, we did a effort to address this concern by defining a portion of MIB. http://tools.ietf.org/html/draft-meng-fan-lock-mib-00 Well, I am not sure if NETCONF WG is a suitable place to accommodate the draft. washam > WashamFan wrote: > >>>> The comment: "A description of lockId is needed to make it > clear > >> that > >>>> it is the value returned by and the partial > locking > >> draft > >>>> must be clarified that the lock id is globally unique within a NETCONF > >>>> server so that it can actually serve as a key here without > having > >> to > >>>> scope it by the sessionId." > >>> How to handle lockId=0 which represents a lock acquired buy > >> non-NETCONF client? > >>> I mean, all non-NETCONF locks would share the same lockId. > >> BALAZS: Where did you see lock-id=0 in the draft? > >> Session-id zero has a special meaning, but not the lock-id=0. > > > > Yes, you're right, I made a mistake. > > But I still want to ask, is there any intention to monitor non-NETCONF > > locks which share the same sessionId and no lockId? > > > As I see the use-case: > I try to modify something, but I get back a message: write denied due > to locking. The next > logical step is to check who or what locked it. I am interested in all > entities that can lock > the datastore, because my work is blocked both if the lock is owned by > a Netconf session or if > is owned by the CLI. If in 50% of the cases I do not get information > about existing locks, the > functionality is unreliable (unusable?). > Rfc4741 speaks about multi-protocol locks, so the data model about > locks should also handle > locks from all protocols. > > I think that non-Netconf locks SHOULD definitely be listed in the > monitoring schema. > > IMO non-netconf locks should also have a non-zero lock-id. Why is that > a difficult problem? > What is the reason not to provide one? > > I also think non-netconf session SHOULD also be listed (with an Id) in > the monitoring schema. > What is the reason to omit them? Obviously the user is interested. > > Balazs From wwwrun@core3.amsl.com Wed Mar 25 08:58:35 2009 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id DBE6A3A6D33; Wed, 25 Mar 2009 08:58:35 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090325155835.DBE6A3A6D33@core3.amsl.com> Date: Wed, 25 Mar 2009 08:58:35 -0700 (PDT) Cc: Internet Architecture Board , netconf mailing list , netconf chair , RFC Editor Subject: [Netconf] Protocol Action: 'NETCONF Over Transport Layer Security (TLS)' to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:58:36 -0000 The IESG has approved the following document: - 'NETCONF Over Transport Layer Security (TLS) ' as a Proposed Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-07.txt Technical Summary The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to provide a secure connection for the transport of NETCONF messages. The mechanisms defined in this document include the support for certificate-based mutual authentication and key derivation, utilizing the protected ciphersuite negotiation, mutual authentication and key management capabilities of the TLS (Transport Layer Security) protocol. Working Group Summary Many WG member were thinking that password-based authentication is already handled well enough by the existing NETCONF transports (SSH and BEEP), and the NETCONF-over- TLS specification does not need to handle passwords. It has been recommended to scope the document to certificate- based authentication. There was also some controversy on the use of pre-shared keys (PSKs) derived from passwords. Based on this dicussion the Working Group decided to remove the text related to PSK based- authentication. See http://www.ietf.org/mail-archive/web/netconf/current/msg03856.html There was some controversal discussion about the Connection Closure. The consensus was that the document adopts the closure mechanism from draft-ietf-syslog-transport-tls-, Section 4.4. There was also some controversy about the use of a dedicated port of NETCONF over TLS. The consensus was that a dedicated port should be requested. The summary of the last changes can be found in: http://www.ietf.org/mail-archive/web/netconf/current/msg03873.html http://www.ietf.org/mail-archive/web/netconf/current/msg03882.html There were many WG members who did not strongly support or object to the document. Nobody objected to the document during or after the WGLC. The level of review in the WG was adequate , with several independent reviews by WG members. There is WG consensus to publish the document. Document Quality No vendors have announced that they will utilize this protocol. Two implementations with independent code-base and initiated by the document author are available as open source. The author ensures that the two implementations have been tested as interoperable. Personnel The document was reviewed by Eric Rescorla, Juergen Schoenwaelder, David Harrington, the WG security advisor Charlie Kaufman, and the security ADs Pasi Eronen and Tim Polk. Mehmet Ersue is the document shepherd, and Dan Romascanu the shepherding AD. RFC Editor Note Please make the following changes to draft-07: 1. In Section 2.1: OLD: Implementation of the protocol specified in this document MAY implement any TLS cipher suite that provides certificate-based mutual authentication [RFC5246]. NEW: Implementation of the protocol specified in this document MAY implement any TLS cipher suite that provides certificate-based mutual authentication [RFC5246]. The server MUST support certificate-based client authentication. 2. In Section 3.2 OLD: The server may have no external knowledge on client's identity and identity checks might not be possible (unless the client has a certificate chain rooted in an appropriate CA). If a server has knowledge on client's identity (typically from some source external to NETCONF or TLS) it MUST check the identity as described above. NEW: The server MUST verify the identity of the client with certificate-based authentication and according to local policy to ensure that the incoming client request is legitimate before any configuration or state data is sent to or received from the client. 3. In Section 4: OLD: This document in its current version does not support third party authentication due to the fact that TLS does not specify this way of authentication and that NETCONF depends on the transport protocol for the authentication service. If third party authentication is needed, BEEP or SSH transport can be used. NEW: This document in its current version does not support third party authentication (e.g., backend AAA servers) due to the fact that TLS does not specify this way of authentication and that NETCONF depends on the transport protocol for the authentication service. If third party authentication is needed, BEEP or SSH transport can be used. 4. Please create an Informative References section and move RFC4642 and RFC5277 from the Normative References section to this new section. From mehmet.ersue@nsn.com Wed Mar 25 09:44:54 2009 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 8C8AE3A6D57 for ; Wed, 25 Mar 2009 09:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=-0.975, 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 lyEi45KdY71B for ; Wed, 25 Mar 2009 09:44:53 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 4041B3A6D54 for ; Wed, 25 Mar 2009 09:44:52 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n2PGjhWu014536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 25 Mar 2009 17:45:43 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n2PGjh2d017937 for ; Wed, 25 Mar 2009 17:45:43 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 17:45:43 +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, 25 Mar 2009 17:45:38 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Protocol Action: 'NETCONF Over Transport Layer Security (TLS)' to Proposed Standard Thread-Index: AcmtYrOwKmiY+/lhT9qrpBxhPt7WBgABfFmg From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Netconf" X-OriginalArrivalTime: 25 Mar 2009 16:45:43.0450 (UTC) FILETIME=[23703FA0:01C9AD69] Subject: [Netconf] FW: Protocol Action: 'NETCONF Over Transport Layer Security (TLS)' to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 16:44:54 -0000 =20 Thank you to the editor and all who contributed to this work for completing this milestone.=20 Cheers,=20 Mehmet -----Original Message----- From: ext The IESG [mailto:iesg-secretary@ietf.org]=20 Sent: Wednesday, March 25, 2009 4:59 PM To: IETF-Announce Cc: Internet Architecture Board; RFC Editor; netconf mailing list; netconf chair Subject: Protocol Action: 'NETCONF Over Transport Layer Security (TLS)' to Proposed Standard=20 The IESG has approved the following document: - 'NETCONF Over Transport Layer Security (TLS) ' as a Proposed Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-07.txt Technical Summary The Network Configuration Protocol (NETCONF) provides=20 mechanisms to install, manipulate, and delete the=20 configuration of network devices. This document describes=20 how to use the Transport Layer Security (TLS) protocol to=20 provide a secure connection for the transport of NETCONF=20 messages. The mechanisms defined in this document include=20 the support for certificate-based mutual authentication and key=20 derivation, utilizing the protected ciphersuite negotiation,=20 mutual authentication and key management capabilities of=20 the TLS (Transport Layer Security) protocol. Working Group Summary Many WG member were thinking that password-based=20 authentication is already handled well enough by the existing=20 NETCONF transports (SSH and BEEP), and the NETCONF-over- TLS specification does not need to handle passwords. It has been recommended to scope the document to certificate- based authentication.=20 There was also some controversy on the use of pre-shared keys=20 (PSKs) derived from passwords. Based on this dicussion the=20 Working Group decided to remove the text related to PSK based- authentication. See http://www.ietf.org/mail-archive/web/netconf/current/msg03856.html =20 There was some controversal discussion about the Connection=20 Closure. The consensus was that the document adopts the closure=20 mechanism from draft-ietf-syslog-transport-tls-, Section 4.4.=20 =20 There was also some controversy about the use of a dedicated=20 port of NETCONF over TLS. The consensus was that a dedicated=20 port should be requested.=20 =20 The summary of the last changes can be found in: http://www.ietf.org/mail-archive/web/netconf/current/msg03873.html=20 http://www.ietf.org/mail-archive/web/netconf/current/msg03882.html=20 There were many WG members who did not strongly support or object=20 to the document. Nobody objected to the document during or after=20 the WGLC. The level of review in the WG was adequate , with several=20 independent reviews by WG members. There is WG consensus to publish =20 the document.=20 Document Quality No vendors have announced that they will utilize this protocol.=20 Two implementations with independent code-base and initiated by the=20 document author are available as open source. The author ensures=20 that the two implementations have been tested as interoperable. Personnel The document was reviewed by Eric Rescorla,=20 Juergen Schoenwaelder, David Harrington, the WG security advisor=20 Charlie Kaufman, and the security ADs Pasi Eronen and Tim Polk.=20 Mehmet Ersue is the document shepherd, and Dan Romascanu the=20 shepherding AD.=20 RFC Editor Note Please make the following changes to draft-07:=20 1. In Section 2.1: OLD: Implementation of the protocol specified in this document MAY implement any TLS cipher suite that provides certificate-based mutual authentication [RFC5246]. NEW: Implementation of the protocol specified in this document MAY implement any TLS cipher suite that provides certificate-based mutual authentication [RFC5246]. The server MUST support certificate-based client authentication.=20 2. In Section 3.2 OLD: The server may have no external knowledge on client's identity and identity checks might not be possible (unless the client has a certificate chain rooted in an appropriate CA). If a server has knowledge on client's identity (typically from some source external to NETCONF or TLS) it MUST check the identity as described above. NEW: The server MUST verify the identity of the client with certificate-based authentication and according to local policy to ensure that the incoming client request is legitimate before any configuration or state data is sent to or received from the client.=20 3. In Section 4:=20 OLD:=20 This document in its current version does not support third party authentication due to the fact that TLS does not specify this way of authentication and that NETCONF depends on the transport protocol for the authentication service. If third party authentication is needed, BEEP or SSH transport can be used. NEW:=20 This document in its current version does not support third party authentication (e.g., backend AAA servers) due to the fact that TLS does not specify this way of authentication and that NETCONF depends=20 on the transport protocol for the authentication service. If third=20 party authentication is needed, BEEP or SSH transport can be used. 4. Please create an Informative References section and move RFC4642 and RFC5277 from the Normative References section to this new section. From mehmet.ersue@nsn.com Wed Mar 25 10:52:07 2009 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 4ADCD28C236 for ; Wed, 25 Mar 2009 10:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=-0.936, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TGePGHY6Dzq for ; Wed, 25 Mar 2009 10:52:06 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 1F79F3A6976 for ; Wed, 25 Mar 2009 10:52:05 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n2PHqsbq011925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Mar 2009 18:52:54 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n2PHqrbQ014686; Wed, 25 Mar 2009 18:52:54 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 18:52:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AD72.8438D509" Date: Wed, 25 Mar 2009 18:52:51 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of NETCONF WG Session at IETF #74 Thread-Index: AcmtcoIOD8tb0TPXQ5ePba/KgXngHQ== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Romascanu, Dan (Dan)" X-OriginalArrivalTime: 25 Mar 2009 17:52:54.0010 (UTC) FILETIME=[85D6E5A0:01C9AD72] Cc: Ron Bonica , Netconf Subject: [Netconf] Summary of NETCONF WG Session at IETF #74 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, 25 Mar 2009 17:52:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AD72.8438D509 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan, please find below a short summary of the NETCONF WG session on TUESDAY, March 24, 2009, 1300-1500: - We had 40 persons in the 2 hour NETCONF session. - We reviewed the status of the WG - We went through the chartered WG items and had a good discussion and review of the documents. - NETCONF over TLS was in "AD followup" (in the mean time approved by IESG). - Partial Lock RPC is in "AD review". Two clarifications will be done in RFC editor's note. - For NETCONF Monitoring Schema is an update necessary after long issue discussion.=20 - 4741bis draft is rather new and there will be a few issue discussion on the maillist. - Parameter handling for With-defaults capability draft will be simplified. - Bob Cole presented on "Robust Configuration Management" which will be updated with NETCONF terminology. - The discussion on "Generic solution on message integrity" showed that there are two favored options: a) extending the security considerations section of SSH, b) introducing escaping mechanism for all transports using streaming. - There was a sense in the room for enabling YANG to define XML attributes based on YANG extensions and using YANG for the definition of NETCONF base module. Additional discussion in the NETMOD session the day after showed this again. Will be brought to the maillist for confirmation. Cheers, Bert & Mehmet ------_=_NextPart_001_01C9AD72.8438D509 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Summary of NETCONF WG Session at IETF #74

Hi = Dan,

please find below a = short summary of the NETCONF WG session on TUESDAY, March 24, 2009, = 1300-1500:

- We had 40 persons = in the 2 hour NETCONF session.
- We reviewed the = status of the WG
- We went through = the chartered WG items and had a good discussion and review of the = documents.

- NETCONF over TLS = was in "AD followup" (in the mean time approved by = IESG).
- Partial Lock RPC = is in "AD review". Two clarifications will be done in RFC = editor's note.
- For NETCONF = Monitoring Schema is an update necessary after long issue discussion. =
- 4741bis draft is = rather new and there will be a few issue discussion on the = maillist.
- Parameter = handling for With-defaults capability draft will be = simplified.

- Bob Cole = presented on "Robust Configuration Management" which will be = updated with NETCONF terminology.

- The discussion on = "Generic solution on message integrity" showed that there are = two favored options: a) extending the security considerations section of = SSH, b) introducing escaping mechanism for all transports using = streaming.

- There was a sense = in the room for enabling YANG to define XML attributes based on YANG = extensions and using YANG for the definition of NETCONF base module. = Additional discussion in the NETMOD session the day after showed this = again. Will be brought to the maillist for = confirmation.

Cheers,
Bert & = Mehmet


------_=_NextPart_001_01C9AD72.8438D509-- From balazs.lengyel@ericsson.com Wed Mar 25 17:58:12 2009 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 34D523A6D45 for ; Wed, 25 Mar 2009 17:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.087 X-Spam-Level: X-Spam-Status: No, score=-6.087 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNsztYLHrIti for ; Wed, 25 Mar 2009 17:58:11 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9F68E3A68C2 for ; Wed, 25 Mar 2009 17:57:47 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5C76E2030D for ; Thu, 26 Mar 2009 01:58:39 +0100 (CET) X-AuditID: c1b4fb3e-ae7babb000006d6d-2f-49cad33f11b4 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 447912010B for ; Thu, 26 Mar 2009 01:58:39 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Mar 2009 01:58:39 +0100 Received: from [127.0.0.1] ([159.107.194.84]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Mar 2009 01:58:38 +0100 Message-ID: <49CAD345.5060308@ericsson.com> Date: Thu, 26 Mar 2009 01:58:45 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Mar 2009 00:58:38.0642 (UTC) FILETIME=[FFA06920:01C9ADAD] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Updates to the Partial-Locking draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: balazs.lengyel@ericsson.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 00:58:12 -0000 Hello, Due to recent comments the following two changes are planned for the next version of the partial lock draft: Chapter 2.1. Overview add: Lock-id is unique for a NETCONF server for all partial-locks granted to any NETCONF or non-NETCONF sessions. Chapter 2.1.1. Usage Scenarios add: Partial locking is primarily useful towards the running configuration. However it can be used to lock a candidate datastore as well. Balazs From bertietf@bwijnen.net Wed Mar 25 19:27:36 2009 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 7A2B928C238 for ; Wed, 25 Mar 2009 19:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.267 X-Spam-Level: X-Spam-Status: No, score=-0.267 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mocTC-RF5Er for ; Wed, 25 Mar 2009 19:27:35 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 6DADF28C229 for ; Wed, 25 Mar 2009 19:27:35 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1LmfKU-0001h5-FD for netconf@ietf.org; Thu, 26 Mar 2009 03:28:27 +0100 Message-ID: From: "Bert Wijnen \(IETF\)" To: "netconf mailing list" References: <49CAD345.5060308@ericsson.com> In-Reply-To: <49CAD345.5060308@ericsson.com> Date: Wed, 25 Mar 2009 18:32:20 -0700 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_068F_01C9AD78.083AC5C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: Re: [Netconf] Updates to the Partial-Locking draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 02:27:36 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_068F_01C9AD78.083AC5C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speaking as WG chair and document shepherd... The document is in AD review, and once AD is happy he will probably = request IETF Last Call. I consider the below chjanges (as a result of comments we received after = handing the document to the AD) as editorial clarifications. SO I prefer them to be = conisdered as the first IETF LC comments. And we plan to resolve them with the text = proposed by Balazs. So if you see any serious issues with the proposed text, pls speak up ASAP, at the lastest by april 10th. Bert Wijnen document shepherd ----- Original Message -----=20 From: Balazs Lengyel=20 To: netconf mailing list=20 Sent: Wednesday, March 25, 2009 5:58 PM Subject: [Netconf] Updates to the Partial-Locking draft Hello, Due to recent comments the following two changes are planned for the = next version of the partial lock draft: Chapter 2.1. Overview add: Lock-id is unique for a NETCONF server for all partial-locks granted = to any NETCONF or non-NETCONF sessions. Chapter 2.1.1. Usage Scenarios add: Partial locking is primarily useful towards the running configuration. However it can be used to lock a candidate datastore as well. Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_068F_01C9AD78.083AC5C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Speaking as WG chair and document = shepherd...
 
The document is in AD review, and once AD is happy = he will=20 probably request IETF Last Call.
I consider the below chjanges (as a result of = comments we=20 received after handing the
document to the AD) as editorial clarifications. SO = I prefer=20 them to be conisdered as
the first IETF LC comments.  And we plan to = resolve them=20 with the text proposed by Balazs.
 
So if you see any serious issues with the proposed = text, pls=20 speak up
ASAP,  at the lastest by april = 10th.
 
Bert Wijnen
document shepherd
 
 
----- Original Message -----
From:=20 Balazs Lengyel
Sent: Wednesday, March 25, 2009 = 5:58=20 PM
Subject: [Netconf] Updates to = the=20 Partial-Locking draft

Hello,
Due to recent comments the following two = changes are=20 planned for the next version of the
partial lock = draft:

Chapter=20 2.1.  Overview add:
Lock-id is unique for a NETCONF server for = all=20 partial-locks granted to any NETCONF or
non-NETCONF=20 sessions.

Chapter 2.1.1.  Usage Scenarios add:
Partial = locking=20 is primarily useful towards the running configuration.
However it = can be=20 used to lock a candidate datastore as=20 = well.



Balazs


__________________________________= _____________
Netconf=20 mailing list
Netconf@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netconf
------=_NextPart_000_068F_01C9AD78.083AC5C0-- From bertietf@bwijnen.net Thu Mar 26 17:33:08 2009 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 BF0F63A685A for ; Thu, 26 Mar 2009 17:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.028 X-Spam-Level: * X-Spam-Status: No, score=1.028 tagged_above=-999 required=5 tests=[AWL=-1.130, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYDVZULHGJ6W for ; Thu, 26 Mar 2009 17:33:07 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 726003A6B26 for ; Thu, 26 Mar 2009 17:33:07 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1Ln01F-0001QE-MD for netconf@ietf.org; Fri, 27 Mar 2009 01:34:00 +0100 Message-ID: From: "Bert Wijnen \(IETF\)" To: "netconf mailing list" Date: Thu, 26 Mar 2009 17:33:52 -0700 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_09FA_01C9AE39.0796C4E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: [Netconf] Summary of action items, decisions, etc. from the NETCONF session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 00:33:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_09FA_01C9AE39.0796C4E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AIs, decisions, etc. from the NETCONF sessionWG participants, Here is a summary of actions, decisions and directions we took at our = meeting=20 at IETF74. Partial Lock:=20 - Balazs to prepare the text for the two clarifications=20 (lock-ID, Primary use case is for writable-running) to be used in=20 RFC editor's note. (to be done no later than next week; has been posted already) Monitoring:=20 - We need to ask Mark Scott whether he is able to continue to act as editor. If not we can ask Martin to pick up the pen. - Washam to bring his concern on missing monitoring of non-netconf locks to the maillist. =20 - Possible need for a string indicating which system or protocol is holding the lock.=20 - Martin to send the results of the counter discussion to the maillist=20 With-defaults:=20 - Balazs to simplify with-default values as proposed in the session = 4741bis:=20 - Decision on the validate operation handling:=20 Alternative 1: + 10, - 0 =20 Alternative 2: + 0=20 Alternative 2+ test option: + 7=20 Martin to bring it to maillist for confirmation and to bring text = proposals=20 for the discussed issues to the maillist.=20 rfc4741bis: - Martin will bring other 4741bis issues for discussion to the maillist. = =20 in the coming weeks in april. Other activities: - Bob Cole to update his draft to use the NETCONF terminology. Also to address all comments already raised during the presentation =20 - The discussion on "Generic solution on message integrity" showed that there are two favored options: a) extending the security considerations section of SSH, b) introducing escaping mechanism for all transports using = streaming. Interested parties to trigger a discussion on the maillist based on=20 a written draft.=20 - There was a sense in the room for enabling YANG to define XML=20 attributes based on YANG extensions and using YANG for the definition of NETCONF base module.=20 Additional discussion in the NETMOD session the day after=20 lead to a consensus in this direction.=20 Andy Bierman will bring the consensus in the NETMOD session=20 to the NETCONF maillist for confirmation.=20 Bert and Mehmet ------=_NextPart_000_09FA_01C9AE39.0796C4E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AIs, decisions, etc. from the NETCONF session
WG participants,
 
Here is a summary of actions, decisions and = directions we took=20 at our meeting
at IETF74.
 
Partial = Lock:=20
-  Balazs to prepare the = text for the=20 two clarifications
   = (lock-ID, Primary use=20 case is for writable-running) to be used in
   RFC = editor's=20 note.  (to be done no later than next week;
   has been = posted=20 already)
 
Monitoring:=20
- We need to ask Mark Scott = whether he is=20 able to continue to act
  as = editor. If not=20 we can ask Martin to pick up the pen.
- Washam=20 to bring his concern on missing monitoring of=20 non-netconf
  =  locks to=20 the maillist. 
-=20 Possible need for a string indicating which system or protocol=20 is
  holding the=20 lock.
- Martin to = send the=20 results of the counter discussion to the maillist =
 
With-defaults:=20
- Balazs to simplify = with-default values as=20 proposed in the session 4741bis:
-=20 Decision on the validate operation handling:
     Alternative 1: + = 10, -=20 0  
     Alternative 2: + 0 =
     Alternative 2+ = test option:=20 + 7
   = Martin to bring=20 it to maillist for confirmation and to bring text proposals=20
   = for the=20 discussed issues to the maillist.
 
rfc4741bis:
- Martin will bring other = 4741bis=20 issues for discussion to the maillist. 
  in the coming weeks in = april.
 
Other activities:
- Bob Cole to update = his=20 draft to use the NETCONF terminology.
   Also to = address all=20 comments already raised during the presentation
 
- The discussion on = "Generic=20 solution on message integrity" showed
   that = there are two=20 favored options:
    =  a)=20 extending the security considerations section of SSH,
    =  b)=20 introducing escaping mechanism for all transports using=20 streaming.
   = Interested=20 parties to trigger a discussion on the maillist based on=20
   a = written=20 draft.
 
- There was a sense = in the room for=20 enabling YANG to define XML
   = attributes based on=20 YANG extensions and using YANG for the
   definition of=20 NETCONF base module.
   = Additional discussion=20 in the NETMOD session the day after
   lead to = a consensus in=20 this direction.
   = Andy Bierman=20 will bring the consensus in the NETMOD session =
   to = the NETCONF=20 maillist for confirmation.
 
Bert and Mehmet
------=_NextPart_000_09FA_01C9AE39.0796C4E0-- From Washam.Fan@huaweisymantec.com Thu Mar 26 21:48:15 2009 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 6877D3A6971 for ; Thu, 26 Mar 2009 21:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 qPsudt3j7zPK for ; Thu, 26 Mar 2009 21:48:14 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 61EA83A6A16 for ; Thu, 26 Mar 2009 21:48:08 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KGS00FZBD10E730@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Fri, 20 Mar 2009 11:43:50 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KGS007M3D0YK400@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Fri, 20 Mar 2009 11:43:48 +0800 (CST) Received: from [10.27.154.59] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 20 Mar 2009 11:43:46 +0800 From: WashamFan To: Mark Scott Message-id: Date: Fri, 20 Mar 2009 11:43:46 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <238C6E77EA42504DA038BAEE6D1C11EC02792900@zcarhxm0.corp.nortel.com> References: <238C6E77EA42504DA038BAEE6D1C11EC02792900@zcarhxm0.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] comment from monitoring draft, may require update in partial lock draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 04:48:15 -0000 > Hi Balazs, > > > > One of the comments raised for 'draft-ietf-netconf-monitoring-v04' may > require an update in raft-partial-lock as well. > > > > The comment: "A description of lockId is needed to make it clear that > it is the value returned by and the partial locking draft > must be clarified that the lock id is globally unique within a NETCONF > server so that it can actually serve as a key here without having to > scope it by the sessionId." How to handle lockId=0 which represents a lock acquired buy non-NETCONF client? I mean, all non-NETCONF locks would share the same lockId. washam > I have addressed the first concern in the monitoring draft (v-04) in > the model documentation. > > > > I could not find anything in the partial locking draft (v-07) that > addresses the second concern though. I.e. no indication of the > uniqueness of the lock-id. > > > > Can you comment on this point? > > > > Thank you, > > Mark > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From andy@netconfcentral.com Thu Mar 26 23:26:12 2009 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 DDA5B3A699A for ; Thu, 26 Mar 2009 23:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kqA5vyU1ltT for ; Thu, 26 Mar 2009 23:26:11 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id A4A753A692D for ; Thu, 26 Mar 2009 23:26:11 -0700 (PDT) Received: (qmail 2124 invoked from network); 27 Mar 2009 06:27:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.243.9 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 27 Mar 2009 06:27:05 -0000 X-YMail-OSG: C4IZYLcVM1niYMB.ri6WtHq4nYpWy48y6r7ibtheQALoXXaE.xF7pvh6cUXkZUTNfAWtFgdOyp2zEI9A0yn927ZkAt5h3TXue.aDNObDyTQjuRY.mWQW7_Q2OLkjtaSG7L0u9747hT2BZ2zB.9Kga4yYg2WFK31BX1xADhGaUGQ.mlZwqTOmAA.E X-Yahoo-Newman-Property: ymail-3 Message-ID: <49CC71B7.3010000@netconfcentral.com> Date: Thu, 26 Mar 2009 23:27:03 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NETCONF Content-Type: multipart/mixed; boundary="------------050403070207090102020209" Subject: [Netconf] proposal for updated ietf-netconf-state.yang 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, 27 Mar 2009 06:26:12 -0000 This is a multi-part message in MIME format. --------------050403070207090102020209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Here is an update of the monitoring module with per-session statistics. I also changed some enums to identityrefs and marked some definitions that need to be moved to netconf.yang and imported. I did not make all the changes from the WG meeting, just a few of them. Here is a basic diff (yangdiff still not caught up to yang-04): // Generated by yangdiff 0.1.1 // old: ietf-netconf-state (2009-03-03) ietf-netconf-state.2009-03-03.yang // new: ietf-netconf-state (2009-03-26) ietf-netconf-state.2009-03-26.yang D revision '2009-03-03' A revision '2009-03-26' M typedef TransportType A description 'Base for all NETCONF...' M type from 'enumeration' to 'identityref' M typedef ProtocolType M type from 'enumeration' to 'identityref' M typedef SchemaFormat M type from 'enumeration' to 'identityref' A grouping CommonStatistics M container ietf-netconf-state M container sessions M list session A container sessionStatistics M container statistics M child node order Andy --------------050403070207090102020209 Content-Type: text/plain; name="ietf-netconf-state.2009-03-26.yang" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ietf-netconf-state.2009-03-26.yang" module ietf-netconf-state { namespace "urn:ietf:params:xml:ns:netconf:state"; prefix "ns"; import ietf-yang-types { prefix yang; } import ietf-inet-types { prefix inet; } organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: WG List: WG Chair: Mehmet Ersue WG Chair: Bert Wijnen Editor: Mark Scott "; description "NETCONF Monitoring Module. All elements in this module are read-only. Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; // RFC Ed.: replace XXXX with actual RFC number and remove this note revision 2009-03-26 { description "Initial revision, published as RFC XXXX."; // RFC Ed.: replace XXXX with actual RFC number // and remove this note } // *** BEGIN *** WILL BE IMPORTED FROM netconf.yang typedef SessionId { type uint32 { range "1..max"; } reference "RFC 4741: NETCONF Configuration Protocol"; } grouping NETCONFDatastoreType { description "Enumeration of possible NETCONF datastore types."; reference "RFC 4741: NETCONF Configuration Protocol"; choice datastore { mandatory true; leaf running { type empty; } leaf candidate { type empty; } leaf startup { type empty; } } } typedef TransportType { description "Base for all NETCONF transport types"; type identityref { base TransportIdentityType; } } identity TransportIdentityType { description "Base for all NETCONF transport types"; } identity SSH { base TransportIdentityType; reference "RFC 4742"; } identity Console { base TransportIdentityType; } identity HTTP { base TransportIdentityType; reference "RFC 4743"; } identity HTTPS { base TransportIdentityType; reference "RFC 4743"; } identity BEEP { base TransportIdentityType; reference "RFC 4744"; } identity SOAP { base TransportIdentityType; reference "RFC 4743"; } identity TLS { base TransportIdentityType; reference "draft-ietf-netconf-tls"; } // *** END: WILL BE IMPORTED FROM netconf.yang typedef ProtocolType { type identityref { base ProtocolIdentityType; } } identity ProtocolIdentityType { description "Base for all agent session protocol types"; } identity CLI { base ProtocolIdentityType; } identity NETCONF { base ProtocolIdentityType; reference "RFC 4741"; } identity WebUI { base ProtocolIdentityType; } typedef SchemaFormat { type identityref { base SchemaIdentifierFormat; } } identity SchemaIdentifierFormat { description "Base for all agent schema formats"; } identity XSD { base SchemaIdentifierFormat; reference "W3C REC REC-xmlschema-1-20041028"; } identity YANG { base SchemaIdentifierFormat; reference "draft-ietf-netmod-yang"; } identity RNG { base SchemaIdentifierFormat; reference "ISO/IEC 19757-2"; } grouping CommonStatistics { leaf inXMLParseErrors { type yang:zero-based-counter32; description "The total number of messages that were unparsable and thus ignored. This covers both unparsable 'hello' and 'rpc' messages."; } leaf inBadHellos { type yang:zero-based-counter32; description "The total number of sessions silently dropped because an invalid 'hello' message was received. This includes hello messages with a 'session-id' attribute, bad namespace, and bad capability declarations."; } leaf inRpcs { type yang:zero-based-counter32; description "The total number of rpc requests received."; } leaf inBadRpcs { type yang:zero-based-counter32; description "The total number of rpcs which were parsed correctly, but couldn't be serviced because they contained non-conformant XML, e.g. missing a mandatory parameter."; } leaf inNotSupportedRpcs { type yang:zero-based-counter32; description "The total number of rpcs which were parsed correctly, but couldn't be serviced because they were not supported by the agent."; } leaf outRpcReplies { type yang:zero-based-counter32; description "The total number of 'rpc-reply' messages sent."; } leaf outRpcErrors { type yang:zero-based-counter32; description "The total number of 'rpc-reply' messages with 'rpc-error' sent."; } } container ietf-netconf-state { config false; container capabilities { description "The list of currently provided NETCONF capabilities. This may be different than those exchanged during session setup (i.e. hello)."; leaf-list capability { type inet:uri; } } container datastores { description "List of NETCONF configuration datastores (e.g. running, startup, candidate) supported on this device and related information."; list datastore { container name { uses NETCONFDatastoreType; } container locks { description "An indication of whether a resource is locked or unlocked. If locked, additional information about the locking such as user an time stamp is provided."; grouping LockInfo { leaf lockedBySession { type SessionId; description "The session ID of the session that has locked this resource."; } leaf lockedTime { type yang:date-and-time; description "The date and time of when the resource was locked."; } } choice lockType { container globalLock { description "Present if the global lock is set."; uses LockInfo; } list partialLocks { key lockId; description "For a partial lock this is the lock id returned in the response."; leaf lockId { type uint32; } uses LockInfo; leaf-list select { type string; min-elements 1; description "The xpath expression which was used to request the lock."; } leaf-list lockedNodes { type instance-identifier; description "The list of instance-identifiers (i.e. the locked nodes)."; } } } } } } container schemas { list schema { key "identifier version format"; leaf identifier { type string; description "Identifier to uniquely reference the schema"; } leaf version { type string; description "Version of the schema supported. Multiple versions can be supported simultaneously."; } leaf format { type SchemaFormat; description "Schema language for the file/module."; } leaf namespace { type inet:uri; description "The XML namespace defined by the data model."; } leaf location { type union { type enumeration { enum "NETCONF"; } type inet:uri; } description "One or more Locations from which the schema can be retrieved. Can be either on the network device retrievable explicitly via the get-schema netconf operation (denoted by the value 'NETCONF') or some network location (i.e. URL)."; } } } container sessions { description "List of NETCONF sessions currently active on this device."; list session { key sessionId; leaf sessionId { type SessionId; } leaf transport { type TransportType; } leaf protocol { type ProtocolType; } leaf username { type string; } leaf sourceHost { type inet:host; } leaf loginTime { type yang:date-and-time; description "Time at which the session was established."; } container sessionStatistics { uses CommonStatistics; } } } container subscriptions { description "Contains information on the active subscriptions on the NETCONF server. Subscriptions which have ended are not reported."; list subscription { key sessionId; description "Information about Netconf Notification Subscriptions."; leaf sessionId { type SessionId; description "The session id associated with this subscription."; } leaf stream { type string; description "The stream associated with this subscription."; } anyxml filter { description "The filters associated with this subscription."; reference "RFC 4741: NETCONF Configuration Protocol"; } leaf startTime { type yang:date-and-time; description "The startTime parameter from the create-subscription invokation, if it was present."; } leaf stopTime { type yang:date-and-time; description "The stopTime parameter from the create-subscription invokation, if it was present."; } leaf outNotifications { type yang:zero-based-counter32; description "A count of event notifications sent along this connection since the subscription was created."; } } } container statistics { leaf netconfStartTime { type yang:date-and-time; description "Date and time at which the NETCONF server process was started. Allows for calculation of time interval for reported metrics."; } leaf inSessions { type yang:zero-based-counter32; description "The total number of NETCONF sessions started towards the NETCONF peer. inSessions - inBadHellos = 'number of correctly started netconf sessions'"; } uses CommonStatistics; leaf outNotifications { type yang:zero-based-counter32; description "The total number of 'notifications' messages sent."; } } } rpc get-schema { input { leaf identifier { type string; mandatory true; } leaf version { type string; mandatory true; } leaf format { type SchemaFormat; mandatory true; } } output { anyxml data { description "Contains the schema content."; } } } } --------------050403070207090102020209-- From Washam.Fan@huaweisymantec.com Fri Mar 27 13:08:24 2009 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 6D3313A6979 for ; Fri, 27 Mar 2009 13:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlF1O0bW+0he for ; Fri, 27 Mar 2009 13:08:23 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 805533A6857 for ; Fri, 27 Mar 2009 13:08:23 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KH600GDJLBEVW00@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 28 Mar 2009 04:09:15 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KH600KZNLBCT500@hstml02-in.huaweisymantec.com> for netconf@ietf.org; Sat, 28 Mar 2009 04:09:13 +0800 (CST) Received: from [203.86.77.51] by hstml02-in.huaweisymantec.com (mshttpd); Sat, 28 Mar 2009 04:09:12 +0800 From: WashamFan To: netconf@ietf.org Message-id: Date: Sat, 28 Mar 2009 04:09:12 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal Subject: [Netconf] sessionId issue 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, 27 Mar 2009 20:08:24 -0000 Hi, There were 2 issues: 1) sessionId=0 for all non-netconf sessions. 2) lockId is unique for all netconf locks. After clarification wrt/ 2), now 2*) lockId is unique for all locks (including both netconf and non-netconf locks). But, how about 1)? sec2.1.4, monitoring-04: Session data pertaining to the NETCONF server. Includes data for NETCONF and non-NETCONF management sessions. sessionId is used as the key amongst sessions, but it can't be the key based on 1). washam From Washam.Fan@huaweisymantec.com Fri Mar 27 13:10:20 2009 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 F19923A698E for ; Fri, 27 Mar 2009 13:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKeZjJcJhXS6 for ; Fri, 27 Mar 2009 13:10:19 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id D96A93A6974 for ; Fri, 27 Mar 2009 13:10:18 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KH600GDLLENVW00@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 28 Mar 2009 04:11:12 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KH600J08LEMJC10@hstml02-in.huaweisymantec.com> for netconf@ietf.org; Sat, 28 Mar 2009 04:11:11 +0800 (CST) Received: from [203.86.77.51] by hstml02-in.huaweisymantec.com (mshttpd); Sat, 28 Mar 2009 04:11:10 +0800 From: WashamFan To: netconf@ietf.org Message-id: Date: Sat, 28 Mar 2009 04:11:10 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal Subject: [Netconf] Non-Netconf lock monitoring 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, 27 Mar 2009 20:10:20 -0000 Hi, When multiple NM protocols are supported by a device, all locks acquired via all supported protocols should be monitored in a consistent way. We should identify each lock whatever protocol is used to control the lock. If I understand correctly, lockId is used to differentiate all locks including both Netconf and non-Netconf ones. That is good, but maybe not enough. We still should provide some information which is expected to be used for releasing a lock by force. sessionId is used to release a Netconf lock via , but IIRC, sessionId=0 for all non-Netconf sessions. Please refer to another thread discussing sessionId issue. I co-author a mib draft to model multiplex protocols supported locks monitoring,, I think it is of value to this issue. And I want to ask if Netconf WG is a suitable place to accommodate the draft. washam From balazs.lengyel@ericsson.com Mon Mar 30 08:59:24 2009 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 1D2CA3A6A71 for ; Mon, 30 Mar 2009 08:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.097 X-Spam-Level: X-Spam-Status: No, score=-6.097 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soOhZdZOQKBm for ; Mon, 30 Mar 2009 08:59:20 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 32D733A68DC for ; Mon, 30 Mar 2009 08:59:20 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 85FA2210DA; Mon, 30 Mar 2009 18:00:15 +0200 (CEST) X-AuditID: c1b4fb3c-ae760bb000003f6e-6b-49d0df72b5f0 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4AF1222725; Mon, 30 Mar 2009 17:04:18 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 17:04:05 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 17:04:05 +0200 Message-ID: <49D0DF65.6080308@ericsson.com> Date: Mon, 30 Mar 2009 17:04:05 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: WashamFan References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2009 15:04:05.0530 (UTC) FILETIME=[C4DC3FA0:01C9B148] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Non-Netconf lock monitoring 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, 30 Mar 2009 15:59:24 -0000 Hello Washam, I agree, that the netconf monitoring draft should include both non-netconf locks, and non-netconf sessions. If you write such a MIB, it should have the same structure and content as the relevant part of the netconf-monitoring YAM. Balazs WashamFan wrote: > Hi, > > When multiple NM protocols are supported by a device, all locks acquired via all supported protocols should be monitored in a consistent way. > > We should identify each lock whatever protocol is used to control the lock. If I understand correctly, lockId is used to differentiate all locks including both Netconf and non-Netconf ones. That is good, but maybe not enough. > > We still should provide some information which is expected to be used for releasing a lock by force. sessionId is used to release a Netconf lock via , but IIRC, > sessionId=0 for all non-Netconf sessions. Please refer to another thread discussing > sessionId issue. > > I co-author a mib draft to model multiplex protocols supported locks monitoring,, I think it > is of value to this issue. And I want to ask if Netconf WG is a suitable place to accommodate the draft. > > washam > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From balazs.lengyel@ericsson.com Mon Mar 30 09:00:30 2009 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 E47AD3A6BA3 for ; Mon, 30 Mar 2009 09:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfialZYQyWP2 for ; Mon, 30 Mar 2009 09:00:30 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0002B3A6B00 for ; Mon, 30 Mar 2009 09:00:29 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A7898223A3; Mon, 30 Mar 2009 18:01:26 +0200 (CEST) X-AuditID: c1b4fb3c-aaf59bb000003f6e-68-49d0e018bffb Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7659F22917; Mon, 30 Mar 2009 17:07:04 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 17:06:39 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 17:06:39 +0200 Message-ID: <49D0DFFF.4090501@ericsson.com> Date: Mon, 30 Mar 2009 17:06:39 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: WashamFan References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2009 15:06:39.0573 (UTC) FILETIME=[20AD5850:01C9B149] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] sessionId issue 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, 30 Mar 2009 16:00:31 -0000 I would rather have the sessionId unique for ALL sessions as well. What to do with SNMP and alike that doesn't really have a session just a UDP packet is an interesting issue? Balazs WashamFan wrote: > Hi, > > There were 2 issues: > 1) sessionId=0 for all non-netconf sessions. > 2) lockId is unique for all netconf locks. > > After clarification wrt/ 2), now > 2*) lockId is unique for all locks (including both netconf and non-netconf locks). > > But, how about 1)? > > sec2.1.4, monitoring-04: > > Session data pertaining to the NETCONF server. Includes data > for NETCONF and non-NETCONF management sessions. > > sessionId is used as the key amongst sessions, but it can't be the key based on 1). > > washam > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com