From mbj@tail-f.com Thu Oct 1 00:54: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 56F783A6897 for ; Thu, 1 Oct 2009 00:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.109, 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 bWP1fLrBMyXg for ; Thu, 1 Oct 2009 00:54:11 -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 7D8983A67F2 for ; Thu, 1 Oct 2009 00:54:11 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 24F0376C5F4; Thu, 1 Oct 2009 09:55:35 +0200 (CEST) Date: Thu, 01 Oct 2009 09:55:34 +0200 (CEST) Message-Id: <20091001.095534.246657446.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20091001065528.GB29299@elstar.local> References: <20090928190418.GB23637@elstar.local> <20091001.084305.213686165.mbj@tail-f.com> <20091001065528.GB29299@elstar.local> 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 draft-ietf-netconf-monitoring-08 X-BeenThere: netconf@ietf.org X-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, 01 Oct 2009 07:54:12 -0000 Juergen Schoenwaelder wrote: > On Thu, Oct 01, 2009 at 08:43:05AM +0200, Martin Bjorklund wrote: > > > > I am wondering why you use zero-based-counter32 and not just > > > counter32. Do we worry about the fact that this might rollover and > > > become ambiguous? > > > > This way you can easily see if e.g. any errors has happend in a > > session. You know that it starts from 0 when the session starts. > > This is true only under the assumption that the counter did never roll > over in a session. Is this assumption reasonable to make for the > counters? If the client knows that it has sent less than 2^32 rpcs on a session, yes. /martin From j.schoenwaelder@jacobs-university.de Thu Oct 1 03:36: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 1221D3A6859 for ; Thu, 1 Oct 2009 03:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.138, 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 yLOZb8XQik3u for ; Thu, 1 Oct 2009 03:36:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DD8853A6858 for ; Thu, 1 Oct 2009 03:36:11 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DFCACC0012; Thu, 1 Oct 2009 12:37:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id H-DHiAl0g5n4; Thu, 1 Oct 2009 12:37:34 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 39EDBC0021; Thu, 1 Oct 2009 12:37:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E4CE2D0ABE3; Thu, 1 Oct 2009 12:37:32 +0200 (CEST) Date: Thu, 1 Oct 2009 12:37:32 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091001103732.GA29496@elstar.local> Mail-Followup-To: Martin Bjorklund , "markscot@nortel.com" , "netconf@ietf.org" References: <20090928190418.GB23637@elstar.local> <20091001.084305.213686165.mbj@tail-f.com> <20091001065528.GB29299@elstar.local> <20091001.095534.246657446.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091001.095534.246657446.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Comments on draft-ietf-netconf-monitoring-08 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: Thu, 01 Oct 2009 10:36:13 -0000 On Thu, Oct 01, 2009 at 09:55:34AM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Oct 01, 2009 at 08:43:05AM +0200, Martin Bjorklund wrote: > > > > > > I am wondering why you use zero-based-counter32 and not just > > > > counter32. Do we worry about the fact that this might rollover and > > > > become ambiguous? > > > > > > This way you can easily see if e.g. any errors has happend in a > > > session. You know that it starts from 0 when the session starts. > > > > This is true only under the assumption that the counter did never roll > > over in a session. Is this assumption reasonable to make for the > > counters? > > If the client knows that it has sent less than 2^32 rpcs on a session, > yes. I am actually more concerned about this: container statistics { // ... uses CommonCounters { description "Global counters, accumulated from all sessions."; } } /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Thu Oct 1 05:17: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 2C31928C220 for ; Thu, 1 Oct 2009 05:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[AWL=-0.670, 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 yXd3QfQrGD0S for ; Thu, 1 Oct 2009 05:17:49 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id DFD5C2946E2 for ; Thu, 1 Oct 2009 05:05:21 -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 n91C6hAX031646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 Oct 2009 14:06:43 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n91C6hFY032734; Thu, 1 Oct 2009 14:06:43 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 14:06:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Oct 2009 14:06:41 +0200 Message-ID: In-Reply-To: <20091001.084305.213686165.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Comments on draft-ietf-netconf-monitoring-08 Thread-Index: AcpCYnIagQDoP0b9R2+BZa1pW1+P5AAK+iCA References: <085091CB2CA14E4B8B163FFC37C84E9D1A784EC0@zcarhxm0.corp.nortel.com><20090928190418.GB23637@elstar.local> <20091001.084305.213686165.mbj@tail-f.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Martin Bjorklund" , X-OriginalArrivalTime: 01 Oct 2009 12:06:43.0000 (UTC) FILETIME=[A3D6CB80:01CA428F] Cc: netconf@ietf.org Subject: Re: [Netconf] Comments on draft-ietf-netconf-monitoring-08 X-BeenThere: netconf@ietf.org X-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, 01 Oct 2009 12:17:50 -0000 Hi, > > Furthermore, we > > should import relevant types from ietf-netconf (SessionId=20 > can clearly > > be imported). The NETCONFDatastoreType should probably be=20 > provided by > > ietf-netconf (after renaming). >=20 > I agree in principle, but that would mean that this document will wait > not only for YANG, but also for rfc4741bis. Do we want to do that? I wouldn't mind to define NETCONFDatastoreType in=20 the monitoring draft based on RFC4741. I think it is good if we can avoid any additional=20 dependencies and delay. Cheers, Mehmet =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Martin Bjorklund > Sent: Thursday, October 01, 2009 8:43 AM > To: j.schoenwaelder@jacobs-university.de > Cc: netconf@ietf.org > Subject: Re: [Netconf] Comments on draft-ietf-netconf-monitoring-08 >=20 > Hi, >=20 > I will comment on some of your issues, and let Mark reply to the > others. >=20 >=20 > Juergen Schoenwaelder wrote: > > On Mon, Sep 28, 2009 at 07:05:15PM +0200, Mark Scott wrote: > > =20 > > > This version addresses action items from IETF75 and mailing list > > > comments. Most significant is the decision to adopt YANG as > > > normative for this draft. > >=20 > > I still do not like the capitalized identifiers. >=20 > +1 >=20 > > Furthermore, we > > should import relevant types from ietf-netconf (SessionId=20 > can clearly > > be imported). The NETCONFDatastoreType should probably be=20 > provided by > > ietf-netconf (after renaming). >=20 > I agree in principle, but that would mean that this document will wait > not only for YANG, but also for rfc4741bis. Do we want to do that? >=20 > > I am wondering why you use zero-based-counter32 and not just > > counter32. Do we worry about the fact that this might rollover and > > become ambiguous? >=20 > This way you can easily see if e.g. any errors has happend in a > session. You know that it starts from 0 when the session starts. >=20 > > I think all definitions should have proper descriptions.=20 > Not all have > > them. > >=20 > > What is the reason to define groupings inline? >=20 > Do you prefer to export all groupings? >=20 >=20 > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From andy@netconfcentral.com Thu Oct 1 06:00: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 1053528C0EC for ; Thu, 1 Oct 2009 06:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_74=0.6, UNPARSEABLE_RELAY=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 Qzo9sApyW9oq for ; Thu, 1 Oct 2009 06:00:04 -0700 (PDT) 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 45DB428C0E6 for ; Thu, 1 Oct 2009 06:00:04 -0700 (PDT) Received: (qmail 4568 invoked from network); 1 Oct 2009 13:01:26 -0000 Received: from adsl-68-120-81-206.dsl.irvnca.pacbell.net (andy@68.120.81.206 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 01 Oct 2009 06:01:26 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 6Ndnz0AVM1nJT2adMUt9A9Qcs9gYrcayMbvkW09_m_ejkm.3v2jJFVAl65GC3KmprglMxfsCqk_pDqetfjpUQm8tgfA8pqrV4uB7CmAsy_ogPyP39EUW1UNIfztyNNhn1axhEamgFpOs5TiglOtbNxJ7so942baMXaEBV6ZNyay38P8nPPogQ4ezrnOaCBBpIydX4ceFciclUvXdJrP.i7n1REdO_XBoceJUdm6.zaCaZSjUFYYLQUq92jHWwvXdKcO8n5_E7z8hBZ7QdUKpHToewhP5LTkQ706mVkszpubLoffp2x7yQnnQQJckUw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AC4A86E.6000701@netconfcentral.com> Date: Thu, 01 Oct 2009 06:02:38 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4AC0ED35.3070404@netconfcentral.com> <20091001.083617.169773375.mbj@tail-f.com> In-Reply-To: <20091001.083617.169773375.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] comments on monitoring-08 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, 01 Oct 2009 13:00:05 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> I noticed that the 'transport' identity was replaced >> with a 'session-type' identity, and now the >> /sessions/session/transport leaf >> has been changed to a session-type leaf. Yet no new >> standard identities were added, and no semantics were >> altered. > > Right, this was just a name change of the identity. > >> I object to this gratuitous incompatible change with -07. >> It looks like some tweaks to support proprietary data models. > > I don't understand how changing the name of a data type is a tweak for > proprietary data models. > Why was it changed at all? The leaf changed names, not just the data type. > The only reason we changed this name was that the old name, > 'transport' has too many connotations. In NETCONF, SSH is a > transport, but for the purpose of this document we say that > netconf-ssh is a session-type. I can't find any discussion in the ML archive on this topic. Since all changes are this point are made through WGLC resolution procedures, I assume there was a request to make this change, which was supported on the mailing list and confirmed by one of the co-Chairs. I can't find any of that email. It looks like you just decided to change the name of the identity and the leaf that uses it, on your own. We use the term "transport" in our NETCONF layer cake diagram. The term "session type" is nowhere to be found in any of our RFCs or I-Ds. The enums exactly match the list of transports available for NETCONF. > >> IMO, the vendor should augment the entry with a different leaf. >> I really want to know the transport, not some meaningless >> 'session type' that happens to look like a transport type. >> >> Also, I thought we were going to make the get-schema/input/version >> parameter optional, and add a default=YANG to the format >> parameter. > > I agree with you. > I never saw 1 objection to making this change. Again, where is the email documenting the co-Chairs decision to exclude this change? >> Instead the /sessions/session/loginTime was >> changed to mandatory. > > Do you think it should be mandatory false? If so, why? Should any > other leaf be mandatory true? > this leaf is fine as mandatory. > > /martin > Andy From mark@ellisonsoftware.com Thu Oct 1 08:45: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 2FBE53A6AB9 for ; Thu, 1 Oct 2009 08:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.864 X-Spam-Level: X-Spam-Status: No, score=-101.864 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 011s0Dk9CNnb for ; Thu, 1 Oct 2009 08:45:13 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 3C2323A6AA4 for ; Thu, 1 Oct 2009 08:45:12 -0700 (PDT) Received: by bwz6 with SMTP id 6so239321bwz.37 for ; Thu, 01 Oct 2009 08:46:34 -0700 (PDT) MIME-Version: 1.0 Sender: mark@ellisonsoftware.com Received: by 10.204.156.3 with SMTP id u3mr106196bkw.179.1254411994036; Thu, 01 Oct 2009 08:46:34 -0700 (PDT) Date: Thu, 1 Oct 2009 11:46:33 -0400 X-Google-Sender-Auth: 633653223b94b884 Message-ID: <8a0268750910010846v3fb2dedataa1d461b579dde73@mail.gmail.com> From: Mark Ellison To: netconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Netconf] and remote URLs X-BeenThere: netconf@ietf.org X-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, 01 Oct 2009 15:45:14 -0000 Regarding use of URL in the protocol operation: sxn 7.2., "" - states "...such as using a local file, a remote file, or inline." Within section 8.8. "URL capability", section 8.8.5.1 "" states, "If the element is specified, then it should identify a local configuration file." My best guess at interpreting the intent would be that 8.8.5.1 suggests that a URL *target* in an operation should be a file that is local to the NETCONF server. And, I assume that a URL *source* in an operation may be a file that is local or remote to the NETCONF server. I would appreciate clarification on this issue and apologize if this issue was previously discussed on the NETCONF email listserv. Regards, Mark From MARKSCOT@nortel.com Thu Oct 1 11:32: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 256493A6995 for ; Thu, 1 Oct 2009 11:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.074 X-Spam-Level: X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_74=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 NDN77gXsaXAj for ; Thu, 1 Oct 2009 11:31:59 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E4CEE3A6885 for ; Thu, 1 Oct 2009 11:31:58 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n91IWhD25191; Thu, 1 Oct 2009 18:32:43 GMT 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, 1 Oct 2009 14:32:41 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D1A806F54@zcarhxm0.corp.nortel.com> In-Reply-To: <4AC4A86E.6000701@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NETCONF] mandatory parms discussion Thread-Index: AcpCl082p/TRSGwNRUqn4yH+p1diRQALOdEA References: <4AC0ED35.3070404@netconfcentral.com><20091001.083617.169773375.mbj@tail-f.com> <4AC4A86E.6000701@netconfcentral.com> From: "Mark Scott" To: "Andy Bierman" , "Martin Bjorklund" Cc: netconf@ietf.org Subject: [Netconf] [NETCONF] mandatory parms discussion X-BeenThere: netconf@ietf.org X-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, 01 Oct 2009 18:32:00 -0000 Andy, A rationale for not modifying the mandatory parameters in was posted to the ML on Sept 16th. I suspect you missed that based on the comment below so I am repeating it here for further discussion: "2. mandatory parameters: Initially was the only mandatory parameter in the operation, however after we agreed to expand the key definition in the schema list we made and mandatory parameters in the operation. My preference would be to keep this alignment between the key and mandatory parms. I agree in cases where only 1 revision and/or 1 format exists this is heavy-handed but it protects against agents returning schema a manager may not have intended since is not unique in schema list and the logic on agent to select the default revision may differ from what the manager would have selected (esp. if more than 1 version exists)." Previously no one else had objected to these being mandatory parameters and no ML consensus had been reached to modify it. I have changed the subject header of this email in an attempt to initiate a ML discussion and will update the draft based on consensus. Mark >> >> Also, I thought we were going to make the get-schema/input/version >> parameter optional, and add a default=3DYANG to the format >> parameter. >=20 > I agree with you. >=20 I never saw 1 objection to making this change. Again, where is the email documenting the co-Chairs decision to exclude this change? From mbj@tail-f.com Thu Oct 1 13:52: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 0CB593A6840 for ; Thu, 1 Oct 2009 13:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.029, 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 9yrHFbtIaAqY for ; Thu, 1 Oct 2009 13:52:27 -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 3726D3A63EB for ; Thu, 1 Oct 2009 13:52:27 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 2F07C61602B; Thu, 1 Oct 2009 22:53:52 +0200 (CEST) Date: Thu, 01 Oct 2009 22:53:51 +0200 (CEST) Message-Id: <20091001.225351.77770924.mbj@tail-f.com> To: ellison@ieee.org From: Martin Bjorklund In-Reply-To: <8a0268750910010846v3fb2dedataa1d461b579dde73@mail.gmail.com> References: <8a0268750910010846v3fb2dedataa1d461b579dde73@mail.gmail.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] and remote URLs X-BeenThere: netconf@ietf.org X-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, 01 Oct 2009 20:52:28 -0000 Mark Ellison wrote: > Regarding use of URL in the protocol operation: > > sxn 7.2., "" - states "...such as using a local file, a > remote file, or inline." > > Within section 8.8. "URL capability", section 8.8.5.1 "" > states, "If the element is specified, then it should identify a > local configuration file." > > My best guess at interpreting the intent would be that 8.8.5.1 > suggests that a URL *target* in an operation should be > a file that is local to the NETCONF server. And, I assume that a URL > *source* in an operation may be a file that is local or > remote to the NETCONF server. I think 8.8.5.1 is pretty clear. It says: 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. I.e. the *source* url should be a local file. According to 8.8.5.1, using url as a *target* is not supported at all. 7.2. also does not allow a url as target, but it does say: This operation allows the new configuration to be expressed in ^^^^^^^^^^^^^^^^^ several ways, such as using a local file, a remote file, or inline. So the word "remote file" in 7.2 contradicts the text in 8.8.5.1, and it also contradicts the next paragraph in 7.2. However, it is not clear to me why the edit-config source url should be a local file. The copy-config operation does not have such a restriction. I don't think edit-config of a *target* url was ever intended to be supported. /martin From mark@ellisonsoftware.com Thu Oct 1 14:29: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 470D73A68B9 for ; Thu, 1 Oct 2009 14:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.877 X-Spam-Level: X-Spam-Status: No, score=-101.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CGKWc-RfvNl for ; Thu, 1 Oct 2009 14:29:28 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 2B1393A67B3 for ; Thu, 1 Oct 2009 14:29:27 -0700 (PDT) Received: by bwz6 with SMTP id 6so502954bwz.37 for ; Thu, 01 Oct 2009 14:30:50 -0700 (PDT) MIME-Version: 1.0 Sender: mark@ellisonsoftware.com Received: by 10.204.0.69 with SMTP id 5mr399619bka.173.1254432650501; Thu, 01 Oct 2009 14:30:50 -0700 (PDT) In-Reply-To: <20091001.225351.77770924.mbj@tail-f.com> References: <8a0268750910010846v3fb2dedataa1d461b579dde73@mail.gmail.com> <20091001.225351.77770924.mbj@tail-f.com> Date: Thu, 1 Oct 2009 17:30:50 -0400 X-Google-Sender-Auth: 2ff0f7285657cec9 Message-ID: <8a0268750910011430k1d7b855cr27c5225a1f386305@mail.gmail.com> From: Mark Ellison To: Martin Bjorklund Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netconf@ietf.org Subject: Re: [Netconf] and remote URLs X-BeenThere: netconf@ietf.org X-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, 01 Oct 2009 21:29:29 -0000 On Thu, Oct 1, 2009 at 4:53 PM, Martin Bjorklund wrote: > Mark Ellison wrote: >> Regarding use of URL in the protocol operation: >> >> sxn 7.2., "" - states "...such as using a local file, a >> remote file, or inline." >> >> Within section 8.8. "URL capability", section 8.8.5.1 "" >> states, "If the element is specified, then it should identify a >> local configuration file." >> >> My best guess at interpreting the intent would be that 8.8.5.1 >> suggests that a URL *target* in an =A0 operation should be >> a file that is local to the NETCONF server. =A0And, I assume that a URL >> *source* in an operation may be a file that is local or >> remote to the NETCONF server. > > I think 8.8.5.1 is pretty clear. =A0It says: > > =A0 The :url capability modifies the operation to accept > =A0 the element as an alternative to the parameter. =A0If > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^^ > =A0 the element is specified, then it should identify a local > =A0 configuration file. > > I.e. the *source* url should be a local file. =A0According to 8.8.5.1, > using url as a *target* is not supported at all. Got it- the :url capability offers an alternate only to the element in the operation. The :url capability does not make the url element within the element usable. > > 7.2. also does not allow a url as target, but it does say: > > =A0 =A0 =A0This operation allows the new configuration to be expressed in > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^^^^^^^^^= ^^^^^^^ > =A0 =A0 =A0several ways, such as using a local file, a remote file, or > =A0 =A0 =A0inline. > > So the word "remote file" in 7.2 contradicts the text in 8.8.5.1, and > it also contradicts the next paragraph in 7.2. Yes- the "remote file" bits serve as the 'catalyst of confusion' for my hunting for intent. > > However, it is not clear to me why the edit-config source url should > be a local file. =A0The copy-config operation does not have such a > restriction. > > I don't think edit-config of a *target* url was ever intended to be > supported. > So the "target" of can only be one of running, candidate or startup configuration datastore as allowed by the NETCONF server capabilities? And, it looks like there is a multi-step process involving and . I can use a remote url as source and a local url as target in the operation to move configuration data onto the local server, then (lock and) use a local source url with the to update the candidate target, then validate, etc. Finally, I can use to move the 'new configuration' contained in the candidate datastore to either a local or a remote url/file. > > /martin > > I appreciate your time and thank you for your help in getting my thoughts sorted out. I may have additional confusions to sort out as implementation proceeds. Regards, Mark From mbj@tail-f.com Thu Oct 1 14:44: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 9E85228C0F1 for ; Thu, 1 Oct 2009 14:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=0.028, 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 Q9qF++2y+U73 for ; Thu, 1 Oct 2009 14:44:29 -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 095053A69BA for ; Thu, 1 Oct 2009 14:44:29 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id E6D5B61602B; Thu, 1 Oct 2009 23:45:54 +0200 (CEST) Date: Thu, 01 Oct 2009 23:45:54 +0200 (CEST) Message-Id: <20091001.234554.207453283.mbj@tail-f.com> To: ellison@ieee.org From: Martin Bjorklund In-Reply-To: <8a0268750910011430k1d7b855cr27c5225a1f386305@mail.gmail.com> References: <8a0268750910010846v3fb2dedataa1d461b579dde73@mail.gmail.com> <20091001.225351.77770924.mbj@tail-f.com> <8a0268750910011430k1d7b855cr27c5225a1f386305@mail.gmail.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] and remote URLs X-BeenThere: netconf@ietf.org X-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, 01 Oct 2009 21:44:31 -0000 Mark Ellison wrote: > So the "target" of can only be one of running, candidate > or startup configuration datastore as allowed by the NETCONF server > capabilities? In fact, it can not be . See 8.7.5.1. I recommend that you look at the YANG model in draft-ietf-netconf-4741bis-01 - it is a bit more precise than the old XSD. > And, it looks like there is a multi-step process involving > and . I can use a remote url as source and > a local url as target in the operation to move > configuration data onto the local server, then (lock and) use a local > source url with the to update the candidate target, then > validate, etc. Finally, I can use to move the 'new > configuration' contained in the candidate datastore to either a local > or a remote url/file. This is a use case described in Appendix D. But I am not sure if copy-config was intended to be a "ftp" operation, i.e. copy any file? I think copy-config makes sense only when at least one of target and source is a data store. (Then it is like a load / save backup operation). /martin From mark@ellisonsoftware.com Thu Oct 1 15:28: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 428863A67EC for ; Thu, 1 Oct 2009 15:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.887 X-Spam-Level: X-Spam-Status: No, score=-101.887 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfT3ExvRs+jq for ; Thu, 1 Oct 2009 15:28:24 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id CAFA13A679F for ; Thu, 1 Oct 2009 15:28:23 -0700 (PDT) Received: by fxm28 with SMTP id 28so516035fxm.42 for ; Thu, 01 Oct 2009 15:29:46 -0700 (PDT) MIME-Version: 1.0 Sender: mark@ellisonsoftware.com Received: by 10.204.155.69 with SMTP id r5mr454863bkw.136.1254436186046; Thu, 01 Oct 2009 15:29:46 -0700 (PDT) In-Reply-To: <20091001.234554.207453283.mbj@tail-f.com> References: <8a0268750910010846v3fb2dedataa1d461b579dde73@mail.gmail.com> <20091001.225351.77770924.mbj@tail-f.com> <8a0268750910011430k1d7b855cr27c5225a1f386305@mail.gmail.com> <20091001.234554.207453283.mbj@tail-f.com> Date: Thu, 1 Oct 2009 18:29:46 -0400 X-Google-Sender-Auth: f82a920253f6ec39 Message-ID: <8a0268750910011529r6989b3c4m753a19abaf78c125@mail.gmail.com> From: Mark Ellison To: Martin Bjorklund Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netconf@ietf.org Subject: Re: [Netconf] and remote URLs X-BeenThere: netconf@ietf.org X-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, 01 Oct 2009 22:28:26 -0000 On Thu, Oct 1, 2009 at 5:45 PM, Martin Bjorklund wrote: > Mark Ellison wrote: >> So the "target" of can only be one of running, candidate >> or startup configuration datastore as allowed by the NETCONF server >> capabilities? > > In fact, it can not be . =A0See 8.7.5.1. =A0I recommend that you > look at the YANG model in draft-ietf-netconf-4741bis-01 - it is a bit > more precise than the old XSD. In fact I am working with the XSD from 4741bis-01 since it works with tools that draw nice UML diagrams for me ;-) I just took a look at the YANG and see some useful information but guess it will take some time to understand YANG better than XSD. In the "rpc edit-config {...}" YANG block I see a reference to section 8.8.5.1., but do not see a reference to section 7.2. (which would seem useful) > >> And, it looks like there is a multi-step process involving >> and . =A0I can use a remote url as source and >> a local url as target in the operation to move >> configuration data onto the local server, then (lock and) use a local >> source url with the to update the candidate target, then >> validate, etc. =A0Finally, I can use to move the 'new >> configuration' contained in the candidate datastore to either a local >> or a remote url/file. > > This is a use case described in Appendix D. =A0But I am not sure if > copy-config was intended to be a "ftp" operation, i.e. copy any file? I have been looking through this Appendix ("E") and see where the operation moves inline config to a local url/file. Section 7.3 has an example of using a remote http source. > > I think copy-config makes sense only when at least one of target and > source is a data store. =A0(Then it is like a load / save backup > operation). Okay- duly noted. However, it would seem that a from a remote http/file to a local file would serve a use case where there is one of many of the same model devices where a configuration is validated and this configuration is then moved out to the many devices- which will then load the config from the local url/file at some future (possibly coordinated) time. I don't think the protocol precludes this. Also, I noticed that the :url capability applied to the :validate capability does not constrain the source to local. I guess this allows a NETCONF server to validate a remote configuration before sending it to the device? Or is this possibly an oversight? Also (sorry!) why does the YANG in 4741bis refer to "agent" rather than "NETCONF server"? (e.g. in feature validate-1.1) Again, it'll take me a while to start 'getting' the YANG as I am still much more comfortable with the UML generated from the XSD. Guess I'll have to try a YANG --> XSD conversion tool here. > > > /martin > Thanks Martin. Regards, Mark From andy@netconfcentral.com Thu Oct 1 17:10: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 42B233A67E6 for ; Thu, 1 Oct 2009 17:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 NGnQbvbgpsug for ; Thu, 1 Oct 2009 17:10:43 -0700 (PDT) Received: from n13.bullet.mail.mud.yahoo.com (n13.bullet.mail.mud.yahoo.com [68.142.206.40]) by core3.amsl.com (Postfix) with SMTP id 9F4073A6899 for ; Thu, 1 Oct 2009 17:10:29 -0700 (PDT) Received: from [68.142.200.224] by n13.bullet.mail.mud.yahoo.com with NNFMP; 02 Oct 2009 00:11:54 -0000 Received: from [68.142.201.67] by t5.bullet.mud.yahoo.com with NNFMP; 02 Oct 2009 00:11:54 -0000 Received: from [127.0.0.1] by omp419.mail.mud.yahoo.com with NNFMP; 02 Oct 2009 00:11:54 -0000 X-Yahoo-Newman-Id: 469782.34905.bm@omp419.mail.mud.yahoo.com Received: (qmail 7596 invoked from network); 2 Oct 2009 00:11:54 -0000 Received: from adsl-68-120-81-206.dsl.irvnca.pacbell.net (andy@68.120.81.206 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 01 Oct 2009 17:11:53 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 7ho9z.EVM1m0y50LZT_CgqsdiUhGIzdXBmPm31Zl19vRBlV3QbTvEJVWzZ467FFwvL00IQy1gf1K8avQPJGml4XcX092tQUFMoEXuOU06HWo5VB5yOjmXkoghRZ7kxs7USc3B3wh5PBCA_Un6ZT97wI1VMCkqPvUiYaprQhF5TKG2sFDosLIF7AA2RaPOaSpGyoR.029EViHSdyoN_zHrwPCuhZAPS9D8AfC X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AC54594.80105@netconfcentral.com> Date: Thu, 01 Oct 2009 17:13:08 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Mark Scott References: <4AC0ED35.3070404@netconfcentral.com><20091001.083617.169773375.mbj@tail-f.com> <4AC4A86E.6000701@netconfcentral.com> <085091CB2CA14E4B8B163FFC37C84E9D1A806F54@zcarhxm0.corp.nortel.com> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D1A806F54@zcarhxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] mandatory parms discussion X-BeenThere: netconf@ietf.org X-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, 02 Oct 2009 00:10:44 -0000 Mark Scott wrote: > Andy, > > A rationale for not modifying the mandatory parameters in > was posted to the ML on Sept 16th. > > I suspect you missed that based on the comment below so I am repeating > it here for further discussion: > > "2. mandatory parameters: Initially > was the only mandatory parameter in the operation, however > after we agreed to expand the key definition in the schema list we made > and mandatory parameters in the operation. My > preference would be to keep this alignment between the key and > mandatory parms. I agree in cases where only 1 revision > and/or 1 format exists this is heavy-handed but it protects against > agents returning schema a manager may not have intended since > is not unique in schema list and the logic on agent to > select the default revision may differ from what the manager would have > selected (esp. if more than 1 version exists)." > > Previously no one else had objected to these being mandatory parameters > and no ML consensus had been reached to modify it. > I don't understand why the RPC is coupled to the /netconf-state/schemas data structure. Revisions are optional in YANG. A valid module can exist without a . This module forces a YANG module to use the empty string as the version, which is somewhat of a hack. > I have changed the subject header of this email in an attempt to > initiate a ML discussion and will update the draft based on consensus. > > Mark > Andy From andy@netconfcentral.com Thu Oct 1 17:19: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 947973A6829 for ; Thu, 1 Oct 2009 17:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 oWnBy6lWMJ23 for ; Thu, 1 Oct 2009 17:19:20 -0700 (PDT) Received: from n76.bullet.mail.sp1.yahoo.com (n76.bullet.mail.sp1.yahoo.com [98.136.44.48]) by core3.amsl.com (Postfix) with SMTP id 969F63A67E2 for ; Thu, 1 Oct 2009 17:19:20 -0700 (PDT) Received: from [216.252.122.216] by n76.bullet.mail.sp1.yahoo.com with NNFMP; 02 Oct 2009 00:20:44 -0000 Received: from [68.142.200.227] by t1.bullet.sp1.yahoo.com with NNFMP; 02 Oct 2009 00:20:44 -0000 Received: from [68.142.201.253] by t8.bullet.mud.yahoo.com with NNFMP; 02 Oct 2009 00:20:44 -0000 Received: from [127.0.0.1] by omp414.mail.mud.yahoo.com with NNFMP; 02 Oct 2009 00:20:44 -0000 X-Yahoo-Newman-Id: 37731.20683.bm@omp414.mail.mud.yahoo.com Received: (qmail 43388 invoked from network); 2 Oct 2009 00:20:43 -0000 Received: from adsl-68-120-81-206.dsl.irvnca.pacbell.net (andy@68.120.81.206 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 01 Oct 2009 17:20:43 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: .8.P.IQVM1mrStQL0rA5eejDaHQRETGAxGcynu0M94q07QX3RGAyYPp8b.kvDpXQqhnPhzybRGnwb16EQrUnAcE9_b4eEd4YxKUCVgF9FkvmycEQ1WZeDtZU40zOosXoGV3a1GDUuZ2qDyt7rtFELyobmovEbDo1uz4Bltmtx3BxMn5tTI4rYY3BVZ9RSFGlRakEnduitL3j.G8ommuvpxIJtxHgG9NaacnJS8I13_sQylX9Kvacw1LZJAlHA4VDtIKTokRo2QNA8aXvIB3tD9ywdxHjHs1.P_LjU8kbW5UuduIklf1GqlP03AyS6Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AC547A6.8010701@netconfcentral.com> Date: Thu, 01 Oct 2009 17:21:58 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4AC0ED35.3070404@netconfcentral.com> <20091001.083617.169773375.mbj@tail-f.com> In-Reply-To: <20091001.083617.169773375.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] comments on monitoring-08 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, 02 Oct 2009 00:19:22 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> I noticed that the 'transport' identity was replaced >> with a 'session-type' identity, and now the >> /sessions/session/transport leaf >> has been changed to a session-type leaf. Yet no new >> standard identities were added, and no semantics were >> altered. > > Right, this was just a name change of the identity. > No it was not: leaf session-type { mandatory true; type identityref { base session-type; } } The enum choices are: netconf-ssh netconf-soap-over-beep netconf-soap-over-https netconf-beep netconf-tls These match the transport mappings for NETCONF. In all the NETCONF RFCs, these are called transport mappings, not session types. I object to this change -- this entire change should be removed, and the -07 text should be restored. > > /martin > Andy From david.partain@ericsson.com Fri Oct 2 01:35: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 7222B3A68BB; Fri, 2 Oct 2009 01:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.438 X-Spam-Level: X-Spam-Status: No, score=-5.438 tagged_above=-999 required=5 tests=[AWL=0.811, 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 CfkZsIyilLfb; Fri, 2 Oct 2009 01:35:40 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C8C273A67F2; Fri, 2 Oct 2009 01:35:39 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000003d08-7e-4ac5bbb16d25 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 1F.2C.15624.1BBB5CA4; Fri, 2 Oct 2009 10:37:05 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 10:36:20 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 10:36:20 +0200 From: David Partain Organization: Ericsson AB To: "netconf@ietf.org" , NETMOD Working Group Date: Fri, 2 Oct 2009 10:36:19 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910021036.19330.david.partain@ericsson.com> X-OriginalArrivalTime: 02 Oct 2009 08:36:20.0063 (UTC) FILETIME=[6A6536F0:01CA433B] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Information from chair phone call on 24 September X-BeenThere: netconf@ietf.org X-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, 02 Oct 2009 08:35:41 -0000 Hi, This mail summarizes the conversation that the 4 co-chairs of NETCONF/NETMOD had with interested parties on default issue. This mail is NOT intended to re-open the question about default handling but to confirm that what we believe is a reasonable way forward is a decision that the working groups can live with. Silence will be considered consent! 1. There were a number of comments during the call that indicated that we need text that says that defaults are taken into consideration in validation. 2. The defaults question: No fundamental changes to the model are needed. That is, a server MAY choose not to send back values that are the default as defined in the YANG model. Instead, we are going to try to address some things that will tighten up potential inconsistencies (to "SHOULD level", not "MUST level") in dealing with defaults. There are cases where you don't necessarily know what a non-answer about an object with a default clause means. In particular, this means looking at upgrade rules, dealing with leafrefs and instance-identifiers. We should try to address the most common cases without trying to cover all possible corner cases. We need specific text, which Andy and Martin have been asked to address. Again, we are not re-opening this discussion by sending this mail: we wish to confirm that this is the right way forward. Some expressed a wish that there be a simple, short explanation of how defaults are handled in general so that one doesn't need to be privy of the entire YANG history to understand why things are the way they are. If you believe that this is useful, please offer text or, at a minimum, point out where you think text is missing. 3. The NETCONF WG to check consensus on whether 'with-defaults:' should be a SHOULD to implement. 4. In conjunction with the 'with-defaults:' work, the NETCONF WG can consider adding an XML attribute in a report-all response that tags default data as such to help NETCONF applications. (This discussion is already underway.) 5. Juergen agreed to help with some examples of XPath expressions refering to config / non-config / garbage data. (I think I got this right.) If others believe that other examples are needed, please suggest that on the mailing list. 6. We need to start thinking about (and writing about) the issue of config vs. statistics vs. operational data. This is something that needs to be given serious thought and energy. This will be done separately (and after) the YANG work is complete. 7. We will try to put text in the architecture draft as a sort of "placeholder" with respect to #5. Text has been suggested on the mailing list before and that should be put into the draft. Thanks. David From mehmet.ersue@nsn.com Fri Oct 2 03:05:18 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 D511C3A680E for ; Fri, 2 Oct 2009 03:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.247 X-Spam-Level: X-Spam-Status: No, score=-5.247 tagged_above=-999 required=5 tests=[AWL=1.352, 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 A-sT-bRdgJqI for ; Fri, 2 Oct 2009 03:05:17 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id B4D833A67FC for ; Fri, 2 Oct 2009 03:04:22 -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 n92A5mlD010368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Oct 2009 12:05:48 +0200 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 n92A5lpS024840; Fri, 2 Oct 2009 12:05:48 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 12:05:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Oct 2009 12:05:46 +0200 Message-ID: In-Reply-To: <4AC547A6.8010701@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] comments on monitoring-08 draft Thread-Index: AcpC9jPJPLZkzhaLQ0Go4Oxsdq48cQAT3Wmg References: <4AC0ED35.3070404@netconfcentral.com><20091001.083617.169773375.mbj@tail-f.com> <4AC547A6.8010701@netconfcentral.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" , "ext Mark Scott" X-OriginalArrivalTime: 02 Oct 2009 10:05:47.0772 (UTC) FILETIME=[E9CC9BC0:01CA4347] Cc: netconf@ietf.org Subject: Re: [Netconf] comments on monitoring-08 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, 02 Oct 2009 10:05:19 -0000 Hi Mark, Andy, it is common practice that during WGLC or later in the=20 process that the document editor does not do changes=20 without without making sure that such a change is=20 supported by the WG (and the co-chairs). Our goal at=20 this late stage should be to finalize the document text. I would suggest to start a new discussion if you=20 strongly believe the change is necessary. Otherwise my proposal as a co-chair would be to redo=20 the change for "transport" vs. "session-type" even=20 though it was well-meant. Cheers, Mehmet =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy Bierman > Sent: Friday, October 02, 2009 2:22 AM > To: Martin Bjorklund > Cc: netconf@ietf.org > Subject: Re: [Netconf] comments on monitoring-08 draft >=20 > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> I noticed that the 'transport' identity was replaced > >> with a 'session-type' identity, and now the > >> /sessions/session/transport leaf > >> has been changed to a session-type leaf. Yet no new > >> standard identities were added, and no semantics were > >> altered. > >=20 > > Right, this was just a name change of the identity. > >=20 >=20 > No it was not: >=20 > leaf session-type { > mandatory true; > type identityref { > base session-type; > } > } >=20 >=20 > The enum choices are: >=20 > netconf-ssh > netconf-soap-over-beep > netconf-soap-over-https > netconf-beep > netconf-tls >=20 > These match the transport mappings for NETCONF. > In all the NETCONF RFCs, these are called transport mappings, > not session types. >=20 > I object to this change -- this entire change should be > removed, and the -07 text should be restored. >=20 >=20 > >=20 > > /martin > >=20 >=20 >=20 > Andy >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From mehmet.ersue@nsn.com Fri Oct 2 03:15: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 387DF3A6844 for ; Fri, 2 Oct 2009 03:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=-0.690, 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 RJM0YPm5v3ey for ; Fri, 2 Oct 2009 03:15:21 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 696463A67F7 for ; Fri, 2 Oct 2009 03:15:21 -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 n92AGk4V030439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Oct 2009 12:16:46 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n92AGjDB026936; Fri, 2 Oct 2009 12:16:46 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 12:16:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Oct 2009 12:16:44 +0200 Message-ID: In-Reply-To: <4AC54594.80105@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] [NETCONF] mandatory parms discussion Thread-Index: AcpC9QG8JMaOQBxbTTuRS3fBnaoduAAUKDpA References: <4AC0ED35.3070404@netconfcentral.com><20091001.083617.169773375.mbj@tail-f.com><4AC4A86E.6000701@netconfcentral.com><085091CB2CA14E4B8B163FFC37C84E9D1A806F54@zcarhxm0.corp.nortel.com> <4AC54594.80105@netconfcentral.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" , "Mark Scott" X-OriginalArrivalTime: 02 Oct 2009 10:16:45.0945 (UTC) FILETIME=[7219D690:01CA4349] Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] mandatory parms discussion X-BeenThere: netconf@ietf.org X-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, 02 Oct 2009 10:15:23 -0000 Hi Mark, Andy,=20 modifying the the mandatory parameters in =20 has been proposed earlier in September. There were no=20 arguments against it at that time. In the sake of progress I would like to ask you to try=20 to converge on a solution. OTHERS: PLEASE speak up if you agree or disagree with=20 any points made by either Mark or Andy. It would be good if we can bring this to a conclusion=20 and the draft one step further soon. Cheers, Mehmet =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy Bierman > Sent: Friday, October 02, 2009 2:13 AM > To: Mark Scott > Cc: netconf@ietf.org > Subject: Re: [Netconf] [NETCONF] mandatory parms=20 > discussion >=20 > Mark Scott wrote: > > Andy, > >=20 > > A rationale for not modifying the mandatory parameters in=20 > > > was posted to the ML on Sept 16th. > >=20 > > I suspect you missed that based on the comment below so I=20 > am repeating > > it here for further discussion: > >=20 > > "2. mandatory parameters: Initially > > was the only mandatory parameter in the =20 > operation, however > > after we agreed to expand the key definition in the schema=20 > list we made > > and mandatory parameters in the operation. My > > preference would be to keep this alignment between the key and > > mandatory parms. I agree in cases where only=20 > 1 revision > > and/or 1 format exists this is heavy-handed but it protects against > > agents returning schema a manager may not have intended since > > is not unique in schema list and the logic on agent to > > select the default revision may differ from what the=20 > manager would have > > selected (esp. if more than 1 version exists)." > >=20 > > Previously no one else had objected to these being=20 > mandatory parameters > > and no ML consensus had been reached to modify it. > >=20 >=20 > I don't understand why the RPC > is coupled to the /netconf-state/schemas data structure. >=20 > Revisions are optional in YANG. A valid module > can exist without a . This module forces > a YANG module to use the empty string as the > version, which is somewhat of a hack. >=20 >=20 > > I have changed the subject header of this email in an attempt to > > initiate a ML discussion and will update the draft based on=20 > consensus. > >=20 > > Mark > > >=20 > Andy >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From mbj@tail-f.com Fri Oct 2 03:21: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 BA80B3A67A5 for ; Fri, 2 Oct 2009 03:21:05 -0700 (PDT) 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 YHUsEZrjM+-U for ; Fri, 2 Oct 2009 03:21:04 -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 5C2F23A67A3 for ; Fri, 2 Oct 2009 03:21:04 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id DEC57616007; Fri, 2 Oct 2009 12:22:30 +0200 (CEST) Date: Fri, 02 Oct 2009 12:22:30 +0200 (CEST) Message-Id: <20091002.122230.150751249.mbj@tail-f.com> To: mehmet.ersue@nsn.com From: Martin Bjorklund In-Reply-To: References: <085091CB2CA14E4B8B163FFC37C84E9D1A806F54@zcarhxm0.corp.nortel.com> <4AC54594.80105@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] [NETCONF] mandatory parms discussion X-BeenThere: netconf@ietf.org X-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, 02 Oct 2009 10:21:05 -0000 "Ersue, Mehmet (NSN - DE/Munich)" wrote: > > Hi Mark, Andy, > > modifying the the mandatory parameters in > has been proposed earlier in September. There were no > arguments against it at that time. > > In the sake of progress I would like to ask you to try > to converge on a solution. > OTHERS: PLEASE speak up if you agree or disagree with > any points made by either Mark or Andy. I agree with Andy, i.e. and should be optional. I think Mark's concern that the client might get a schema it didn't intended is covered by saying that if there are more than one schema with the given , an error is returned. In this case the client must give all parameters. /martin From dromasca@avaya.com Fri Oct 2 03:31: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 23F0728B23E; Fri, 2 Oct 2009 03:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 khkkMGcGyhqb; Fri, 2 Oct 2009 03:31:00 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 7316428C0D8; Fri, 2 Oct 2009 03:30:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,493,1249272000"; d="scan'208";a="158655251" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Oct 2009 06:32:23 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Oct 2009 06:32:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Oct 2009 12:32:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need for WebEx at IETF 76 thread-index: AcpC62cK+Vp4d9meScWEUESp+2mT7QAXlQ/Q From: "Romascanu, Dan (Dan)" To: , "OPS Area (E-mail)" , "radext mailing list" , , , , "IETF IPFIX Working Group" Subject: [Netconf] FW: Need for WebEx at IETF 76 X-BeenThere: netconf@ietf.org X-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, 02 Oct 2009 10:31:01 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Alexa Morris Sent: Friday, October 02, 2009 1:03 AM To: The IESG Subject: Need for WebEx at IETF 76 I'd like to know if any of you might need to use WebEx for any working group sessions taking place at IETF 76. Please note that at present I'm looking more for a "I need WebEx because one of my key presenters will not be physically present"=20 From mbj@tail-f.com Fri Oct 2 04:06: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 DD5A43A69DB for ; Fri, 2 Oct 2009 04:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.105, 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 PN7F2E1mg+6f for ; Fri, 2 Oct 2009 04:06:45 -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 BBA3A3A67FD for ; Fri, 2 Oct 2009 04:06:44 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C7A5C616007; Fri, 2 Oct 2009 13:08:11 +0200 (CEST) Date: Fri, 02 Oct 2009 13:08:11 +0200 (CEST) Message-Id: <20091002.130811.171518135.mbj@tail-f.com> To: ellison@ieee.org From: Martin Bjorklund In-Reply-To: <8a0268750910011529r6989b3c4m753a19abaf78c125@mail.gmail.com> References: <8a0268750910011430k1d7b855cr27c5225a1f386305@mail.gmail.com> <20091001.234554.207453283.mbj@tail-f.com> <8a0268750910011529r6989b3c4m753a19abaf78c125@mail.gmail.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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netconf@ietf.org Subject: Re: [Netconf] and remote URLs X-BeenThere: netconf@ietf.org X-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, 02 Oct 2009 11:06:46 -0000 Mark Ellison wrote: > On Thu, Oct 1, 2009 at 5:45 PM, Martin Bjorklund wro= te: > > Mark Ellison wrote: > >> So the "target" of can only be one of running, candi= date > >> or startup configuration datastore as allowed by the NETCONF serve= r > >> capabilities? > > > > In fact, it can not be . =A0See 8.7.5.1. =A0I recommend th= at you > > look at the YANG model in draft-ietf-netconf-4741bis-01 - it is a b= it > > more precise than the old XSD. > = > In fact I am working with the XSD from 4741bis-01 since it works with= > tools that draw nice UML diagrams for me ;-) That's fine; I just wanted to point out that the XSD in 4741 allows more than is actually legal according to the text. > I just took a look at > the YANG and see some useful information but guess it will take some > time to understand YANG better than XSD. In the "rpc edit-config > {...}" YANG block I see a reference to section 8.8.5.1., but do not > see a reference to section 7.2. (which would seem useful) Thanks, that was a bug in the script that adds xrefs to the YANG module; fixed. > >> And, it looks like there is a multi-step process involving > >> and . =A0I can use a remote url as sour= ce and > >> a local url as target in the operation to move > >> configuration data onto the local server, then (lock and) use a lo= cal > >> source url with the to update the candidate target, = then > >> validate, etc. =A0Finally, I can use to move the 'ne= w > >> configuration' contained in the candidate datastore to either a lo= cal > >> or a remote url/file. > > > > This is a use case described in Appendix D. =A0But I am not sure if= > > copy-config was intended to be a "ftp" operation, i.e. copy any fil= e? > = > I have been looking through this Appendix ("E") and see where the > operation moves inline config to a local url/file. > Section 7.3 has an example of using a remote http > source. > > > > I think copy-config makes sense only when at least one of target an= d > > source is a data store. =A0(Then it is like a load / save backup > > operation). > = > Okay- duly noted. However, it would seem that a from a= > remote http/file to a local file would serve a use case where there i= s > one of many of the same model devices where a configuration is > validated and this configuration is then moved out to the many > devices- which will then load the config from the local url/file at > some future (possibly coordinated) time. > = > I don't think the protocol precludes this. If not, what checks, if any, should be done by copy-config when both target and source are urls? Is this legal: file://incoming.conf http://www.ietf.org/index.html > Also, I noticed that the :url capability applied to the :validate > capability does not constrain the source to local. I guess this > allows a NETCONF server to validate a remote configuration before > sending it to the device? Or is this possibly an oversight? I think this should be ok. The only operation that is restricted to local files is . Hmm.. the reason for restricting to local files was for security. We don't want the NETCONF server to delete files on remote computers; it is pointless. But to a remote file is allowed, so you can get the NETCONF server to overwrite remote files. > Also (sorry!) why does the YANG in 4741bis refer to "agent" rather > than "NETCONF server"? (e.g. in feature validate-1.1) Bug, now fixed. /martin From j.schoenwaelder@jacobs-university.de Fri Oct 2 04:21:18 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 E94EB3A67B3 for ; Fri, 2 Oct 2009 04:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.138, 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 sDKVFqSU3dZC for ; Fri, 2 Oct 2009 04:21:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 50F523A679C for ; Fri, 2 Oct 2009 04:21:15 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 510BFC003E; Fri, 2 Oct 2009 13:22:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pA89PUvc9AbL; Fri, 2 Oct 2009 13:22:41 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3EA1EC001D; Fri, 2 Oct 2009 13:22:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2B32ED0D425; Fri, 2 Oct 2009 13:22:40 +0200 (CEST) Date: Fri, 2 Oct 2009 13:22:40 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20091002112240.GA2607@elstar.local> Mail-Followup-To: Martin Bjorklund , "ellison@ieee.org" , "netconf@ietf.org" References: <8a0268750910011430k1d7b855cr27c5225a1f386305@mail.gmail.com> <20091001.234554.207453283.mbj@tail-f.com> <8a0268750910011529r6989b3c4m753a19abaf78c125@mail.gmail.com> <20091002.130811.171518135.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091002.130811.171518135.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] and remote URLs 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: Fri, 02 Oct 2009 11:21:18 -0000 On Fri, Oct 02, 2009 at 01:08:11PM +0200, Martin Bjorklund wrote: > I think this should be ok. The only operation that is restricted to > local files is . > > Hmm.. the reason for restricting to local files was > for security. We don't want the NETCONF server to delete files on > remote computers; it is pointless. But to a remote file > is allowed, so you can get the NETCONF server to overwrite remote > files. I fail to follow the logic - why is overwriting OK but deleting not? At the end, it is a matter of the remote ftp/http/... server to enforce access control rules. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Fri Oct 2 04:24:06 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 E934C3A67CC for ; Fri, 2 Oct 2009 04:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.103, 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 qGb-iQX5V3vC for ; Fri, 2 Oct 2009 04:24:05 -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 DBF003A67B3 for ; Fri, 2 Oct 2009 04:24:00 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7956D616007; Fri, 2 Oct 2009 13:25:27 +0200 (CEST) Date: Fri, 02 Oct 2009 13:25:27 +0200 (CEST) Message-Id: <20091002.132527.85975746.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20091002112240.GA2607@elstar.local> References: <8a0268750910011529r6989b3c4m753a19abaf78c125@mail.gmail.com> <20091002.130811.171518135.mbj@tail-f.com> <20091002112240.GA2607@elstar.local> 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] and remote URLs X-BeenThere: netconf@ietf.org X-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, 02 Oct 2009 11:24:06 -0000 Juergen Schoenwaelder wrote: > On Fri, Oct 02, 2009 at 01:08:11PM +0200, Martin Bjorklund wrote: > > > I think this should be ok. The only operation that is restricted to > > local files is . > > > > Hmm.. the reason for restricting to local files was > > for security. We don't want the NETCONF server to delete files on > > remote computers; it is pointless. But to a remote file > > is allowed, so you can get the NETCONF server to overwrite remote > > files. > > I fail to follow the logic - why is overwriting OK but deleting not? That's what I meant - the reasoning is flawed. > At the end, it is a matter of the remote ftp/http/... server to > enforce access control rules. So we should simply remove the text about local config files then. /martin From mark@ellisonsoftware.com Fri Oct 2 06:19: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 3CDCC3A677E for ; Fri, 2 Oct 2009 06:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.595 X-Spam-Level: X-Spam-Status: No, score=-101.595 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_48=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPl7e229nf0e for ; Fri, 2 Oct 2009 06:19:53 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id A5C8D3A6765 for ; Fri, 2 Oct 2009 06:19:52 -0700 (PDT) Received: by bwz6 with SMTP id 6so976289bwz.37 for ; Fri, 02 Oct 2009 06:21:16 -0700 (PDT) MIME-Version: 1.0 Sender: mark@ellisonsoftware.com Received: by 10.204.48.194 with SMTP id s2mr1124187bkf.210.1254489676691; Fri, 02 Oct 2009 06:21:16 -0700 (PDT) In-Reply-To: References: <4AC0ED35.3070404@netconfcentral.com> <20091001.083617.169773375.mbj@tail-f.com> <4AC4A86E.6000701@netconfcentral.com> <085091CB2CA14E4B8B163FFC37C84E9D1A806F54@zcarhxm0.corp.nortel.com> <4AC54594.80105@netconfcentral.com> Date: Fri, 2 Oct 2009 09:21:16 -0400 X-Google-Sender-Auth: 865202bc329201bd Message-ID: <8a0268750910020621i3fd997aaqec36f7b81d6b3040@mail.gmail.com> From: Mark Ellison To: "Ersue, Mehmet (NSN - DE/Munich)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] mandatory parms discussion X-BeenThere: netconf@ietf.org X-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, 02 Oct 2009 13:19:54 -0000 On Fri, Oct 2, 2009 at 6:16 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > > Hi Mark, Andy, > > modifying the the mandatory parameters in > has been proposed earlier in September. There were no > arguments against it at that time. > > In the sake of progress I would like to ask you to try > to converge on a solution. > OTHERS: PLEASE speak up if you agree or disagree with > any points made by either Mark or Andy. > I do think the important aspect to a client would be the ability to use to retrieve the actual set of schemata in use by a server. I do not think it should be necessary for a client to know a priori, or derive from the capabilities present in the server , the name and revision of each schema/YANG module. When would a server actually have two revisions of the same schema module in concurrent use? As long as the revision information is part of the retrieved schema and a server implements at most one revision of a schema, then I see no value in having a client ask for a schema by name and revision. If the name+revision of each schema does not appear in the server , then maybe there could be a operation to get a list of name+revision of each schema utilized by a server and then it would be up to the client to get desired schemata from the retrieved list. As an alternative to a operation, there could be a state data node containing this information, similar to the intent of the SNMPv2-MIB sysORTable. > It would be good if we can bring this to a conclusion > and the draft one step further soon. > > Cheers, > Mehmet > Just my attempt to be helpful. Regards, Mark > >> -----Original Message----- >> From: netconf-bounces@ietf.org >> [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy Bierman >> Sent: Friday, October 02, 2009 2:13 AM >> To: Mark Scott >> Cc: netconf@ietf.org >> Subject: Re: [Netconf] [NETCONF] mandatory parms >> discussion >> >> Mark Scott wrote: >> > Andy, >> > >> > A rationale for not modifying the mandatory parameters in >> >> > was posted to the ML on Sept 16th. >> > >> > I suspect you missed that based on the comment below so I >> am repeating >> > it here for further discussion: >> > >> > =A0 =A0 "2. =A0 mandatory parameters: =A0Initially >> > was the only mandatory parameter in the >> operation, however >> > after we agreed to expand the key definition in the schema >> list we made >> > and mandatory parameters in the operation. =A0My >> > preference would be to keep this alignment between the key and >> > mandatory parms. =A0I agree in cases where only >> 1 revision >> > and/or 1 format exists this is heavy-handed but it protects against >> > agents returning schema a manager may not have intended since >> > is not unique in schema list and the logic on agent to >> > select the default revision may differ from what the >> manager would have >> > selected (esp. if more than 1 version exists)." >> > >> > Previously no one else had objected to these being >> mandatory parameters >> > and no ML consensus had been reached to modify it. >> > >> >> I don't understand why the RPC >> is coupled to the /netconf-state/schemas data structure. >> >> Revisions are optional in YANG. =A0A valid module >> can exist without a . =A0This module forces >> a YANG module to use the empty string as the >> version, which is somewhat of a hack. >> >> >> > I have changed the subject header of this email in an attempt to >> > initiate a ML discussion and will update the draft based on >> consensus. >> > >> > Mark >> > >> >> Andy >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From mark@ellisonsoftware.com Fri Oct 2 06:33:04 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 3466D3A6A25 for ; Fri, 2 Oct 2009 06:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.877 X-Spam-Level: X-Spam-Status: No, score=-101.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iv97XsY9o3ct for ; Fri, 2 Oct 2009 06:33:03 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 2D5A33A67F3 for ; Fri, 2 Oct 2009 06:33:03 -0700 (PDT) Received: by bwz6 with SMTP id 6so988032bwz.37 for ; Fri, 02 Oct 2009 06:34:26 -0700 (PDT) MIME-Version: 1.0 Sender: mark@ellisonsoftware.com Received: by 10.204.0.69 with SMTP id 5mr1170479bka.173.1254490466054; Fri, 02 Oct 2009 06:34:26 -0700 (PDT) In-Reply-To: <20091002.130811.171518135.mbj@tail-f.com> References: <8a0268750910011430k1d7b855cr27c5225a1f386305@mail.gmail.com> <20091001.234554.207453283.mbj@tail-f.com> <8a0268750910011529r6989b3c4m753a19abaf78c125@mail.gmail.com> <20091002.130811.171518135.mbj@tail-f.com> Date: Fri, 2 Oct 2009 09:34:26 -0400 X-Google-Sender-Auth: bf25e33218886831 Message-ID: <8a0268750910020634o40c3fc5bq212c4b0ad095e503@mail.gmail.com> From: Mark Ellison To: Martin Bjorklund Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netconf@ietf.org Subject: Re: [Netconf] and remote URLs X-BeenThere: netconf@ietf.org X-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, 02 Oct 2009 13:33:04 -0000 On Fri, Oct 2, 2009 at 7:08 AM, Martin Bjorklund wrote: > Mark Ellison wrote: >> On Thu, Oct 1, 2009 at 5:45 PM, Martin Bjorklund wrote: >> > Mark Ellison wrote: [deletions] >> > I think copy-config makes sense only when at least one of target and >> > source is a data store. =A0(Then it is like a load / save backup >> > operation). >> >> Okay- duly noted. =A0However, it would seem that a from a >> remote http/file to a local file would serve a use case where there is >> one of many of the same model devices where a configuration is >> validated and this configuration is then moved out to the many >> devices- which will then load the config from the local url/file at >> some future (possibly coordinated) time. >> >> I don't think the protocol precludes this. > > If not, what checks, if any, should be done by copy-config when both > target and source are urls? =A0Is this legal: > > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 =A0file://incoming.conf > =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 =A0http://www.ietf.org/index.html > =A0 =A0 =A0 > =A0 =A0 > > I see your point that could be misused by placing garbage into a local file. However, the same could be attempted when the target is a configuration data store which is then saved to a local file. When a client is using properly, it seems an extra step to load a remote source into a configuration date store in order to copy to a local file and an extra step to load a local file into a configuration data store in order to save to a remote file. [deletions] > > > /martin > Regards, Mark From andy@netconfcentral.com Fri Oct 2 07:59: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 45AF73A67F1 for ; Fri, 2 Oct 2009 07:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_48=0.6, UNPARSEABLE_RELAY=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 KrW-1MtR9qWz for ; Fri, 2 Oct 2009 07:59:36 -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 800563A676A for ; Fri, 2 Oct 2009 07:59:36 -0700 (PDT) Received: (qmail 59251 invoked from network); 2 Oct 2009 15:01:02 -0000 Received: from adsl-68-120-81-206.dsl.irvnca.pacbell.net (andy@68.120.81.206 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 02 Oct 2009 08:01:02 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: Yaa2KdcVM1kuElIy90Q7zmOdTT24wWLPvq0lPinb_GYoiQtlKr84GTsW6br3zVZNVoUjIppzrfp67bX.8eO8nDq_g6s71mwXbC0KoMEvr3lXrkU2LpXnr3dzItaUajlWf7XhS9O2rH7ILXrm01trBE9wrfH5zogwkyFCH3Fwe0ZxztppEbV9HCu4BK4AWzzKknT21cn81vq5GbkqE6ZmX5kqMv7CBhJU.AefKXmm.viCRojCoGWy0PY7MZqKEwBxmohoZK5hJXElbdC9EnTVCKrPC..EUkQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AC615FC.2050307@netconfcentral.com> Date: Fri, 02 Oct 2009 08:02:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Mark Ellison References: <4AC0ED35.3070404@netconfcentral.com> <20091001.083617.169773375.mbj@tail-f.com> <4AC4A86E.6000701@netconfcentral.com> <085091CB2CA14E4B8B163FFC37C84E9D1A806F54@zcarhxm0.corp.nortel.com> <4AC54594.80105@netconfcentral.com> <8a0268750910020621i3fd997aaqec36f7b81d6b3040@mail.gmail.com> In-Reply-To: <8a0268750910020621i3fd997aaqec36f7b81d6b3040@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] mandatory parms discussion X-BeenThere: netconf@ietf.org X-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, 02 Oct 2009 14:59:37 -0000 Mark Ellison wrote: > On Fri, Oct 2, 2009 at 6:16 AM, Ersue, Mehmet (NSN - DE/Munich) > wrote: >> Hi Mark, Andy, >> >> modifying the the mandatory parameters in >> has been proposed earlier in September. There were no >> arguments against it at that time. >> >> In the sake of progress I would like to ask you to try >> to converge on a solution. >> OTHERS: PLEASE speak up if you agree or disagree with >> any points made by either Mark or Andy. >> > > I do think the important aspect to a client would be the ability to > use to retrieve the actual set of schemata in use by a > server. I do not think it should be necessary for a client to know a > priori, or derive from the capabilities present in the server , > the name and revision of each schema/YANG module. > > When would a server actually have two revisions of the same schema > module in concurrent use? As long as the revision information is part > of the retrieved schema and a server implements at most one revision > of a schema, then I see no value in having a client ask for a schema > by name and revision. > > If the name+revision of each schema does not appear in the server > , then maybe there could be a operation to get a > list of name+revision of each schema utilized by a server and then it > would be up to the client to get desired schemata from the retrieved > list. > The operative word is 'if'. I'm sure these corner-cases are obvious to everyone, but I'll list them anyway: * The module name may appear in a deviation and not appear in its own module capability. * A module 'A' can import 'B' without giving its revision, and there is no module capability for 'B'. * A submodule can be included without a revision date, and there is no module capability for the sub-module (this is not even supported in , let alone optional). * A module may not even have a revision. > As an alternative to a operation, there could be a state > data node containing this information, similar to the intent of the > SNMPv2-MIB sysORTable. > there is already no need for a special operation >> It would be good if we can bring this to a conclusion >> and the draft one step further soon. >> >> Cheers, >> Mehmet >> > > Just my attempt to be helpful. > > Regards, > > Mark > Andy From mark@ellisonsoftware.com Fri Oct 2 09:52: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 59D003A6A5B for ; Fri, 2 Oct 2009 09:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.885 X-Spam-Level: X-Spam-Status: No, score=-101.885 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJlo7vQRvlVo for ; Fri, 2 Oct 2009 09:52:30 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 637A13A69AB for ; Fri, 2 Oct 2009 09:52:30 -0700 (PDT) Received: by bwz6 with SMTP id 6so1177288bwz.37 for ; Fri, 02 Oct 2009 09:53:53 -0700 (PDT) MIME-Version: 1.0 Sender: mark@ellisonsoftware.com Received: by 10.204.154.150 with SMTP id o22mr1343029bkw.154.1254502433386; Fri, 02 Oct 2009 09:53:53 -0700 (PDT) In-Reply-To: <4AC615FC.2050307@netconfcentral.com> References: <4AC0ED35.3070404@netconfcentral.com> <20091001.083617.169773375.mbj@tail-f.com> <4AC4A86E.6000701@netconfcentral.com> <085091CB2CA14E4B8B163FFC37C84E9D1A806F54@zcarhxm0.corp.nortel.com> <4AC54594.80105@netconfcentral.com> <8a0268750910020621i3fd997aaqec36f7b81d6b3040@mail.gmail.com> <4AC615FC.2050307@netconfcentral.com> Date: Fri, 2 Oct 2009 12:53:53 -0400 X-Google-Sender-Auth: ad3538db3bad4f0b Message-ID: <8a0268750910020953k214a4388v205e645a46ce258a@mail.gmail.com> From: Mark Ellison To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] mandatory parms discussion X-BeenThere: netconf@ietf.org X-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, 02 Oct 2009 16:52:31 -0000 On Fri, Oct 2, 2009 at 11:02 AM, Andy Bierman wrote: > Mark Ellison wrote: [deletions] > >> As an alternative to a operation, there could be a state >> data node containing this information, similar to the intent of the >> SNMPv2-MIB sysORTable. >> > > there is already > > no need for a special operation > Thanks for pointing this out to me. I'll take a 'my bad' on this for not having read through the netconf-monitoring draft prior to articulating my thoughts. [deletions] > > > Andy > Regards, Mark From xiangli@iwlcorp.com Mon Oct 5 09:45: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 60D4928C239 for ; Mon, 5 Oct 2009 09:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=1.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, SARE_SUB_OBFU_Q0=0.303, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppv17MEQmavo for ; Mon, 5 Oct 2009 09:45:31 -0700 (PDT) Received: from smtp244.iad.emailsrvr.com (smtp244.iad.emailsrvr.com [207.97.245.244]) by core3.amsl.com (Postfix) with ESMTP id 81F9828C207 for ; Mon, 5 Oct 2009 09:45:31 -0700 (PDT) Received: from relay14.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay14.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 60F6C22AF72 for ; Mon, 5 Oct 2009 12:47:02 -0400 (EDT) Received: from dynamic6.wm-web.iad.mlsrvr.com (dynamic6.wm-web.iad.mlsrvr.com [192.168.2.147]) by relay14.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 5B6EF22A50E for ; Mon, 5 Oct 2009 12:47:02 -0400 (EDT) Received: from iwlcorp.com (localhost [127.0.0.1]) by dynamic6.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 4AF4B3F019C for ; Mon, 5 Oct 2009 12:47:02 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: xiangli@iwlcorp.com, from: xiangli@iwl.com) with HTTP; Mon, 5 Oct 2009 09:47:02 -0700 (PDT) Date: Mon, 5 Oct 2009 09:47:02 -0700 (PDT) From: "Xiang Li" To: netconf@core3.amsl.com MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: <20091005163951.059743A691C@core3.amsl.com> References: <20091005163951.059743A691C@core3.amsl.com> Message-ID: <1254761222.301417032@192.168.1.201> X-Mailer: webmail7.0 Subject: Re: [Netconf] =?utf-8?q?Confirm=3A_netconf=40core3=2Eamsl=2Ecom=3Axc?= =?utf-8?q?=5FT3OSsohVg=3ADeW74Z0QDzXQ7xcer8aZof7GDX5ApqJENX=5F4vg?= X-BeenThere: netconf@ietf.org X-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, 05 Oct 2009 16:54:24 -0000 =0A=0Anetconf@core3.amsl.com said:=0A=0A> =0A> Confirmation of list posting= -- confirmation ID: xc_T3OSsohVg=0A> =0A> The ietf.org mailing-list server= has received a list posting from=0A> xiangli@iwlcorp.com to netconf@core3.= amsl.com with the subject=0A> '=3D?UTF-8?Q?namespace=3D20issue=3D20in=3D20t= he=3D20sample=3D20=3D20in=3D20RFC474?=3D=0A> =3D?UTF-8?Q?2=3D20netc= onf=3D20over=3D20ssh?=3D'=0A> =0A> As the sender address isn't subscribed t= o the list, and has not been=0A> confirmed earlier, we have to request a co= nfirmation of the address.=0A> To confirm the address, send a message to ne= tconf@core3.amsl.com,=0A> with the same subject line as this message.=0A> = =0A> (Simply sending a 'reply' to this message should work from most email= =0A> interfaces, since that usually leaves the subject line in the right=0A= > form. The reply's additional "Re:" is ok.)=0A> =0A> If you do not wish y= our posting to the list to go through, simply=0A> disregard this message. = Questions to postmaster@ietf.org.=0A> =0A> =0A From xiangli@iwlcorp.com Mon Oct 5 11:00: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 112B628C245 for ; Mon, 5 Oct 2009 11:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=1.543, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sd9erGaO1UAD for ; Mon, 5 Oct 2009 11:00:53 -0700 (PDT) Received: from smtp184.iad.emailsrvr.com (smtp184.iad.emailsrvr.com [207.97.245.184]) by core3.amsl.com (Postfix) with ESMTP id D9C5228C1CD for ; Mon, 5 Oct 2009 11:00:52 -0700 (PDT) Received: from relay8.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay8.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id E4684203D8E for ; Mon, 5 Oct 2009 14:02:27 -0400 (EDT) Received: from dynamic5.wm-web.iad.mlsrvr.com (dynamic5.wm-web.iad.mlsrvr.com [192.168.2.146]) by relay8.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 95C85202E08 for ; Mon, 5 Oct 2009 14:02:27 -0400 (EDT) Received: from iwlcorp.com (localhost [127.0.0.1]) by dynamic5.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 6F29F8D006E for ; Mon, 5 Oct 2009 14:02:27 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: xiangli@iwlcorp.com, from: xiangli@iwl.com) with HTTP; Mon, 5 Oct 2009 11:02:27 -0700 (PDT) Date: Mon, 5 Oct 2009 11:02:27 -0700 (PDT) From: "Xiang Li" To: netconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1254765747.450910030@192.168.1.70> X-Mailer: webmail7.0 Subject: [Netconf] =?utf-8?q?namespace_issue_in_the_sample_=3Chello=3E_in_?= =?utf-8?q?RFC474_2_netconf_over_ssh?= X-BeenThere: netconf@ietf.org X-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, 05 Oct 2009 18:00:54 -0000 Hi=0A =0AIn RFC4271, the sample hello message shows the must be in = the netconf namespace:=0A=0A =0A =0A =0A urn:= ietf:params:netconf:base:1.0=0A =0A =0A=0ABut = in RFC4272 Netconf over SSH, the sample hello does not use=0Athe netconf na= mespace:=0A=0A C: =0A C: =0A C: =0A C: urn:ietf:params:xml:ns:netconf:base:1.0=0A C: <= /capability>=0A C: =0A C: =0A C: ]]>]]>= =0A=0A=0AIt appears to me this is a bug in RFC4742 since RFC4741 says:=0A= =0A3.1. Namespace=0A=0A All NETCONF protocol elements are defined in the= following namespace:=0A=0A urn:ietf:params:xml:ns:netconf:base:1.0=0A= =0A=0AI actually saw an implementation's message using the format a= s=0Adocumented in RFC4742.=0A=0A=0AThanks,=0AXiang Li From MARKSCOT@nortel.com Mon Oct 5 14:08: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 A62D828C20B for ; Mon, 5 Oct 2009 14:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 obG3zIQeNkU9 for ; Mon, 5 Oct 2009 14:08:13 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8332F3A67E4 for ; Mon, 5 Oct 2009 14:08:13 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n95L99B25866; Mon, 5 Oct 2009 21:09:10 GMT 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, 5 Oct 2009 17:09:07 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D1A8B09AB@zcarhxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] comments on monitoring-08 draft Thread-Index: AcpC9jPJPLZkzhaLQ0Go4Oxsdq48cQAT3WmgAK6FIjA= References: <4AC0ED35.3070404@netconfcentral.com><20091001.083617.169773375.mbj@tail-f.com> <4AC547A6.8010701@netconfcentral.com> From: "Mark Scott" To: "Ersue, Mehmet (NSN - DE/Munich)" , "ext Andy Bierman" Cc: netconf@ietf.org Subject: Re: [Netconf] comments on monitoring-08 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, 05 Oct 2009 21:08:14 -0000 All, The definition will be reverted to the -07 version per Andy's earlier suggestion. Mark -----Original Message----- From: Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com]=20 Sent: Friday, October 02, 2009 6:06 AM To: ext Andy Bierman; Scott, Mark (CAR:2N00) Cc: netconf@ietf.org; Martin Bjorklund Subject: RE: [Netconf] comments on monitoring-08 draft Hi Mark, Andy, it is common practice that during WGLC or later in the=20 process that the document editor does not do changes=20 without without making sure that such a change is=20 supported by the WG (and the co-chairs). Our goal at=20 this late stage should be to finalize the document text. I would suggest to start a new discussion if you=20 strongly believe the change is necessary. Otherwise my proposal as a co-chair would be to redo=20 the change for "transport" vs. "session-type" even=20 though it was well-meant. Cheers, Mehmet =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy Bierman > Sent: Friday, October 02, 2009 2:22 AM > To: Martin Bjorklund > Cc: netconf@ietf.org > Subject: Re: [Netconf] comments on monitoring-08 draft >=20 > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> I noticed that the 'transport' identity was replaced > >> with a 'session-type' identity, and now the > >> /sessions/session/transport leaf > >> has been changed to a session-type leaf. Yet no new > >> standard identities were added, and no semantics were > >> altered. > >=20 > > Right, this was just a name change of the identity. > >=20 >=20 > No it was not: >=20 > leaf session-type { > mandatory true; > type identityref { > base session-type; > } > } >=20 >=20 > The enum choices are: >=20 > netconf-ssh > netconf-soap-over-beep > netconf-soap-over-https > netconf-beep > netconf-tls >=20 > These match the transport mappings for NETCONF. > In all the NETCONF RFCs, these are called transport mappings, > not session types. >=20 > I object to this change -- this entire change should be > removed, and the -07 text should be restored. >=20 >=20 > >=20 > > /martin > >=20 >=20 >=20 > Andy >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From MARKSCOT@nortel.com Mon Oct 5 14:19: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 7821D3A684E for ; Mon, 5 Oct 2009 14:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 bT+rKGLHceBG for ; Mon, 5 Oct 2009 14:19:14 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 2C5593A67ED for ; Mon, 5 Oct 2009 14:19:08 -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 n95LK1L25821; Mon, 5 Oct 2009 21:20:01 GMT 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, 5 Oct 2009 17:19:59 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D1A8B09CB@zcarhxm0.corp.nortel.com> In-Reply-To: <20091002.122230.150751249.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] [NETCONF] mandatory parms discussion Thread-Index: AcpDSkEuxtPP7qaRQRany8r/x/s5egCkNMrA References: <085091CB2CA14E4B8B163FFC37C84E9D1A806F54@zcarhxm0.corp.nortel.com><4AC54594.80105@netconfcentral.com> <20091002.122230.150751249.mbj@tail-f.com> From: "Mark Scott" To: "Martin Bjorklund" , Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] mandatory parms discussion X-BeenThere: netconf@ietf.org X-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, 05 Oct 2009 21:19:15 -0000 Martin and Andy, Agreed we can make and optional so long as the server returns an error if more than one entry exists with the same . The revised negative responses (sec 3.1) proposed: If requested schema does not exist, the is 'invalid-value'. If requested schema is not unique, the is 'operation-failed' and the is 'data-not-unique'. Default of YANG is also specified in sec 3.1, and example 2b is updated to show default of YANG when format not specified. and the revised RPC definition proposed: rpc get-schema { description "When the schema is available on the device this operation is used to return it via NETCONF. If requested schema does not exist, the is 'invalid-value'. If requested schema is not unique, the is 'operation-failed' and the is 'data-not-unique'."; input { leaf identifier { type string; mandatory true; } leaf version { type string; } leaf format { type identityref { base schema-format; } } } output { anyxml data { description "Contains the schema content."; } } These updates will be made in v-09 update. Any comments or concerns please raise them. =20 cheers, Mark -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Friday, October 02, 2009 6:23 AM To: mehmet.ersue@nsn.com Cc: andy@netconfcentral.com; Scott, Mark (CAR:2N00); netconf@ietf.org Subject: Re: [Netconf] [NETCONF] mandatory parms discussion "Ersue, Mehmet (NSN - DE/Munich)" wrote: >=20 > Hi Mark, Andy,=20 >=20 > modifying the the mandatory parameters in =20 > has been proposed earlier in September. There were no=20 > arguments against it at that time. >=20 > In the sake of progress I would like to ask you to try=20 > to converge on a solution. > OTHERS: PLEASE speak up if you agree or disagree with=20 > any points made by either Mark or Andy. I agree with Andy, i.e. and should be optional. I think Mark's concern that the client might get a schema it didn't intended is covered by saying that if there are more than one schema with the given , an error is returned. In this case the client must give all parameters. /martin From andy@netconfcentral.com Mon Oct 5 15:03: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 251C43A6A4C for ; Mon, 5 Oct 2009 15:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 ITmrZ3c1UN99 for ; Mon, 5 Oct 2009 15:03:29 -0700 (PDT) Received: from n16a.bullet.mail.mud.yahoo.com (n16a.bullet.mail.mud.yahoo.com [68.142.207.126]) by core3.amsl.com (Postfix) with SMTP id 28F703A6A4B for ; Mon, 5 Oct 2009 15:03:29 -0700 (PDT) Received: from [68.142.200.227] by n16.bullet.mail.mud.yahoo.com with NNFMP; 05 Oct 2009 22:05:03 -0000 Received: from [68.142.201.71] by t8.bullet.mud.yahoo.com with NNFMP; 05 Oct 2009 22:05:03 -0000 Received: from [127.0.0.1] by omp423.mail.mud.yahoo.com with NNFMP; 05 Oct 2009 22:05:03 -0000 X-Yahoo-Newman-Id: 401980.24158.bm@omp423.mail.mud.yahoo.com Received: (qmail 70785 invoked from network); 5 Oct 2009 22:05:02 -0000 Received: from adsl-68-120-81-206.dsl.irvnca.pacbell.net (andy@68.120.81.206 with plain) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 05 Oct 2009 15:05:02 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: qriOQl8VM1keiCVisYBuF11DT4N03ucaoHKagt4Nylm7YOwpfds3AKssDZYiwGatcmy1LE5GHvMBvUAlcn5Gnlq5e3.FITeuhoGjehda5_HJkOTXb6g5oCWeyqdnQdjZbZUXUPttyCWg9ZatmyTQhfRKu2N1vOtziuo7Awpf7_mg4UnX.EJn35Cm14c2Y3mBZ4HWZgSkAXtA.pn0V7WQkqZu08kAYBN2Ben4wzbbjstDlMmp7iq_Wy.pu_in7Ht3dRCmAj_1E9O1BAT9ZT5T3nNlL82vJcNp X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACA6D84.9040105@netconfcentral.com> Date: Mon, 05 Oct 2009 15:04:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Mark Scott References: <085091CB2CA14E4B8B163FFC37C84E9D1A806F54@zcarhxm0.corp.nortel.com><4AC54594.80105@netconfcentral.com> <20091002.122230.150751249.mbj@tail-f.com> <085091CB2CA14E4B8B163FFC37C84E9D1A8B09CB@zcarhxm0.corp.nortel.com> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D1A8B09CB@zcarhxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] mandatory parms discussion X-BeenThere: netconf@ietf.org X-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, 05 Oct 2009 22:03:30 -0000 Mark Scott wrote: > Martin and Andy, > > Agreed we can make and optional so long as the server > returns an error if more than one entry exists with the same > . IMO, if is empty, then the server needs to pick a version. It SHOULD be the most recent version (perhaps MUST). The module itself will indicate the revision, if the client really cares. The operator may not know the revision, or really care. I prefer text that says: If the version parameter is missing, and the /netconf-state/schemas/schema list contains more than one entry for a specific identifier value, then the server SHOULD return the more recent version. This is better for servers that will just have the most recent version of accessible modules, and rarely have more than 1 version of a groupings/typedefs module. > > The revised negative responses (sec 3.1) proposed: > If requested schema does not exist, the is > 'invalid-value'. > If requested schema is not unique, the is > 'operation-failed' and the is 'data-not-unique'. > > Default of YANG is also specified in sec 3.1, and example 2b is > updated to show default of YANG when format not specified. > > and the revised RPC definition proposed: > rpc get-schema { > description > "When the schema is available on the device this operation is > used to return it via NETCONF. If requested schema > does not exist, > the is 'invalid-value'. If requested schema > is not unique, > the is 'operation-failed' and the > is > 'data-not-unique'."; > input { > leaf identifier { > type string; > mandatory true; > } > leaf version { > type string; > } > leaf format { > type identityref { > base schema-format; > } > } > } > output { > anyxml data { > description "Contains the schema content."; > } > } > > These updates will be made in v-09 update. Any comments or concerns > please raise them. > > cheers, > Mark > Andy > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Friday, October 02, 2009 6:23 AM > To: mehmet.ersue@nsn.com > Cc: andy@netconfcentral.com; Scott, Mark (CAR:2N00); netconf@ietf.org > Subject: Re: [Netconf] [NETCONF] mandatory parms discussion > > "Ersue, Mehmet (NSN - DE/Munich)" wrote: >> Hi Mark, Andy, >> >> modifying the the mandatory parameters in >> has been proposed earlier in September. There were no >> arguments against it at that time. >> >> In the sake of progress I would like to ask you to try >> to converge on a solution. >> OTHERS: PLEASE speak up if you agree or disagree with >> any points made by either Mark or Andy. > > I agree with Andy, i.e. and should be optional. I > think Mark's concern that the client might get a schema it didn't > intended is covered by saying that if there are more than one schema > with the given , an error is returned. In this case the > client must give all parameters. > > > /martin > From Washam.Fan@huaweisymantec.com Tue Oct 6 07:00: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 47BD13A68B4 for ; Tue, 6 Oct 2009 07:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.934 X-Spam-Level: X-Spam-Status: No, score=-0.934 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOvWcF27SJXM for ; Tue, 6 Oct 2009 07:00:40 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 4BA9A3A659C for ; Tue, 6 Oct 2009 07:00:40 -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.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KR300K0QIZ62Q70@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Tue, 06 Oct 2009 22:01:55 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KR300JOIIZ6VO10@hstml02-in.huaweisymantec.com> for netconf@ietf.org; Tue, 06 Oct 2009 22:01:54 +0800 (CST) Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Tue, 06 Oct 2009 22:01:54 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Tue, 06 Oct 2009 22:01:54 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4ACA6D84.9040105@netconfcentral.com> References: <085091CB2CA14E4B8B163FFC37C84E9D1A806F54@zcarhxm0.corp.nortel.com> <4AC54594.80105@netconfcentral.com> <20091002.122230.150751249.mbj@tail-f.com> <085091CB2CA14E4B8B163FFC37C84E9D1A8B09CB@zcarhxm0.corp.nortel.com> <4ACA6D84.9040105@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] mandatory parms discussion X-BeenThere: netconf@ietf.org X-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, 06 Oct 2009 14:00:41 -0000 > Mark Scott wrote: > > Martin and Andy, > > > > Agreed we can make and optional so long as the server > > returns an error if more than one entry exists with the same > > . > > > IMO, if is empty, then the server needs to pick a version. > It SHOULD be the most recent version (perhaps MUST). Or the version the server supports? Did you imply no "data-not-unique" error is returned when the parameters are missing, instead, the server will use defaults when the parameters are missing? washam From Washam.Fan@huaweisymantec.com Tue Oct 6 07:05: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 332D228C1BD for ; Tue, 6 Oct 2009 07:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AMHAEo8uBRJ for ; Tue, 6 Oct 2009 07:04:59 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 69EBC28C188 for ; Tue, 6 Oct 2009 07:04:59 -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-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KR3002XXJ66LW10@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Tue, 06 Oct 2009 22:06:06 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KR300JPWJ66R610@hstml02-in.huaweisymantec.com> for netconf@ietf.org; Tue, 06 Oct 2009 22:06:06 +0800 (CST) Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Tue, 06 Oct 2009 22:06:06 +0800 From: WashamFan To: Xiang Li Message-id: Date: Tue, 06 Oct 2009 22:06:06 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <1254765747.450910030@192.168.1.70> References: <1254765747.450910030@192.168.1.70> Cc: netconf@ietf.org Subject: Re: [Netconf] namespace issue in the sample in RFC474 2 netconf over ssh X-BeenThere: netconf@ietf.org X-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, 06 Oct 2009 14:05:00 -0000 > I actually saw an implementation's message using the format as > documented in RFC4742. I don't think the implementation is a compliant one. (Maybe, the implementation can interoperate with a complicant one) washam > > Thanks, > Xiang Li From andy@netconfcentral.com Tue Oct 6 07:35: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 3E1213A6848 for ; Tue, 6 Oct 2009 07:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 a8KeTcqe07L9 for ; Tue, 6 Oct 2009 07:35:13 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id D7C1F3A68E8 for ; Tue, 6 Oct 2009 07:35:12 -0700 (PDT) Received: (qmail 54765 invoked from network); 6 Oct 2009 14:36:48 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.81.206 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 6 Oct 2009 14:36:47 -0000 X-YMail-OSG: AMtD1f0VM1mtyh4gj.Ul.fLM5cjqE9j.zNfUG7O2GibyNQsX3kskkQF1I4zyVUQ5VrYR72Pqr6wy2qY2hdCEXUEED0kxjVXrOuCYAawctSIAf44bTldzhBOiGshdZpxChnulTwLC7aNtgRHkVML1._zTDcJWZm33nz_XmU6..ZlB.pxRRaLM4N6dc1Xdqfa3KgmZGvlNh2X7Xz4jlPUaszgOmZE5jkqKuU_1nLG4dZv9CT0f6aj6q38p4IRlEeI..WNjQKsGrBICnlsvWS4gmIdc7ba0ZL44dm864uNT1rYSmgEzbLzchZd5Cxxg2IVlAw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACB55F4.1060708@netconfcentral.com> Date: Tue, 06 Oct 2009 07:36:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: WashamFan References: <085091CB2CA14E4B8B163FFC37C84E9D1A806F54@zcarhxm0.corp.nortel.com> <4AC54594.80105@netconfcentral.com> <20091002.122230.150751249.mbj@tail-f.com> <085091CB2CA14E4B8B163FFC37C84E9D1A8B09CB@zcarhxm0.corp.nortel.com> <4ACA6D84.9040105@netconfcentral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] [NETCONF] mandatory parms discussion X-BeenThere: netconf@ietf.org X-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, 06 Oct 2009 14:35:14 -0000 WashamFan wrote: >> Mark Scott wrote: >>> Martin and Andy, >>> >>> Agreed we can make and optional so long as the server >>> returns an error if more than one entry exists with the same >>> . >> >> IMO, if is empty, then the server needs to pick a version. >> It SHOULD be the most recent version (perhaps MUST). > > Or the version the server supports? Did you imply > no "data-not-unique" error is returned when the parameters are > missing, instead, the server will use defaults when the parameters > are missing? Of course the server only returns revisions that it supports. It would return the most recent revision date of the schema list entries it has in its /netconf-state/schemas subtree. > > washam > Andy From Thilo.Garke@alcatel-lucent.de Tue Oct 6 07:12:02 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 26CB928C1BD for ; Tue, 6 Oct 2009 07:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.648 X-Spam-Level: X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, 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 UFJT75cDslZ6 for ; Tue, 6 Oct 2009 07:12:01 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 92B7B3A6884 for ; Tue, 6 Oct 2009 07:12:00 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n96ECqE7022392 for ; Tue, 6 Oct 2009 16:13:32 +0200 Received: from FRVELSMBS15.ad2.ad.alcatel.com ([155.132.6.35]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 16:12:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Oct 2009 16:12:50 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CA469F.D9AC90F0" Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Questions regarding with default-operation "none" Thread-Index: AcpGjxWsViI2DaRBStqf0d1s0QWhJg== From: "Garke Thilo" To: X-OriginalArrivalTime: 06 Oct 2009 14:12:52.0258 (UTC) FILETIME=[1788A820:01CA468F] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 X-Mailman-Approved-At: Tue, 06 Oct 2009 08:19:08 -0700 Subject: [Netconf] Questions regarding with default-operation "none" X-BeenThere: netconf@ietf.org X-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, 06 Oct 2009 14:14:25 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01CA469F.D9AC90F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_01CA469F.D9AC90F0" ------=_NextPart_001_0001_01CA469F.D9AC90F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi * I'm new to NETCONF and have two questions regarding in = case is set to "none". 1.) Does any operation given in a parent element apply to all its = children elements? 2.) If so, are nested operations valid such that the inner operation overrides the outer one? 3.) Would this imply that any operations inside of a merge operation are = not valid? Thanks in advance for any helpful reply. Best regards, Thilo Garke Development Engineer MS/E (LTE OAM) Lorenzstra=DFe 10 Building 5/2/67 70430 Stuttgart Email: Thilo.Garke@alcatel-lucent.de Phone: ++49 (0)711 821 30334 Alcatel-Lucent Deutschland AG Sitz der Gesellschaft: Stuttgart =B7 Amtsgericht Stuttgart HRB 4026 Vorsitzender des Aufsichtsrates: Michael Oppenhoff Vorstand: Alf Henryk Wulf (Vorsitzender) =B7 Hans-J=F6rg Daub =B7 Dr.=20 Rainer Fechner =B7 Peter Kury ------=_NextPart_001_0001_01CA469F.D9AC90F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Questions regarding <edit-config> with default-operation = "none"

Hi *

I'm new to NETCONF and have two = questions regarding <edit-config> in case = <default-operation> is set to "none".

1.) Does any operation given in a = parent element apply to all its children elements?

2.) If so, are nested operations valid = such that the inner operation overrides the outer one?

3.) Would this imply that any = operations inside of a merge operation are not valid?

Thanks in advance for any helpful = reply.

Best regards,

Thilo Garke
Development = Engineer
MS/E (LTE OAM)
Lorenzstra=DFe = 10
Building 5/2/67
70430 = Stuttgart
Email: = Thilo.Garke@alcatel-lucent.de
Phone: ++49 (0)711 = 821 30334

Alcatel-Lucent Deutschland = AG
Sitz der Gesellschaft: Stuttgart = =B7 Amtsgericht Stuttgart HRB 4026 Vorsitzender des Aufsichtsrates: = Michael Oppenhoff
Vorstand:  Alf Henryk Wulf = (Vorsitzender) =B7 Hans-J=F6rg Daub =B7 Dr.
Rainer Fechner =B7 Peter = Kury

------=_NextPart_001_0001_01CA469F.D9AC90F0-- ------=_NextPart_000_0000_01CA469F.D9AC90F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWUDCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggT0MIID3KADAgECAgojlVoEAAAAAAAL MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyNjE4MTkzNloXDTE4MTEyNjE4Mjkz NlowgZwxEzARBgoJkiaJk/IsZAEZFgNjb20xFzAVBgoJkiaJk/IsZAEZFgdhbGNhdGVsMRIwEAYK CZImiZPyLGQBGRYCYWQxEzARBgoJkiaJk/IsZAEZFgNhZDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVj ZW50MSowKAYDVQQDEyFBbGNhdGVsIEx1Y2VudCBBRCBJbnRlcm5hbCBTdWIgQ0EwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC2DpkqrHxaolxoM6VB0MWrYQfD3VB9FAP3r7lEbpsrOiy0 9VSIEuefQ5JYwoxhG3yQk2dIADl7hdMVWozjWc3v2NOO9D27CcEoLuMevevA7btTo5F5Zqq+M6bn J08vTSRbPVzC3kTVBCGFVEOBm0CPblx2MnC1/iRH7EXxYrRchRkOKFUGUZ7+opszni+wU0AvzXgR ftK0zH9G1ajZRb/5QpQZkEuJ4lqajHcEv77b+Op3goKBr1V9ojrAUHab3ktWtVGLHYue9oBIaYLW eHkZdMIg+MB0JtdyzRA98u/WAcMCjoKsuG3jgJRYn/V41vKnWxB1uP81ErqSPDr5KUt9AgMBAAGj ggGOMIIBijAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTb0a4tSs5Q3zGk62BUQnO8qHvmZTAL BgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEw HwYDVR0jBBgwFoAUB6yyWvZhiXxcfOvilycpaQyKH/AweAYDVR0fBHEwbzBtoGugaYY5aHR0cDov L3NlcnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3JshixodHRw Oi8vd3d3LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybDCBggYIKwYBBQUHAQEEdjB0 MDgGCCsGAQUFBzAChixodHRwOi8vd3d3LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNy dDA4BggrBgEFBQcwAoYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5j cnQwDQYJKoZIhvcNAQEFBQADggEBAG/kdQHOPu356b7Lu94Q8hmx1agUxBC15hkj5xh7TekDygtf o3YKSWZTMuw2LXvajIjzitTg9pYOvWeP7MmyMRor/UJd6RR0aqQLpvIYSOmH4IDm6TAeLB/0xiX+ ZcSI60e8Zpu8hWCssS0ce/71qYmlghZ4BEHU9v1mCBdiYB7SIFfRQAE9wCEKklFWosoT7CJGWBU9 t9VBndeRLDmndWwv2IRf98gX9nDbK0dhDMCfvJ+8zCoDbZm6E40CWBI6SVaiXlkFcpPNoJupAaAu YyGrkB638wy9otRl+23czLQYpcuopZ9WvzOUvf2ka05aHpAzRv7OG/IFnY/A6ltnAxQwggaeMIIF hqADAgECAgpkafy7AAAAAAUUMA0GCSqGSIb3DQEBBQUAMIGcMRMwEQYKCZImiZPyLGQBGRYDY29t MRcwFQYKCZImiZPyLGQBGRYHYWxjYXRlbDESMBAGCgmSJomT8ixkARkWAmFkMRMwEQYKCZImiZPy LGQBGRYDYWQyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEqMCgGA1UEAxMhQWxjYXRlbCBMdWNl bnQgQUQgSW50ZXJuYWwgU3ViIENBMB4XDTA5MDgxMzA3NDYyN1oXDTExMDgxMzA3NDYyN1owQDEQ MA4GA1UEAxMHbGkwNDg2MjEsMCoGCSqGSIb3DQEJARYdVGhpbG8uR2Fya2VAYWxjYXRlbC1sdWNl bnQuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJ9uoPXfkuuzb/CbfQJMQV+h6UdbEbkC 96phhnpW4qpSY8XDHiwL6TopFATjFNQ0z+SvdpOw4DF6qUa+djPQun/ITlc6XQqP0M5JnLXttV2Y rMJ1s/SzJPTk4xetR1FiBzBT21LzrWW/QXyRi6hq0eFzqDS+PUI1jT6OHgUFJQVlAgMBAAGjggO/ MIIDuzALBgNVHQ8EBAMCB4AwHQYDVR0OBBYEFKCQcoDqydTQniMjKpGIOx0FLLnhMDwGCSsGAQQB gjcVBwQvMC0GJSsGAQQBgjcVCITK+0yGwYV3kY8og4arK4bD2UsNhYOdYIWPlUYCAWQCAQswHwYD VR0jBBgwFoAU29GuLUrOUN8xpOtgVEJzvKh75mUwggFkBgNVHR8EggFbMIIBVzCCAVOgggFPoIIB S4aB3WxkYXA6Ly8vQ049QWxjYXRlbCUyMEx1Y2VudCUyMEFEJTIwSW50ZXJuYWwlMjBTdWIlMjBD QSxDTj1mcm1yc3Nwa2kwMnAsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9YWxjYXRlbCxEQz1jb20/Y2VydGlmaWNh dGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hi1o dHRwOi8vd3d3LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvQURzdWJDQS5jcmyGOmh0dHA6Ly9zZXJ2 aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvQURzdWJDQS5jcmwwggFoBggrBgEF BQcBAQSCAVowggFWMIHQBggrBgEFBQcwAoaBw2xkYXA6Ly8vQ049QWxjYXRlbCUyMEx1Y2VudCUy MEFEJTIwSW50ZXJuYWwlMjBTdWIlMjBDQSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2Vydmlj ZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1hZCxEQz1hbGNhdGVsLERDPWNvbT9j QUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA5Bggr BgEFBQcwAoYtaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL0FEc3ViQ0EuY3J0MEYG CCsGAQUFBzAChjpodHRwOi8vc2VydmljZXMuc3VwcG9ydC5hbGNhdGVsLWx1Y2VudC5jb20vUEtJ L0FEc3ViQ0EuY3J0MBMGA1UdJQQMMAoGCCsGAQUFBwMEMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYB BQUHAwQwKAYDVR0RBCEwH4EdVGhpbG8uR2Fya2VAYWxjYXRlbC1sdWNlbnQuZGUwDQYJKoZIhvcN AQEFBQADggEBAIiOuYIO611V5ihsEZ9lx7kVetw+qyWs1QBsWU7ZRaYqnwlvMbO0RYCiiHGlAxqj Ry+p+0CgFLsrLhn6QlWnZjeLF02Z0kv2LY7m2ySGkzjkSnvU79MlI9ouwFqVmacd2Q2tUvM0pGlc 1HaAQ17hyOWuzPhsy85R8Vq9hfjeYzhyI2PkByFOqDlRPDVTJuBjAJZamU+btE2MBEf42STjaT0p bm2TpKmfAYMUSjKoE/dPd6T2utXkL6tGQ1CJ8+baiGHiSj90cFgeGT/TnbgsmEFl5wk8m293m1ka IensM2UAtvUTISoyoFDrjcQguRLieYFZJtMkbtGS8XTTkkUyATQwggb9MIIF5aADAgECAgpkatg3 AAAAAAUVMA0GCSqGSIb3DQEBBQUAMIGcMRMwEQYKCZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPy LGQBGRYHYWxjYXRlbDESMBAGCgmSJomT8ixkARkWAmFkMRMwEQYKCZImiZPyLGQBGRYDYWQyMRcw FQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEqMCgGA1UEAxMhQWxjYXRlbCBMdWNlbnQgQUQgSW50ZXJu YWwgU3ViIENBMB4XDTA5MDgxMzA3NDcyNloXDTExMDgxMzA3NDcyNlowQDEQMA4GA1UEAxMHbGkw NDg2MjEsMCoGCSqGSIb3DQEJARYdVGhpbG8uR2Fya2VAYWxjYXRlbC1sdWNlbnQuZGUwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAKSyJDnQZkBqUTkSms+U0YHxcpB/Zmxk4p+z/NstQkEgILdp T+4J2TFJlv1hn1AChtOqa1AxOsQqTI733UFqRyMLznyNlllRt1dAaYrRPTIr2JhFfOsTeORE+xvj Uhifr5G5VNBL9c8435wUvpcvgvLKf+dGT8Nz1dgR1wr5cl7/AgMBAAGjggQeMIIEGjALBgNVHQ8E BAMCBSAwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAcG BSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTZGQgkmSTmtB9XXPKXRTFzAR9yoTA7BgkrBgEE AYI3FQcELjAsBiQrBgEEAYI3FQiEyvtMhsGFd5GPKIOGqyuGw9lLDYei6h7fo3oCAWQCAQswHwYD VR0jBBgwFoAU29GuLUrOUN8xpOtgVEJzvKh75mUwggFkBgNVHR8EggFbMIIBVzCCAVOgggFPoIIB S4aB3WxkYXA6Ly8vQ049QWxjYXRlbCUyMEx1Y2VudCUyMEFEJTIwSW50ZXJuYWwlMjBTdWIlMjBD QSxDTj1mcm1yc3Nwa2kwMnAsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9YWxjYXRlbCxEQz1jb20/Y2VydGlmaWNh dGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hi1o dHRwOi8vd3d3LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvQURzdWJDQS5jcmyGOmh0dHA6Ly9zZXJ2 aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvQURzdWJDQS5jcmwwggFoBggrBgEF BQcBAQSCAVowggFWMIHQBggrBgEFBQcwAoaBw2xkYXA6Ly8vQ049QWxjYXRlbCUyMEx1Y2VudCUy MEFEJTIwSW50ZXJuYWwlMjBTdWIlMjBDQSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2Vydmlj ZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1hZCxEQz1hbGNhdGVsLERDPWNvbT9j QUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA5Bggr BgEFBQcwAoYtaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL0FEc3ViQ0EuY3J0MEYG CCsGAQUFBzAChjpodHRwOi8vc2VydmljZXMuc3VwcG9ydC5hbGNhdGVsLWx1Y2VudC5jb20vUEtJ L0FEc3ViQ0EuY3J0MB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMEMCkGCSsGAQQBgjcV CgQcMBowCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDBDAoBgNVHREEITAfgR1UaGlsby5HYXJrZUBh bGNhdGVsLWx1Y2VudC5kZTANBgkqhkiG9w0BAQUFAAOCAQEAAW3FG8BhaY88lfDYmTkbBbBM8ti1 oRP7CW5ObBBY0pMlkelc91EL4ZDh0sJmBbMhOqo/LWKKTEq4Q2P/BHMI5xmf/Eb1QftV0y/Yg4pt th69XWp9O/CePB8neQis+wQHVvRC3dc4T65zkqXiaqBT9ps/BKKqNPYrWzl1Tah6ge6daieajqCF Zm5ebBrAj6A4tbSTn4KsPpHkyC4+GqYLsVfosoI1HH9W+ACP/UMKyVP8AR1d15ZQIceZxR8+SKb/ iYmValJln1lUXdBIIGo1V2gwB2cHpV6eNeUmf/V4uQtKk8WQl687i+ShZ2Xujd2YUhSb1AaSrGfx 5gX1wFIHIzGCA5wwggOYAgEBMIGrMIGcMRMwEQYKCZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPy LGQBGRYHYWxjYXRlbDESMBAGCgmSJomT8ixkARkWAmFkMRMwEQYKCZImiZPyLGQBGRYDYWQyMRcw FQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEqMCgGA1UEAxMhQWxjYXRlbCBMdWNlbnQgQUQgSW50ZXJu YWwgU3ViIENBAgpkafy7AAAAAAUUMAkGBSsOAwIaBQCgggJGMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTAwNjE0MTI0OVowIwYJKoZIhvcNAQkEMRYEFBwvhl4Q F9haROQ1wLb0d59tmSemMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIG8BgkrBgEEAYI3EAQxga4wgaswgZwxEzARBgoJkiaJk/IsZAEZFgNjb20xFzAVBgoJ kiaJk/IsZAEZFgdhbGNhdGVsMRIwEAYKCZImiZPyLGQBGRYCYWQxEzARBgoJkiaJk/IsZAEZFgNh ZDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSowKAYDVQQDEyFBbGNhdGVsIEx1Y2VudCBBRCBJ bnRlcm5hbCBTdWIgQ0ECCmRq2DcAAAAABRUwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGcMRMwEQYK CZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPyLGQBGRYHYWxjYXRlbDESMBAGCgmSJomT8ixkARkW AmFkMRMwEQYKCZImiZPyLGQBGRYDYWQyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEqMCgGA1UE AxMhQWxjYXRlbCBMdWNlbnQgQUQgSW50ZXJuYWwgU3ViIENBAgpkatg3AAAAAAUVMA0GCSqGSIb3 DQEBAQUABIGAGyz6LvGAK40t0YefeVRPD6I1rJxDsNjT+A0jMcn4XIkEXm+QMN+QEltoRLU663vW Os+2zCclTEVNk1HgktNrCspkadkLP6D5nXyYk+x9KNwMK3YkxGpqHbyttIKXO2Ku/KeJyevP2kIl BP/+C+VSi31mPZYyRfpnYS/zb8X2qngAAAAAAAA= ------=_NextPart_000_0000_01CA469F.D9AC90F0-- From andy@netconfcentral.com Tue Oct 6 08:43: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 A88F03A69F3 for ; Tue, 6 Oct 2009 08:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.813 X-Spam-Level: X-Spam-Status: No, score=-1.813 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, J_CHICKENPOX_46=0.6, UNPARSEABLE_RELAY=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 x5mm9NsLoWgZ for ; Tue, 6 Oct 2009 08:43:22 -0700 (PDT) Received: from n23b.bullet.mail.mud.yahoo.com (n23b.bullet.mail.mud.yahoo.com [68.142.206.142]) by core3.amsl.com (Postfix) with SMTP id C730B3A69F1 for ; Tue, 6 Oct 2009 08:43:22 -0700 (PDT) Received: from [209.191.108.97] by n23.bullet.mail.mud.yahoo.com with NNFMP; 06 Oct 2009 15:44:58 -0000 Received: from [68.142.201.243] by t4.bullet.mud.yahoo.com with NNFMP; 06 Oct 2009 15:44:58 -0000 Received: from [127.0.0.1] by omp404.mail.mud.yahoo.com with NNFMP; 06 Oct 2009 15:44:58 -0000 X-Yahoo-Newman-Id: 611412.12355.bm@omp404.mail.mud.yahoo.com Received: (qmail 56394 invoked from network); 6 Oct 2009 15:44:58 -0000 Received: from adsl-68-120-81-206.dsl.irvnca.pacbell.net (andy@68.120.81.206 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 06 Oct 2009 08:44:58 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: CWwvFDQVM1msjuCMBvLTKUQn4JZ0XX1xArg2E.Zki.qoILOy03rxKdBM2Qufg5wA0KaqYr.XxVcs4BqcVpERAjmenuDgTOU2gQKtLa42VpwnkX2ezTi_BcZTai1rvKQiICAqIE6v_5D47cw9ckCYziZTfzXWgzGpESCqc1IQ25aQAfLnQBwn8mdoZ71CHBY66qo9FevPk7Wn5JZC6Ugeb3urk7i8yaTyVKEs5CNFySvZ3bBxKs6kiHdTQXmQhoBU X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACB6577.3080601@netconfcentral.com> Date: Tue, 06 Oct 2009 08:42:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Garke Thilo References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Questions regarding with default-operation "none" X-BeenThere: netconf@ietf.org X-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, 06 Oct 2009 15:43:24 -0000 Garke Thilo wrote: > Hi * > > I'm new to NETCONF and have two questions regarding in > case is set to "none". > > 1.) Does any operation given in a parent element apply to all its > children elements? > yes > 2.) If so, are nested operations valid such that the inner operation > overrides the outer one? > Yes -- the operation changes. Some combinations do not make sense, and must be flagged as errors e.g., create inside delete, delete inside create. Some combinations may make sense, depending on your interpretation (the NETCONF RFC is silent on this entire issue). E.g., merge or replace inside delete. > 3.) Would this imply that any operations inside of a merge operation are > not valid? no. Any operation can work inside merge, providing that the data model requirements are met (for create or delete). IMO, the server needs to handle an arbitrary mix of nc:operation attributes. I've heard that some implementations do not handle nc:operation very well at all (like allowing just 1 instance of the nc:operation attribute in the entire element.) The yang:insert operation complicates matters a bit, but you may not be implementing YANG, and don't need to worry about it :-) > > Thanks in advance for any helpful reply. > > Best regards, > > Thilo Garke Andy From shikhar@schmizz.net Wed Oct 7 00:11:39 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 E048C3A6986 for ; Wed, 7 Oct 2009 00:11:39 -0700 (PDT) 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 tK81jjifHEn6 for ; Wed, 7 Oct 2009 00:11:39 -0700 (PDT) Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.210.194]) by core3.amsl.com (Postfix) with ESMTP id 2613E3A691C for ; Wed, 7 Oct 2009 00:11:34 -0700 (PDT) Received: by yxe32 with SMTP id 32so4977003yxe.5 for ; Wed, 07 Oct 2009 00:13:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.205.8 with SMTP id h8mr2617250anq.142.1254899589371; Wed, 07 Oct 2009 00:13:09 -0700 (PDT) In-Reply-To: References: <1254765747.450910030@192.168.1.70> Date: Wed, 7 Oct 2009 09:13:09 +0200 Message-ID: <309bec650910070013g129abe0eueebbd1fb0949807@mail.gmail.com> From: shikhar To: WashamFan Content-Type: text/plain; charset=ISO-8859-1 Cc: netconf@ietf.org Subject: Re: [Netconf] namespace issue in the sample in RFC474 2 netconf over ssh X-BeenThere: netconf@ietf.org X-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, 07 Oct 2009 07:11:40 -0000 On Tue, Oct 6, 2009 at 4:06 PM, WashamFan wrote: >> I actually saw an implementation's message using the format as >> documented in RFC4742. Ditto > I don't think the implementation is a compliant one. (Maybe, the > implementation can interoperate with a complicant one) Not without a workaround. Well, technically it is compliant with RFC 4742 but non-compliant with RFC 4741, so that's a bug that needs fixing. Shikhar > washam > >> >> Thanks, >> Xiang Li > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From mbj@tail-f.com Wed Oct 7 00:22:02 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 1364D3A683D for ; Wed, 7 Oct 2009 00:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[AWL=-0.901, BAYES_20=-0.74, 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 pgBM3QlYfK99 for ; Wed, 7 Oct 2009 00:22:01 -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 4FF6D3A67E5 for ; Wed, 7 Oct 2009 00:22:01 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 6D6F7616018; Wed, 7 Oct 2009 09:23:35 +0200 (CEST) Date: Wed, 07 Oct 2009 09:23:35 +0200 (CEST) Message-Id: <20091007.092335.142865395.mbj@tail-f.com> To: shikhar@schmizz.net From: Martin Bjorklund In-Reply-To: <309bec650910070013g129abe0eueebbd1fb0949807@mail.gmail.com> References: <1254765747.450910030@192.168.1.70> <309bec650910070013g129abe0eueebbd1fb0949807@mail.gmail.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] namespace issue in the sample in RFC474 2 netconf over ssh X-BeenThere: netconf@ietf.org X-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, 07 Oct 2009 07:22:02 -0000 shikhar wrote: > On Tue, Oct 6, 2009 at 4:06 PM, WashamFan > > I don't think the implementation is a compliant one. (Maybe, the > > implementation can interoperate with a complicant one) > > Not without a workaround. Well, technically it is compliant with RFC > 4742 but non-compliant with RFC 4741, so that's a bug that needs > fixing. Even 4742 says: [...] which MUST be followed by a element in the 'NETCONF' namespace. I think it is clear that the example in 4742 which doesn't have a namespace is a bug. Chairs: should we file an errata for this? /martin From mehmet.ersue@nsn.com Wed Oct 7 01: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 DB6DC3A684C for ; Wed, 7 Oct 2009 01:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[AWL=-0.669, 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 nziHF6GUDCUV for ; Wed, 7 Oct 2009 01:53:42 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id DEDEC3A67F7 for ; Wed, 7 Oct 2009 01:53:41 -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 n978tIEL016868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Oct 2009 10:55:18 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n978tIl0031377; Wed, 7 Oct 2009 10:55:18 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 10:55:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Oct 2009 10:55:17 +0200 Message-ID: In-Reply-To: <20091007.092335.142865395.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] namespace issue in the sample in RFC474 2 netconf over ssh Thread-Index: AcpHHxzczlOGObAYTGePGhs335kViQADJ6oQ References: <1254765747.450910030@192.168.1.70><309bec650910070013g129abe0eueebbd1fb0949807@mail.gmail.com> <20091007.092335.142865395.mbj@tail-f.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Martin Bjorklund" , X-OriginalArrivalTime: 07 Oct 2009 08:55:18.0407 (UTC) FILETIME=[E4F77970:01CA472B] Cc: netconf@ietf.org Subject: Re: [Netconf] namespace issue in the sample in RFC474 2 netconf over ssh X-BeenThere: netconf@ietf.org X-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, 07 Oct 2009 08:53:42 -0000 > From: netconf-bounces@ietf.org On Behalf Of ext Martin Bjorklund ... > Even 4742 says: >=20 > [...] which MUST be followed by a element in the 'NETCONF' > namespace. >=20 > I think it is clear that the example in 4742 which doesn't have a > namespace is a bug. >=20 > Chairs: should we file an errata for this? Yes, we should. Mehmet From mbj@tail-f.com Wed Oct 7 04:38: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 AC43F28C279 for ; Wed, 7 Oct 2009 04:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_50=0.001, 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 5vaQU-rycKdX for ; Wed, 7 Oct 2009 04:38:41 -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 E469828C270 for ; Wed, 7 Oct 2009 04:38:40 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 3D6E461601E for ; Wed, 7 Oct 2009 13:40:20 +0200 (CEST) Date: Wed, 07 Oct 2009 13:40:19 +0200 (CEST) Message-Id: <20091007.134019.139448851.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund 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: [Netconf] comments on monitoring: format 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: Wed, 07 Oct 2009 11:38:41 -0000 Hi, It seems that some text we originally had in the YANG draft about how YANG modules are listed in the schema list, that was supposed to be moved into the monitoring draft is not there. So I suggest we add the following to 2.1.3: In "identifier (string)" add a paragraph: For YANG data models, the identifier is the name of the module or submodule. In "version (string)" add a paragraph: For YANG data models, version is the value of the most recent YANG "revision" statement in the module or submodule, or the empty string if no revision statement is present. In "format (identifyref, schema-format)" add a paragraph: For YANG data models, the format is one of "yang" or "yin". In "namespace(inet:uri)" add a paragraph: For YANG data models, this is the module's namespace. If the list entry describes a submodule, this field contains the namespace of the module to which the submodule belongs. /martin From xiangli@iwlcorp.com Wed Oct 7 09:50: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 E692C3A6930 for ; Wed, 7 Oct 2009 09:50:55 -0700 (PDT) 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.219, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xZHA7ZG-AVA for ; Wed, 7 Oct 2009 09:50:55 -0700 (PDT) Received: from smtp164.iad.emailsrvr.com (smtp164.iad.emailsrvr.com [207.97.245.164]) by core3.amsl.com (Postfix) with ESMTP id 089203A6884 for ; Wed, 7 Oct 2009 09:50:55 -0700 (PDT) Received: from relay6.relay.iad.emailsrvr.com (localhost [127.0.0.1]) by relay6.relay.iad.emailsrvr.com (SMTP Server) with ESMTP id B3B7783F87E; Wed, 7 Oct 2009 12:52:34 -0400 (EDT) Received: from dynamic1.wm-web.iad.mlsrvr.com (dynamic1.wm-web.iad.mlsrvr.com [192.168.2.150]) by relay6.relay.iad.emailsrvr.com (SMTP Server) with ESMTP id A4F0716CD1A; Wed, 7 Oct 2009 12:52:34 -0400 (EDT) Received: from iwlcorp.com (localhost [127.0.0.1]) by dynamic1.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 9309AC98059; Wed, 7 Oct 2009 12:52:34 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: xiangli@iwlcorp.com, from: xiangli@iwl.com) with HTTP; Wed, 7 Oct 2009 09:52:34 -0700 (PDT) Date: Wed, 7 Oct 2009 09:52:34 -0700 (PDT) From: "Xiang Li" To: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1254934354.59978028@192.168.1.201> X-Mailer: webmail7.0 Cc: netconf@ietf.org Subject: [Netconf] new RFC 4742 errata X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 16:50:56 -0000 Hi,=0A=0APlease add an errata attachment to RFC 4742 for the=0Afollowing bu= g (the netconf namespace is missing in the sample hello message):=0A=0Apage= 4, =0AOLD:=0A=0A S: =0A S: <= hello>=0A=0A ...=0A C: =0A = C: =0A ...=0A=0A=0A=0ANEW:=0A=0A S: =0A S: =0A=0A ...=0A C: =0A C= : =0A ...=0A=0A= =0AThanks,=0AXiang Li From rfc-editor@rfc-editor.org Wed Oct 7 10:08:02 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 9CB4F3A683A for ; Wed, 7 Oct 2009 10:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.904 X-Spam-Level: X-Spam-Status: No, score=-16.904 tagged_above=-999 required=5 tests=[AWL=0.695, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLb6VTmqjOhK for ; Wed, 7 Oct 2009 10:08:01 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id E92493A6827 for ; Wed, 7 Oct 2009 10:08:01 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id BD35833AD08; Wed, 7 Oct 2009 10:08:13 -0700 (PDT) To: xiangli@iwl.com From: rfc-editor@rfc-editor.org Message-Id: <20091007170813.BD35833AD08@bosco.isi.edu> Date: Wed, 7 Oct 2009 10:08:13 -0700 (PDT) Cc: netconf@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [Netconf] new RFC 4742 errata X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 17:08:02 -0000 Greetings, Please submit errata using this page (under "Report New Errata"): http://www.rfc-editor.org/errata.php There are instructions here, although hopefully it's pretty straightforward: http://www.rfc-editor.org/how_to_report.html Please let us know if you have questions. Thank you. RFC Editor/ah On Oct 7, 2009, at 12:52 PM, Xiang Li wrote: > > Hi, > > Please add an errata attachment to RFC 4742 for the > following bug (the netconf namespace is missing in the sample hello message): > > page 4, > OLD: > > S: > S: > > ... > C: > C: > ... > > > > NEW: > > S: > S: > > ... > C: > C: > ... > > > Thanks, > Xiang Li From web-usrn@ISI.EDU Wed Oct 7 10:24: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 A52F43A6916 for ; Wed, 7 Oct 2009 10:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.906 X-Spam-Level: X-Spam-Status: No, score=-16.906 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MEynR-2SXOm for ; Wed, 7 Oct 2009 10:24:16 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id CDBF428C121 for ; Wed, 7 Oct 2009 10:23:58 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n97HME30025048; Wed, 7 Oct 2009 10:22:15 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n97HMBwY025011; Wed, 7 Oct 2009 10:22:11 -0700 (PDT) Date: Wed, 7 Oct 2009 10:22:11 -0700 (PDT) Message-Id: <200910071722.n97HMBwY025011@boreas.isi.edu> To: margaret@thingmagic.com, ted.goddard@icesoft.com, dromasca@avaya.com, rbonica@juniper.net, bertietf@bwijnen.net, mehmet.ersue@nsn.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: netconf@ietf.org, rfc-editor@rfc-editor.org Subject: [Netconf] [Technical Errata Reported] RFC4742 (1903) X-BeenThere: netconf@ietf.org X-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, 07 Oct 2009 17:24:17 -0000 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=4742&eid=1903 -------------------------------------- Type: Technical Reported by: Xiang Li Section: 3.1 Original Text ------------- S: S: S: S: S: urn:ietf:params:xml:ns:netconf:base:1.0 S: S: S: urn:ietf:params:ns:netconf:capability:startup:1.0 S: S: S: 4 S: S: ]]>]]> C: C: C: C: C: urn:ietf:params:xml:ns:netconf:base:1.0 C: C: C: C: ]]>]]> Corrected Text -------------- S: S: S: S: S: urn:ietf:params:xml:ns:netconf:base:1.0 S: S: S: urn:ietf:params:ns:netconf:capability:startup:1.0 S: S: S: 4 S: S: ]]>]]> C: C: C: C: C: urn:ietf:params:xml:ns:netconf:base:1.0 C: C: C: C: ]]>]]> Notes ----- the netconf namespace is missing in the sample hello message (for both client and server hello) 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 From kwatsen@juniper.net Wed Oct 7 12:47: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 50F9428C1E8 for ; Wed, 7 Oct 2009 12:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 S9IbMOzEppFQ for ; Wed, 7 Oct 2009 12:47:49 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 6470528C1E3 for ; Wed, 7 Oct 2009 12:47:49 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSszwwp8cbsagoxmyobu5imTdocvJUvW/@postini.com; Wed, 07 Oct 2009 12:49:30 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Wed, 7 Oct 2009 12:47:58 -0700 From: Kent Watsen To: 'Wes Hardaker' , Andy Bierman Date: Wed, 7 Oct 2009 12:47:49 -0700 Thread-Topic: [Netconf] xml start directive with ssh Thread-Index: Acn48hMYXa4BGopSRSKrOm7i10hgsBOlISrQ Message-ID: <84600D05C20FF943918238042D7670FD3664804754@EMBX01-HQ.jnpr.net> References: <200906251812.OAA17955@adminfs.snmp.com> <200906251817.n5PIHHlI018841@idle.juniper.net> <4A443788.2080904@netconfcentral.com> <4A48FF7E.1070301@netconfcentral.com> In-Reply-To: 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] xml start directive with ssh X-BeenThere: netconf@ietf.org X-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, 07 Oct 2009 19:47:50 -0000 Wes Hardaker wrote: > AB> I think the NETCONF subsystem should only send and receive > AB> XML instance documents. I would be surprised if any implementations > AB> accepted arbitrary garbage text at any time. >=20 > I do agree that it would be a much cleaner service if we stop trying to > do the odd protocol mashing. If a bis is ever done I agree it should be > dropped. I don't see anything from this thread in the bis, should it be added now? Also, is the consensus that the xml start directive MUST proceed an= d MAY proceed , , and ? Thanks, Kent From andy@netconfcentral.com Wed Oct 7 13:08: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 58BF828C214 for ; Wed, 7 Oct 2009 13:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 eyWIRQv9kC85 for ; Wed, 7 Oct 2009 13:08:00 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 8DE6A28C204 for ; Wed, 7 Oct 2009 13:08:00 -0700 (PDT) Received: (qmail 30910 invoked from network); 7 Oct 2009 20:09:38 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.81.206 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 7 Oct 2009 20:09:38 -0000 X-YMail-OSG: UcRZ4UAVM1kvi7hMAvXKblUSIwguzASFN.f4EabdM7cBoeZrXFh3Is2kCUOPpg.lTwZ716xhIlJke4B1S0vCM2tpEAmA9R2jfKPmkQTQmhHkgnPNj2IWdw4xPuImcPHX1YP3MJ9wcg1rlygPuz5SZE7MH7aSHZdkOn3ystBYgzh269p7fkq8ixJz_THqan_HMCyAc3gPtLBheFm5OpUq6PFJ8jI4inscjfambgfVP_pai0DSYF9HcF0PII0sdcbFxuTnXZeBE1EKX4LYnSGRlhJixOmoGrVFUmL.V5nTpw6RcgNaqhhY3YcryRGLfQuI.w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACCF573.4010609@netconfcentral.com> Date: Wed, 07 Oct 2009 13:09:23 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Kent Watsen References: <200906251812.OAA17955@adminfs.snmp.com> <200906251817.n5PIHHlI018841@idle.juniper.net> <4A443788.2080904@netconfcentral.com> <4A48FF7E.1070301@netconfcentral.com> <84600D05C20FF943918238042D7670FD3664804754@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3664804754@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Wes Hardaker' , "netconf@ietf.org" Subject: Re: [Netconf] xml start directive with ssh X-BeenThere: netconf@ietf.org X-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, 07 Oct 2009 20:08:01 -0000 Kent Watsen wrote: > > Wes Hardaker wrote: >> AB> I think the NETCONF subsystem should only send and receive >> AB> XML instance documents. I would be surprised if any implementations >> AB> accepted arbitrary garbage text at any time. >> This falls into the category of insane stuff nobody is going to bother with, except somebody writing a test to see if every little nit that can be wrung out of the spec is followed. Interoperability is achieved through common need. The more complicated and less common the standard is, the lower the interoperability will be. >> I do agree that it would be a much cleaner service if we stop trying to >> do the odd protocol mashing. If a bis is ever done I agree it should be >> dropped. > > I don't see anything from this thread in the bis, should it be added now? > > Also, is the consensus that the xml start directive MUST proceed and MAY proceed , , and ? > good catch -- probably a bug. It makes no sense to deviate from XML 1.0 anywhere in the NETCONF protocol. The XMLDecl in the prolog is optional, so NETCONF is wrong. > Thanks, > Kent > > Andy From mbj@tail-f.com Wed Oct 7 13:14: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 DDB133A67FB for ; Wed, 7 Oct 2009 13:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.761 X-Spam-Level: X-Spam-Status: No, score=-0.761 tagged_above=-999 required=5 tests=[AWL=-1.129, BAYES_40=-0.185, 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 94rZIbfZEwyX for ; Wed, 7 Oct 2009 13:14:15 -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 BA2FC3A6951 for ; Wed, 7 Oct 2009 13:14:07 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 0685361601C; Wed, 7 Oct 2009 22:15:47 +0200 (CEST) Date: Wed, 07 Oct 2009 22:15:46 +0200 (CEST) Message-Id: <20091007.221546.82521305.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4ACCF573.4010609@netconfcentral.com> References: <84600D05C20FF943918238042D7670FD3664804754@EMBX01-HQ.jnpr.net> <4ACCF573.4010609@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: wes@hardakers.net, netconf@ietf.org Subject: Re: [Netconf] xml start directive with ssh X-BeenThere: netconf@ietf.org X-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, 07 Oct 2009 20:14:16 -0000 Andy Bierman wrote: > Kent Watsen wrote: > > > > Wes Hardaker wrote: > >> I do agree that it would be a much cleaner service if we stop trying to > >> do the odd protocol mashing. If a bis is ever done I agree it should be > >> dropped. > > > > I don't see anything from this thread in the bis, should it be added now? This would be 4742bis, which we're not doing now. > > Also, is the consensus that the xml start directive MUST proceed and > > MAY proceed , , and ? > > > > good catch -- probably a bug. Hmm... where? > It makes no sense to deviate from XML 1.0 > anywhere in the NETCONF protocol. The XMLDecl > in the prolog is optional, so NETCONF is wrong. We added the current clarification to 4741bis-01, section 3: A NETCONF message MAY begin with an XML declaration (see section 2.8 of [1]). which is consistent with XML. /martin From kwatsen@juniper.net Wed Oct 7 14:10: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 238CA3A68D6 for ; Wed, 7 Oct 2009 14:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 WLA+RaShjgid for ; Wed, 7 Oct 2009 14:10:48 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 548B33A67A8 for ; Wed, 7 Oct 2009 14:10:48 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSs0EOAQNtQkVaXb3ZX3ndLn5WZ+1mzpB@postini.com; Wed, 07 Oct 2009 14:12:29 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 7 Oct 2009 14:09:17 -0700 From: Kent Watsen To: 'Martin Bjorklund' , "andy@netconfcentral.com" Date: Wed, 7 Oct 2009 14:09:16 -0700 Thread-Topic: [Netconf] xml start directive with ssh Thread-Index: AcpHivZcqy7qKaegROiz7znV52O5RwABt+QQ Message-ID: <84600D05C20FF943918238042D7670FD36646BFB41@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3664804754@EMBX01-HQ.jnpr.net> <4ACCF573.4010609@netconfcentral.com> <20091007.221546.82521305.mbj@tail-f.com> In-Reply-To: <20091007.221546.82521305.mbj@tail-f.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: "wes@hardakers.net" , "netconf@ietf.org" Subject: Re: [Netconf] xml start directive with ssh X-BeenThere: netconf@ietf.org X-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, 07 Oct 2009 21:10:54 -0000 > We added the current clarification to 4741bis-01, section 3: >=20 > A NETCONF message MAY begin with an XML declaration (see section 2.8 > of [1]). >=20 > which is consistent with XML. Thanks! So, even though there isn't a 4742bis, is it correct to assume tha= t 4742's statement in section 3 regarding the XML declaration MUST precede = the element is an error? Thanks, Kent From xiangli@iwlcorp.com Wed Oct 7 14:25: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 B59F03A67A8 for ; Wed, 7 Oct 2009 14:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=1.402, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnmSPfOsdCWe for ; Wed, 7 Oct 2009 14:25:46 -0700 (PDT) Received: from smtp144.iad.emailsrvr.com (smtp144.iad.emailsrvr.com [207.97.245.144]) by core3.amsl.com (Postfix) with ESMTP id DC1EA3A697B for ; Wed, 7 Oct 2009 14:25:45 -0700 (PDT) Received: from relay24.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay24.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 196C41B4107; Wed, 7 Oct 2009 17:27:26 -0400 (EDT) Received: from dynamic3.wm-web.iad.mlsrvr.com (dynamic3.wm-web.iad.mlsrvr.com [192.168.2.152]) by relay24.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 137801B40CD; Wed, 7 Oct 2009 17:27:25 -0400 (EDT) Received: from iwlcorp.com (localhost [127.0.0.1]) by dynamic3.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id D4CE72110001; Wed, 7 Oct 2009 17:27:25 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: xiangli@iwlcorp.com, from: xiangli@iwl.com) with HTTP; Wed, 7 Oct 2009 14:27:25 -0700 (PDT) Date: Wed, 7 Oct 2009 14:27:25 -0700 (PDT) From: "Xiang Li" To: "Kent Watsen" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: <84600D05C20FF943918238042D7670FD36646BFB41@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3664804754@EMBX01-HQ.jnpr.net> <4ACCF573.4010609@netconfcentral.com> <20091007.221546.82521305.mbj@tail-f.com> <84600D05C20FF943918238042D7670FD36646BFB41@EMBX01-HQ.jnpr.net> Message-ID: <1254950845.86938564@192.168.1.71> X-Mailer: webmail7.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] xml start directive with ssh X-BeenThere: netconf@ietf.org X-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, 07 Oct 2009 21:25:46 -0000 Looks to me it is a bug in RFC4742.=0A=0AXiang=0A=0A"Kent Watsen" said:=0A=0A> =0A>> We added the current clarification to 4741b= is-01, section 3:=0A>>=0A>> A NETCONF message MAY begin with an XML decl= aration (see section 2.8=0A>> of [1]).=0A>>=0A>> which is consistent wit= h XML.=0A> =0A> =0A> Thanks! So, even though there isn't a 4742bis, is it = correct to assume that=0A> 4742's statement in section 3 regarding the XML = declaration MUST precede the=0A> element is an error?=0A> =0A> Than= ks,=0A> Kent=0A> =0A> =0A> =0A> =0A> ______________________________________= _________=0A> Netconf mailing list=0A> Netconf@ietf.org=0A> https://www.iet= f.org/mailman/listinfo/netconf=0A> =0A From wjhns1@hardakers.net Fri Oct 9 09:11: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 5D5DB3A6953 for ; Fri, 9 Oct 2009 09:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJGxbJyKsS4M for ; Fri, 9 Oct 2009 09:10:59 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 9639E28C12E for ; Fri, 9 Oct 2009 09:10:59 -0700 (PDT) Received: from localhost (unknown [166.129.25.218]) by mail.hardakers.net (Postfix) with ESMTPSA id B149F981EF; Fri, 9 Oct 2009 09:12:42 -0700 (PDT) From: Wes Hardaker To: "Xiang Li" Organization: Sparta References: <84600D05C20FF943918238042D7670FD3664804754@EMBX01-HQ.jnpr.net> <4ACCF573.4010609@netconfcentral.com> <20091007.221546.82521305.mbj@tail-f.com> <84600D05C20FF943918238042D7670FD36646BFB41@EMBX01-HQ.jnpr.net> <1254950845.86938564@192.168.1.71> Date: Fri, 09 Oct 2009 09:12:37 -0700 In-Reply-To: <1254950845.86938564@192.168.1.71> (Xiang Li's message of "Wed, 7 Oct 2009 14:27:25 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netconf@ietf.org" Subject: Re: [Netconf] xml start directive with ssh X-BeenThere: netconf@ietf.org X-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, 09 Oct 2009 16:11:32 -0000 >>>>> On Wed, 7 Oct 2009 14:27:25 -0700 (PDT), "Xiang Li" said: XL> Looks to me it is a bug in RFC4742. That's correct; it's not in the netconf protocol. It's an SSH specific transport issue. -- Wes Hardaker Cobham Analytic Solutions From mrw@lilacglade.org Mon Oct 12 10:20: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 737A528C24F for ; Mon, 12 Oct 2009 10:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1-b9M3+MW3R for ; Mon, 12 Oct 2009 10:20:09 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 0A0D53A68C9 for ; Mon, 12 Oct 2009 10:20:08 -0700 (PDT) Received: from [10.36.0.42] (pool-173-48-144-147.bstnma.fios.verizon.net [173.48.144.147]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n9CHJY51057101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Oct 2009 13:19:36 -0400 (EDT) (envelope-from mrw@lilacglade.org) From: Margaret Wasserman To: "Bert Wijnen \(IETF\)" In-Reply-To: X-Priority: 3 References: Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 13:19:35 -0400 X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Tue, 13 Oct 2009 00:09:53 -0700 Cc: Margaret Wasserman , Ronald Bonica , netconf@ietf.org, Rfc Editor Editor Subject: Re: [Netconf] [Technical Errata Reported] RFC4742 (1903) X-BeenThere: netconf@ietf.org X-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, 12 Oct 2009 17:20:10 -0000 Hi Bert, My ThingMagic e-mail address is no longer valid, please use mrw@lilacglade.org . I have reviewed the errata, and I think that the report is correct; the namespace is missing from the example and should be added. Margaret On Oct 11, 2009, at 4:05 PM, Bert Wijnen (IETF) wrote: > Hi Margaret, > does your email at thingmagic still work? > Do you ever look at it? > Anyway at that email address there is an email about an errata rport > for RFc4742. > Would be good if you could take a look and respond. > > Thanks, Bert > > ----- Original Message ----- > From: RFC Errata System > To: margaret@thingmagic.com ; ted.goddard@icesoft.com ; dromasca@avaya.com > ; rbonica@juniper.net ; bertietf@bwijnen.net ;mehmet.ersue@nsn.com > Cc: xiangli@iwl.com ; netconf@ietf.org ; rfc-editor@rfc-editor.org > Sent: Wednesday, October 07, 2009 7:22 PM > Subject: [Technical Errata Reported] RFC4742 (1903) > > > 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=4742&eid=1903 > > -------------------------------------- > Type: Technical > Reported by: Xiang Li > > Section: 3.1 > > Original Text > ------------- > S: > S: > S: > S: > S: urn:ietf:params:xml:ns:netconf:base:1.0 > S: > S: > S: urn:ietf:params:ns:netconf:capability:startup:1.0 > S: > S: > S: 4 > S: > S: ]]>]]> > > C: > C: > C: > C: > C: urn:ietf:params:xml:ns:netconf:base:1.0 > C: > C: > C: > C: ]]>]]> > > > Corrected Text > -------------- > S: > S: > S: > S: > S: urn:ietf:params:xml:ns:netconf:base:1.0 > S: > S: > S: urn:ietf:params:ns:netconf:capability:startup:1.0 > S: > S: > S: 4 > S: > S: ]]>]]> > > C: > C: > C: > C: > C: urn:ietf:params:xml:ns:netconf:base:1.0 > C: > C: > C: > C: ]]>]]> > > > Notes > ----- > the netconf namespace is missing in the sample hello message (for > both client and server hello) > > 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 > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.421 / Virus Database: 270.14.8/2425 - Release Date: > 10/09/09 08:10:00 From bertietf@bwijnen.net Tue Oct 13 01:19: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 CD97B3A6926 for ; Tue, 13 Oct 2009 01:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVYWC7B8Q05b for ; Tue, 13 Oct 2009 01:19:50 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id C837D3A68F0 for ; Tue, 13 Oct 2009 01:19:49 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1Mxcbd-0002cJ-LU; Tue, 13 Oct 2009 10:19:47 +0200 Received: from guest-24.ripe.net (cat.ripe.net [193.0.1.249]) by herring.ripe.net (Postfix) with ESMTP id 97D5A2F583; Tue, 13 Oct 2009 10:19:41 +0200 (CEST) Message-ID: <4AD4381D.7030809@bwijnen.net> Date: Tue, 13 Oct 2009 10:19:41 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Netconf References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4a6a0ec3f85d37afbac6204d8f8fb5ed1 Cc: Margaret Wasserman Subject: [Netconf] WG consensus call: Technical Errata Reported RFC4742 X-BeenThere: netconf@ietf.org X-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, 13 Oct 2009 08:19:54 -0000 NETCONF WG participants, Pls check the below and speak up if you do not agree or see any problems in approving this errata report. If we hear no objections/concerns by 28 October 2009, we assume WG consensus and we'll ask our AD to approve the errata report as valid. Bert and Mehmet Margaret Wasserman wrote: > > I have reviewed the errata, and I think that the report is correct; > the namespace is missing from the example and should be added. > > Margaret > > >> ----- Original Message ----- >> From: RFC Errata System >> To: margaret@thingmagic.com ; ted.goddard@icesoft.com ; >> dromasca@avaya.com ; rbonica@juniper.net ; bertietf@bwijnen.net >> ;mehmet.ersue@nsn.com >> Cc: xiangli@iwl.com ; netconf@ietf.org ; rfc-editor@rfc-editor.org >> Sent: Wednesday, October 07, 2009 7:22 PM >> Subject: [Technical Errata Reported] RFC4742 (1903) >> >> >> 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=4742&eid=1903 >> >> -------------------------------------- >> Type: Technical >> Reported by: Xiang Li >> >> Section: 3.1 >> >> Original Text >> ------------- >> S: >> S: >> S: >> S: >> S: urn:ietf:params:xml:ns:netconf:base:1.0 >> S: >> S: >> S: urn:ietf:params:ns:netconf:capability:startup:1.0 >> S: >> S: >> S: 4 >> S: >> S: ]]>]]> >> >> C: >> C: >> C: >> C: >> C: urn:ietf:params:xml:ns:netconf:base:1.0 >> C: >> C: >> C: >> C: ]]>]]> >> >> >> Corrected Text >> -------------- >> S: >> S: >> S: >> S: >> S: urn:ietf:params:xml:ns:netconf:base:1.0 >> S: >> S: >> S: urn:ietf:params:ns:netconf:capability:startup:1.0 >> S: >> S: >> S: 4 >> S: >> S: ]]>]]> >> >> C: >> C: >> C: >> C: >> C: urn:ietf:params:xml:ns:netconf:base:1.0 >> C: >> C: >> C: >> C: ]]>]]> >> >> >> Notes >> ----- >> the netconf namespace is missing in the sample hello message (for >> both client and server hello) >> >> 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 From root@core3.amsl.com Wed Oct 14 10:30:02 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 27D993A6A1C; Wed, 14 Oct 2009 10:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091014173002.27D993A6A1C@core3.amsl.com> Date: Wed, 14 Oct 2009 10:30:02 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-09.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, 14 Oct 2009 17:30:02 -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, M. Bjorklund Filename : draft-ietf-netconf-monitoring-09.txt Pages : 30 Date : 2009-10-14 This document defines a NETCONF data model to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF datastores, sessions, locks 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-09.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-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-14102147.I-D@ietf.org> --NextPart-- From MARKSCOT@nortel.com Wed Oct 14 10:47: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 D8FC83A69C0 for ; Wed, 14 Oct 2009 10:47:20 -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 JSVJgsYsO-oQ for ; Wed, 14 Oct 2009 10:47:20 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id BD78E3A67AB for ; Wed, 14 Oct 2009 10:47:19 -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 n9EHlHq23351 for ; Wed, 14 Oct 2009 17:47:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Wed, 14 Oct 2009 13:47:09 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D1A9F69CD@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-netconf-monitoring-09 Thread-Index: AcpM8tHJxxCBJN7QSL2T+SkMdEFmTwAABoPA From: "Mark Scott" To: Subject: [Netconf] FW: New Version Notification for draft-ietf-netconf-monitoring-09 X-BeenThere: netconf@ietf.org X-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, 14 Oct 2009 17:47:20 -0000 SGVsbG8sDQoNCkEgbmV3IHZlcnNpb24gKHY5KSBvZiB0aGUgTkVUQ09ORiBNb25pdG9yaW5nIFNj aGVtYSBkcmFmdCBoYXMgYmVlbiBwb3N0ZWQuDQoNClRoaXMgdmVyc2lvbiBhZGRyZXNzZXMgbWFp bGluZyBsaXN0IGNvbW1lbnRzIHJlY2VpdmVkIG9uIHY4Og0KLSByZXZlcnNpb24gb2YgJ3Nlc3Np b24tdHlwZScgdG8gJ3RyYW5zcG9ydCcNCi0gZWxlbWVudCBuYW1pbmcgY29uc2lzdGVuY3kuICBB bGwgbG93ZXJDYW1lbENhc2UgbmFtZXMgaGF2ZSBiZWVuIGNvbnZlcnRlZCB0byAnaHlwaGVuLWRl bGltaXRlZCcgb3IgJ25ldGNvbmYtc3R5bGUtbmFtaW5nJyBhcyBpdCBpcyBzb21ldGltZXMgcmVm ZXJyZWQgdG8gb24gdGhlIE1MLiAgRS5nLiAgJ3Nlc3Npb25UeXBlJyAtPiAnc2Vzc2lvbi10eXBl Jy4gIFRoaXMgY2hhbmdlIGltcGFjdHMgYm90aCB0aGUgZHJhZnQgdGV4dCBhbmQgeWFuZyBtb2R1 bGUuICANCi0gPGdldC1zY2hlbWE+IG9wZXJhdGlvbiB1cGRhdGVkOg0KCS0gbm93IGhhcyBvbmx5 IG9uZSBtYW5kYXRvcnkgcGFyYW1ldGVyLCAnaWRlbnRpZmllcicNCgktIHVwZGF0ZWQgbmVnYXRp dmUgcmVzcG9uc2VzLCBpbmNsdWRpbmcgdGhlIHJwYyBvcGVyYXRpb24gZGVzY3JpcHRpb24gaW4g eWFuZyBtb2R1bGUNCi0gY29tbWVudHMgYWRkZWQgdG8gdGhlIHlhbmcgbW9kdWxlIGluZGljYXRp bmcgdGhhdCB0aGUgZGVmaW5pdGlvbiBvZiAnc2Vzc2lvbi1pZCcgaXMgY29uc2lzdGVudCB3aXRo IDQ3NDFiaXMgJ3Nlc3Npb24taWQtdHlwZScgYW5kIGNvdWxkIGJlIGltcG9ydGVkIGZyb20gdGhh dCBwZW5kaW5nIFJGQy4gIFNpbWlsYXIgZm9yICduZXRjb25mLWRhdGFzdG9yZS10eXBlJy4gIFRo aXMgd2FzIGluIGZhdm91ciBvZiBhZGRpbmcgZnVydGhlciBkZXBlbmRlbmNpZXMgYW5kIGRlbGF5 cyBieSB3YWl0aW5nIGZvciA0NzQxYmlzIHRvIGNvbXBsZXRlLg0KIA0KUGxlYXNlIGRpcmVjdCBh bnkgY29tbWVudHMgb24gdGhpcyB2ZXJzaW9uIHRvIHRoZSBtYWlsaW5nIGxpc3QuDQoNCmNoZWVy cywNCk1hcmsNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSUVURiBJLUQg U3VibWlzc2lvbiBUb29sIFttYWlsdG86aWRzdWJtaXNzaW9uQGlldGYub3JnXSANClNlbnQ6IFdl ZG5lc2RheSwgT2N0b2JlciAxNCwgMjAwOSAxOjIyIFBNDQpUbzogU2NvdHQsIE1hcmsgKENBUjoy TjAwKQ0KQ2M6IG1iakB0YWlsLWYuY29tDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWlldGYtbmV0Y29uZi1tb25pdG9yaW5nLTA5IA0KDQoNCkEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1pZXRmLW5ldGNvbmYtbW9uaXRvcmluZy0wOS50eHQgaGFzIGJlZW4g c3VjY2Vzc2Z1bHkgc3VibWl0dGVkIGJ5IE1hcmsgU2NvdHQgYW5kIHBvc3RlZCB0byB0aGUgSUVU RiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWlldGYtbmV0Y29uZi1tb25pdG9yaW5n DQpSZXZpc2lvbjoJIDA5DQpUaXRsZToJCSBORVRDT05GIE1vbml0b3JpbmcgU2NoZW1hDQpDcmVh dGlvbl9kYXRlOgkgMjAwOS0xMC0xNA0KV0cgSUQ6CQkgbmV0Y29uZg0KTnVtYmVyX29mX3BhZ2Vz OiAzMA0KDQpBYnN0cmFjdDoNClRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIE5FVENPTkYgZGF0YSBt b2RlbCB0byBiZSB1c2VkIHRvIG1vbml0b3IgdGhlDQpORVRDT05GIHByb3RvY29sLiAgVGhlIG1v bml0b3JpbmcgZGF0YSBtb2RlbCBpbmNsdWRlcyBpbmZvcm1hdGlvbg0KYWJvdXQgTkVUQ09ORiBk YXRhc3RvcmVzLCBzZXNzaW9ucywgbG9ja3MgYW5kIHN0YXRpc3RpY3MuICBUaGlzIGRhdGENCmZh Y2lsaXRhdGVzIHRoZSBtYW5hZ2VtZW50IG9mIGEgTkVUQ09ORiBzZXJ2ZXIuICBUaGlzIGRvY3Vt ZW50IGFsc28NCmRlZmluZXMgbWV0aG9kcyBmb3IgTkVUQ09ORiBjbGllbnRzIHRvIGRpc2NvdmVy IGRhdGEgbW9kZWxzIHN1cHBvcnRlZA0KYnkgYSBORVRDT05GIHNlcnZlciBhbmQgZGVmaW5lcyBh IG5ldyBORVRDT05GIDxnZXQtc2NoZW1hPiBvcGVyYXRpb24NCnRvIHJldHJpZXZlIHRoZW0uDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQuDQoNCg0K From balazs.lengyel@ericsson.com Mon Oct 19 03:56: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 085D03A67D2; Mon, 19 Oct 2009 03:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWxSbOWQfnuq; Mon, 19 Oct 2009 03:56:35 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id ADBAE3A67E6; Mon, 19 Oct 2009 03:56:34 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-9d-4adc45e8b7b0 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id A6.14.24026.8E54CDA4; Mon, 19 Oct 2009 12:56:40 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 12:55:48 +0200 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 12:55:46 +0200 Message-ID: <4ADC45B2.1070201@ericsson.com> Date: Mon, 19 Oct 2009 12:55:46 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: rdroms@cisco.com, netconf-chairs@tools.ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Oct 2009 10:55:47.0007 (UTC) FILETIME=[B6814CF0:01CA50AA] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list , iesg@ietf.org Subject: [Netconf] Netconf-partial-lock comment/discuss X-BeenThere: netconf@ietf.org X-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, 19 Oct 2009 10:56:36 -0000 Hello Ralph, In the tracker https://datatracker.ietf.org/idtracker/ballot/3035 about the draft-ietf-netconf-partial-lock-09 you have the comment: "Comment [2009-08-08]: 2.4.2. Positive Response: If the device was able to satisfy the request, an is sent that contains an element. A positive response MUST be sent even if all of the locked parts of the datastore(s) have already been deleted. Negative Response: If the parameter does not identify a lock which is owned by the session, an ’invalid-value’ error is returned. Are there other ways in which the can fail?" ANSWER: No other way, besides generic faults like access control, XML parser errors that are covered by RFC4741. Can you accept this answer? Do you have other specific failure mode in mind? regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From root@core3.amsl.com Mon Oct 19 04:00: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 9721728C164; Mon, 19 Oct 2009 04:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091019110001.9721728C164@core3.amsl.com> Date: Mon, 19 Oct 2009 04:00:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-partial-lock-10.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, 19 Oct 2009 11:00: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 : Partial Lock RPC for NETCONF Author(s) : B. Lengyel, M. Bjorklund Filename : draft-ietf-netconf-partial-lock-10.txt Pages : 28 Date : 2009-10-19 The NETCONF protocol defines the lock and unlock RPCs, used to lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-partial-lock-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-partial-lock-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-19035814.I-D@ietf.org> --NextPart-- From bertietf@bwijnen.net Mon Oct 19 04:40:27 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 6FD823A67D4 for ; Mon, 19 Oct 2009 04:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bv9s0M6riHbg for ; Mon, 19 Oct 2009 04:40:26 -0700 (PDT) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 478583A67A8 for ; Mon, 19 Oct 2009 04:40:26 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MzqbA-000789-HF for netconf@ietf.org; Mon, 19 Oct 2009 13:40:30 +0200 Received: from guest-24.ripe.net (dog.ripe.net [193.0.1.217]) by herring.ripe.net (Postfix) with ESMTP id 7CCC42F593 for ; Mon, 19 Oct 2009 13:40:24 +0200 (CEST) Message-ID: <4ADC5028.8050301@bwijnen.net> Date: Mon, 19 Oct 2009 13:40:24 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Netconf References: <20091019110001.9CFEE28C168@core3.amsl.com> In-Reply-To: <20091019110001.9CFEE28C168@core3.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd46f1ca8469c4daa87324897d094350202 Subject: [Netconf] WG: Pls check ASAP: draft-ietf-netconf-partial-lock-10.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, 19 Oct 2009 11:40:27 -0000 NETCONF WG participants, First thanks to Balazs for the new (hopefully latest) revision. This revision is supposed to address all IESG DISCUSS comments. I have asked Balazs to send responses to the DISCUSSing ADs and explicitly ask them if their DISCUSS can be cleared for this new revision. Balazs will send a copy of those reponses to the WG list. So pls pay attention and react ASAP (this week if at all possible) if you see any issues in the responses or the new revision. If this new rev indeed clears the DISCUSSes, then I will ask our AD to move the document into the RFC-Editor queue. Bert Wijnen document shepherd Internet-Draft@ietf.org wrote: > New version (-10) has been submitted for draft-ietf-netconf-partial-lock-10.txt. > http://www.ietf.org/internet-drafts/draft-ietf-netconf-partial-lock-10.txt > Sub state has been changed to AD Follow up from New Id Needed > > Diff from previous version: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-partial-lock-10 > > IETF Secretariat. > > > From balazs.lengyel@ericsson.com Mon Oct 19 04:56: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 CE4A63A67E6; Mon, 19 Oct 2009 04:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kvKBkKe6Md0; Mon, 19 Oct 2009 04:56:46 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 99EC13A67C0; Mon, 19 Oct 2009 04:56:45 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-53-4adc54032007 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id BD.19.24026.3045CDA4; Mon, 19 Oct 2009 13:56:51 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 13:56:24 +0200 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 13:56:24 +0200 Message-ID: <4ADC53E7.6080204@ericsson.com> Date: Mon, 19 Oct 2009 13:56:23 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: netconf-chairs@tools.ietf.org, pasi.eronen@nokia.com Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2009 11:56:24.0728 (UTC) FILETIME=[2EC17980:01CA50B3] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list , iesg@ietf.org Subject: [Netconf] Netconf-partial-lock comment/discuss X-BeenThere: netconf@ietf.org X-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, 19 Oct 2009 11:56:46 -0000 Hello Pasi, In the tracker https://datatracker.ietf.org/idtracker/ballot/3035 about the draft-ietf-netconf-partial-lock-09 you have the comment: "Discuss [2009-08-10]: I have reviewed draft-ietf-netconf-partial-lock-09, and have one question/concern that I'd like to discuss before recommending approval of the document: I'm having trouble getting the following XML snippets through a validator: the rpc-reply example in Section 2.4.1.1, step 4 in Appendix C, and step 7 in Appendix C. I'm not sure if this is a problem in the examples, the schema, or my validation setup, though... " ANSWER: The element is intentionally missing as the RFC4741 XSD is faulty. This is now mentioned explicitly in the draft: Note: The XML Schema in [NETCONF] has a known bug which requires the XML element in a . This means that the above examples will not validate using the XML Schema found in [NETCONF]. Please indicate if you can this answer? regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From Pasi.Eronen@nokia.com Mon Oct 19 05:03: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 BA7913A67D4; Mon, 19 Oct 2009 05:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 uuBTLNdnDBGe; Mon, 19 Oct 2009 05:03:12 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 8AA233A659C; Mon, 19 Oct 2009 05:03:11 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9JC30u6019072; Mon, 19 Oct 2009 15:03:14 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 15:03:12 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 15:02:56 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 19 Oct 2009 14:02:53 +0200 From: To: , Date: Mon, 19 Oct 2009 14:02:49 +0200 Thread-Topic: Netconf-partial-lock comment/discuss Thread-Index: AcpQs0b7k2awVjDFTL6i8Fkw5Zs8aAAAL3MA Message-ID: <808FD6E27AD4884E94820BC333B2DB773C09A9015E@NOK-EUMSG-01.mgdnok.nokia.com> References: <4ADC53E7.6080204@ericsson.com> In-Reply-To: <4ADC53E7.6080204@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 X-OriginalArrivalTime: 19 Oct 2009 12:02:56.0594 (UTC) FILETIME=[18537B20:01CA50B4] X-Nokia-AV: Clean X-Mailman-Approved-At: Mon, 19 Oct 2009 05:04:53 -0700 Cc: netconf@ietf.org, iesg@ietf.org Subject: Re: [Netconf] Netconf-partial-lock comment/discuss X-BeenThere: netconf@ietf.org X-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, 19 Oct 2009 12:03:12 -0000 Hi Balazs, The next text looks OK, and I've cleared my DISCUSS. Best regards, Pasi > -----Original Message----- > From: ext Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > Sent: 19 October, 2009 14:56 > To: netconf-chairs@tools.ietf.org; Eronen Pasi (Nokia-NRC/Helsinki) > Cc: netconf mailing list; iesg@ietf.org > Subject: Netconf-partial-lock comment/discuss >=20 > Hello Pasi, > In the tracker https://datatracker.ietf.org/idtracker/ballot/3035 about > the > draft-ietf-netconf-partial-lock-09 you have the comment: >=20 > "Discuss [2009-08-10]: > I have reviewed draft-ietf-netconf-partial-lock-09, and have > one question/concern that I'd like to discuss before recommending > approval of the document: >=20 > I'm having trouble getting the following XML snippets through a > validator: the rpc-reply example in Section 2.4.1.1, step 4 in > Appendix C, and step 7 in Appendix C. I'm not sure if this is > a problem in the examples, the schema, or my validation setup, > though... > " >=20 > ANSWER: The element is intentionally missing as the RFC4741 XSD > is faulty. This is now > mentioned explicitly in the draft: >=20 > Note: The XML Schema in [NETCONF] has a known bug which requires the > XML element in a . This means that the above > examples will not validate using the XML Schema found in [NETCONF]. >=20 >=20 > Please indicate if you can this answer? >=20 > regards Balazs >=20 >=20 > -- > Balazs Lengyel Ericsson Hungary Ltd. > 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 Oct 19 05:25: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 A13DE28C138; Mon, 19 Oct 2009 05:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSPpIru6YvSI; Mon, 19 Oct 2009 05:25:50 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 328C53A69A0; Mon, 19 Oct 2009 05:25:50 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-e7-4adc5ad2fe17 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id CD.6B.08816.2DA5CDA4; Mon, 19 Oct 2009 14:25:55 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 14:25:54 +0200 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 14:25:54 +0200 Message-ID: <4ADC5AD1.2020402@ericsson.com> Date: Mon, 19 Oct 2009 14:25:53 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: netconf-chairs@tools.ietf.org, Adrian Farrel Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2009 12:25:54.0176 (UTC) FILETIME=[4D6DD000:01CA50B7] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list , iesg@ietf.org Subject: [Netconf] Netconf-partial-lock comment/discuss X-BeenThere: netconf@ietf.org X-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, 19 Oct 2009 12:25:51 -0000 Hello , In the tracker https://datatracker.ietf.org/idtracker/ballot/3035 about the draft-ietf-netconf-partial-lock-09 you have the comment: I'm sure security has been extensively debated in the context of RFC 4741 and I don't want to rehash any debates. I wondered whether (2.4.1.1)... Negative Response: If a lock is already held by another session on any node within the subtrees to be locked, the element is 'lock-denied' and the element includes the of the lock owner. ...was potentially giving out more information than necesary/desirbale. Probably you need to state that the filter (2.4.1.1)... If access control denies the partial lock, the is 'access-denied'. ...and (3.)... Only an authenticated and authorized user can request a partial lock. ...SHOULD be evaluated first. Otherwise, an unauthrised user can easily determine the identities of the authorised users. In 2.4.1.1 this will need reordering of the text as well as the "SHOULD" statement. ----- ANSWER: OK, updated, access control will be checked first, however anyway only the sessionId would be available not the user name, so the security risk is minimal. From the stored new -10 version: "Access control SHOULD be checked before checking for conflicting locks to avoid giving out information about other sessions to an unauthorized client." ----- It also seemed to me that (3.) ... A lock that is hung for some reason (e.g., a broken TCP connection that the server has not yet recognised) can be released using another NETCONF session by explicitly killing the session owning that lock using the operation. ...seemed quite an amusing attack. But I presume that the session issuing the is suitably qualified. ----- ANSWER: This is part of RFC4741. Nothing about is new in this draft. Yes authorization and authentication should prevent such an attack. ----- === 2.4.2. The operation unlocks the parts of the datastores that were previously locked using during the same session. This is not true in the case of overlapping partial locks as previously described. Just need to tweak the text a little. Comment [2009-08-13]: ---- ANSWER: OK, added:"In case of multiple potentially overlapping locks, only the lock identified by the lock-id is removed." ----- Please indicate if you can accept these answers! regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. 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 Oct 19 05:34: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 3005028C134; Mon, 19 Oct 2009 05:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPhzMrnnNhrG; Mon, 19 Oct 2009 05:34:10 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C66183A6887; Mon, 19 Oct 2009 05:34:09 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-2d-4adc5cc78382 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id DC.3C.24026.7CC5CDA4; Mon, 19 Oct 2009 14:34:15 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 14:34:14 +0200 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 14:34:14 +0200 Message-ID: <4ADC5CC5.2030003@ericsson.com> Date: Mon, 19 Oct 2009 14:34:13 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: netconf-chairs@tools.ietf.org, alexey.melnikov@isode.com Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2009 12:34:14.0739 (UTC) FILETIME=[77C9AA30:01CA50B8] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list , iesg@ietf.org Subject: [Netconf] Netconf-partial-lock comment/discuss X-BeenThere: netconf@ietf.org X-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, 19 Oct 2009 12:34:11 -0000 Hello , In the tracker https://datatracker.ietf.org/idtracker/ballot/3035 about the draft-ietf-netconf-partial-lock-09 you have the comment: Discuss [2009-08-10]: Overall this is a well written document. I have one blocking comment though: In Section 2.1: The operation returns a lock-id to identify each successfully acquired lock. The lock-id is unique for a NETCONF server for all partial-locks granted to any NETCONF or non-NETCONF sessions. Can a ever be reused after a session terminates? ----- ANSWER: Yes lock-id values can be reused once the lock is removed. The node only needs to guarantee that lock-ids IN-USE at a specific time are not reused. There is no other risk involved as: - the lock-id is a 32 bit integer, it has a big enough value space - the lock-id can only be used in the same session where it was granted, so there is no risk of another session misusing it ----- Comment [2009-08-10]: 2.4.1. The operation allows the client to lock a portion of one or more datastores. The portion to lock is specified with XPath expressions in the "select" elements and the list of datastores in the "target" elements in the operation. Each XPath expression MUST return a node set. What should happen when the XPath expression returns no nodes? ---- ANSWER: As indicated in the text "If all the select expressions return an empty node set, the is 'operation-failed', and the is 'no-matches'." ----- If a node in the scope of the lock is deleted, it is removed from the scope of the lock, so any other session or non-NETCONF mechanism can recreate it. Can you elaborate on how a node covered by a partial lock can be deleted? ---- ANSWER: The owner of the lock can delete such nodes. Clarified in the text of the already stored -10 draft. "If a node in the scope of the lock is deleted by the session owning the lock, it is removed from the scope of the lock, so any other session or non-NETCONF mechanism can recreate it." ---- Please indicate if you can accept these answers! regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. 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 Oct 19 05:45: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 EA57328C1AC; Mon, 19 Oct 2009 05:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYs+KNWwkGlK; Mon, 19 Oct 2009 05:45:45 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 21B103A67E4; Mon, 19 Oct 2009 05:45:41 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-34-4adc5f7b178f Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 4E.EC.08816.B7F5CDA4; Mon, 19 Oct 2009 14:45:48 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 14:45:47 +0200 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 14:45:46 +0200 Message-ID: <4ADC5F7A.1060403@ericsson.com> Date: Mon, 19 Oct 2009 14:45:46 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: netconf-chairs@tools.ietf.org, tim.polk@nist.gov Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2009 12:45:46.0859 (UTC) FILETIME=[1452CBB0:01CA50BA] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list , iesg@ietf.org Subject: [Netconf] Netconf-partial-lock comment/discuss X-BeenThere: netconf@ietf.org X-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, 19 Oct 2009 12:45:46 -0000 Hello Tim, In the tracker https://datatracker.ietf.org/idtracker/ballot/3035 about the draft-ietf-netconf-partial-lock-09 you have the comment: Discuss [2009-08-13]: [revised discuss: I now agree that 4741 is not updated by this spec.] The following two issues (initially raised in Steve Hanna's late secdir review posted Monday August 11, see the email for the gory details) are also blocking: (1) The document assumes an access control mechanism is in place, but does not actually impose this as a requirement. I would like to see this language strengthened, since I do not see reasonable deployment scenarios that leverage partial locking and do not require access control. That is, if partial lock is supported an appropriate access control mechanism MUST also be in place. ---- ANSWER: Updated text in 2.4.1 to indicate authentication is MANDATORY and access control (if implemented) must be also passed. Access control is not standardized for NETCONF so we cant make it mandatory, however it is strongly recommended (In the security section). If access control is implemented by the Netconf server, partial-lock must be subject to it. Today practically all implementations implement access control even if in a proprietary way, so the situation is quite good. Updated security section to indicate this. Excerpts from the already stored -10 draft: 2.4.1 " A partial lock operation MUST fail if: o The requesting user is not successfully authenticated. o The NETCONF server implements access control, and the locking user does not have sufficient access rights. The exact handling of access rights is outside the scope of this document, but it is assumed that there is an access control system that MAY deny or allow the partial lock operation. " 3. Security Considerations " The same considerations are relevant as for the base NETCONF Protocol [NETCONF]. and RPCs MUST only be allowed for an authenticated user. and RPCs SHOULD only be allowed for an authorized user. However as NETCONF access control is not standardized and not a mandatory part of a NETCONF implementation, it is strongly recommended, but OPTIONAL (although nearly all implementations include some kind of access control). A lock (either a partial lock or a global lock) might prevent other users from configuring the system. The following mechanisms are in place to prevent the misuse of this possibility: A user, that is not successfully authenticated, MUST NOT be granted a partial lock. Only an authorized user SHOULD be able to request a partial lock. ... " ---- Discuss: (2) The complexities of specifying the scope for related operations should be highlighted, along with the consequences of incorrect scoping. (Steve's review includes a specific example of the results when the scope is specified without considering related operations.) I would also recommend adding a pointer in the security considerations to section 2.1.1.3, where the dangers of multiple managers in a semi-coordinated mode are detailed. The results are sufficiently bad to merit a reminder in the ---- ANSWER: The complexities of specifying the scope and some related issues are pointed out in 2.4.1 " o If part of the running datastore is locked, this has no effect on any unlocked parts of the datastore. If this is a problem (e.g., changes depend on data values or nodes outside the protected part of the datastore), these nodes SHOULD be included in the protected area of the lock. o Configuration data can be edited both inside and outside the protected area of a lock. It is the responsibility of the NETCONF client application to lock all relevant parts of the datastore that are crucial for a specific management action. " Due to other comments the possibility of locking the candidate database have been removed and with that the whole use case (and the chapter 2.1.1.3). ---- Comment [2009-08-13]: Steve's review included a number of editorial comments the authors may wish to consider. ---- ANSWER: Comments accepted, document updated. See the already stored -10 draft for details. ---- Please indicate if you can accept these answers! regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. 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 Oct 19 05:52: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 66C213A6997; Mon, 19 Oct 2009 05:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SVnGMgoQZhr; Mon, 19 Oct 2009 05:52:45 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 39FFB3A67D7; Mon, 19 Oct 2009 05:52:45 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-ea-4adc61227a69 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 99.D6.04191.2216CDA4; Mon, 19 Oct 2009 14:52:50 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 14:52:50 +0200 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 14:52:49 +0200 Message-ID: <4ADC6121.90908@ericsson.com> Date: Mon, 19 Oct 2009 14:52:49 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: netconf-chairs@tools.ietf.org, "Romascanu, Dan (Dan)" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2009 12:52:50.0040 (UTC) FILETIME=[108F1780:01CA50BB] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list , iesg@ietf.org Subject: [Netconf] Netconf-partial-lock comment/discuss X-BeenThere: netconf@ietf.org X-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, 19 Oct 2009 12:52:46 -0000 Hello Dan, In the tracker https://datatracker.ietf.org/idtracker/ballot/3035 about the draft-ietf-netconf-partial-lock-09 you have the comment: Discuss [2009-08-12]: Late discussions among the editors and implementers of the NETCONF standard raised the issue of possibly removing partial-lock for startup, since it was clarified in 4741bis that startup cannot be modified with edit-config. I am holding a DISCUSS until the WG reaches the consensus on this issue. ANSWER: startup and candidate datastores removed from the scope in the already stored -10 draft. They can not be locked with partial-lock. Startup was removed due to the argument you raised, candidate because: - partial-locking was always aimed predominantly towards the running database. Partially-Locking the candidate was always seen as a lesser use-case included for completeness. - a number of people objected that having partial locking with a global commit operation will lead to problems - the workgroup consensus was not broad enough Please indicate if you can accept these answers! regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From bertietf@bwijnen.net Mon Oct 19 05:57: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 A1DAB28C183; Mon, 19 Oct 2009 05:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuUNYLck1npt; Mon, 19 Oct 2009 05:57:56 -0700 (PDT) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id E872528C17B; Mon, 19 Oct 2009 05:57:55 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1Mzro4-00016Y-6D; Mon, 19 Oct 2009 14:57:53 +0200 Received: from guest-24.ripe.net (chimp.ripe.net [193.0.1.199]) by herring.ripe.net (Postfix) with ESMTP id 236FB2F592; Mon, 19 Oct 2009 14:57:48 +0200 (CEST) Message-ID: <4ADC624B.7020900@bwijnen.net> Date: Mon, 19 Oct 2009 14:57:47 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Adrian Farrel References: <4ADC5AD1.2020402@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd48ee52339d4807c87f9c0351952382dab Cc: iesg@ietf.org, netconf mailing list , netconf-chairs@tools.ietf.org Subject: Re: [Netconf] Netconf-partial-lock comment/discuss X-BeenThere: netconf@ietf.org X-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, 19 Oct 2009 12:57:56 -0000 Adrian Farrel wrote: > >> Please indicate if you can accept these answers! > > Good job. Very acceptable. > > Thanks, > Adrian > > Thanks Adrian Bert Wijnen document shepherd From Adrian.Farrel@huawei.com Mon Oct 19 05:44: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 C0DA93A6887; Mon, 19 Oct 2009 05:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.732 X-Spam-Level: X-Spam-Status: No, score=-0.732 tagged_above=-999 required=5 tests=[AWL=-0.547, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D39J+APWZuab; Mon, 19 Oct 2009 05:44:01 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 0A9D03A67E4; Mon, 19 Oct 2009 05:44:01 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRR0029ZI1J3G@usaga03-in.huawei.com>; Mon, 19 Oct 2009 07:44:07 -0500 (CDT) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRR005R0I1GFS@usaga03-in.huawei.com>; Mon, 19 Oct 2009 07:44:06 -0500 (CDT) Date: Mon, 19 Oct 2009 13:42:23 +0100 From: Adrian Farrel To: Balazs Lengyel , netconf-chairs@tools.ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=Windows-1252; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4ADC5AD1.2020402@ericsson.com> X-Mailman-Approved-At: Mon, 19 Oct 2009 05:58:39 -0700 Cc: netconf mailing list , iesg@ietf.org Subject: Re: [Netconf] Netconf-partial-lock comment/discuss X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 12:44:01 -0000 > Please indicate if you can accept these answers! Good job. Very acceptable. Thanks, Adrian From william.polk@nist.gov Mon Oct 19 07:12: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 B60643A68C6; Mon, 19 Oct 2009 07:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.392 X-Spam-Level: X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=0.206, 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 lr8-MK-AjLuv; Mon, 19 Oct 2009 07:12:54 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id DB6BE3A6836; Mon, 19 Oct 2009 07:12:53 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n9JED4HN015464; Mon, 19 Oct 2009 10:13:04 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Mon, 19 Oct 2009 10:12:45 -0400 From: "Polk, William T." To: Balazs Lengyel , "netconf-chairs@tools.ietf.org" , "Polk, William T." Date: Mon, 19 Oct 2009 10:12:45 -0400 Thread-Topic: Netconf-partial-lock comment/discuss Thread-Index: AcpQujAMLx1/7FQDSR+v708dT+GkWQADAqFo Message-ID: In-Reply-To: <4ADC5F7A.1060403@ericsson.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C701EC1D176D4timpolknistgov_" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov X-Mailman-Approved-At: Mon, 19 Oct 2009 07:32:34 -0700 Cc: netconf mailing list , "iesg@ietf.org" Subject: Re: [Netconf] Netconf-partial-lock comment/discuss X-BeenThere: netconf@ietf.org X-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, 19 Oct 2009 14:12:55 -0000 --_000_C701EC1D176D4timpolknistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Balazs, Looks great! I have cleared. Thnaks, Tim On 10/19/09 8:45 AM, "Balazs Lengyel" wrote: Hello Tim, In the tracker https://datatracker.ietf.org/idtracker/ballot/3035 about the draft-ietf-netconf-partial-lock-09 you have the comment: Discuss [2009-08-13]: [revised discuss: I now agree that 4741 is not updated by this spec.] The following two issues (initially raised in Steve Hanna's late secdir rev= iew posted Monday August 11, see the email for the gory details) are also blocking: (1) The document assumes an access control mechanism is in place, but does = not actually impose this as a requirement. I would like to see this language strengthened, since I do not see reasonable deployment scenarios that leverage partial locking and do not require access control. That is, if partial lock is supported an appropriate access control mechanism MUST also be in place. ---- ANSWER: Updated text in 2.4.1 to indicate authentication is MANDATORY and a= ccess control (if implemented) must be also passed. Access control is not standardized for NE= TCONF so we cant make it mandatory, however it is strongly recommended (In the security sect= ion). If access control is implemented by the Netconf server, partial-lock must be subject = to it. Today practically all implementations implement access control even if in a propr= ietary way, so the situation is quite good. Updated security section to indicate this. Excerpt= s from the already stored -10 draft: 2.4.1 " A partial lock operation MUST fail if: o The requesting user is not successfully authenticated. o The NETCONF server implements access control, and the locking user does not have sufficient access rights. The exact handling of access rights is outside the scope of this document, but it is assumed that there is an access control system that MAY deny or allow the partial lock operation. " 3. Security Considerations " The same considerations are relevant as for the base NETCONF Protocol [NETCONF]. and RPCs MUST only be allowed for an authenticated user. and RPCs SHOULD only be allowed for an authorized user. However as NETCONF access control is not standardized and not a mandatory part of a NETCONF implementation, it is strongly recommended, but OPTIONAL (although nearly all implementations include some kind of access control). A lock (either a partial lock or a global lock) might prevent other users from configuring the system. The following mechanisms are in place to prevent the misuse of this possibility: A user, that is not successfully authenticated, MUST NOT be granted a partial lock. Only an authorized user SHOULD be able to request a partial lock. ... " ---- Discuss: (2) The complexities of specifying the scope for related operations should = be highlighted, along with the consequences of incorrect scoping. (Steve's review includes a specific example of the results when the scope is specified with= out considering related operations.) I would also recommend adding a pointer in the security considerations to section 2.1.1.3, where the dangers of multiple managers in a semi-coordinated mode are detailed. The results are sufficiently bad to merit a reminder in the ---- ANSWER: The complexities of specifying the scope and some related issues ar= e pointed out in 2.4.1 " o If part of the running datastore is locked, this has no effect on any unlocked parts of the datastore. If this is a problem (e.g., changes depend on data values or nodes outside the protected part of the datastore), these nodes SHOULD be included in the protected area of the lock. o Configuration data can be edited both inside and outside the protected area of a lock. It is the responsibility of the NETCONF client application to lock all relevant parts of the datastore that are crucial for a specific management action. " Due to other comments the possibility of locking the candidate database hav= e been removed and with that the whole use case (and the chapter 2.1.1.3). ---- Comment [2009-08-13]: Steve's review included a number of editorial comments the authors may wish= to consider. ---- ANSWER: Comments accepted, document updated. See the already stored -10 dra= ft for details. ---- Please indicate if you can accept these answers! regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com --_000_C701EC1D176D4timpolknistgov_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Netconf-partial-lock comment/discuss Hi Balazs,

Looks great!  I have cleared.

Thnaks,

Tim


On 10/19/09 8:45 AM, "Balazs Lengyel" <balazs.lengyel@ericsson.com> wrote:

Hello Tim,
In the tracker https://datatracker.ietf.org/idtracker/ballot/3035 about the
draft-ietf-netconf-partial-lock-09 you have the comment:

Discuss [2009-08-13]:
[revised discuss: I now agree that 4741 is not updated by this spec.]

The following two issues (initially raised in Steve Hanna's late secdir rev= iew
posted Monday
August 11, see the email for the gory details) are also blocking:

(1) The document assumes an access control mechanism is in place, but does = not
actually
impose this as a requirement.  I would like to see this language
strengthened, since I do
not see reasonable deployment scenarios that leverage
partial locking and do not require
access control.  That is, if partial lock is
supported an appropriate access control mechanism
MUST also be in place.

----
ANSWER: Updated text in 2.4.1 to indicate authentication is MANDATORY and a= ccess control (if
implemented) must be also passed. Access control is not standardized for NE= TCONF so we cant
make it mandatory, however it is strongly recommended (In the security sect= ion). If access
control is implemented by the Netconf server, partial-lock must be subject = to it. Today
practically all implementations implement access control even if in a propr= ietary way, so the
situation is quite good. Updated security section to indicate this. Excerpt= s from the already
stored -10 draft:
2.4.1
"   A partial lock operation MUST fail if:

    o  The requesting user is not successfully aut= henticated.

    o  The NETCONF server implements access contro= l, and the locking user
       does not have sufficient access r= ights.  The exact handling of
       access rights is outside the scop= e of this document, but it is
       assumed that there is an access c= ontrol system that MAY deny or
       allow the partial lock operation.=
"

3.  Security Considerations

"  The same considerations are relevant as for the base NETCONF P= rotocol
    [NETCONF]. <partial-lock> and <partial-unl= ock> RPCs MUST only be
    allowed for an authenticated user. <partial-lock= > and <partial-
    unlock> RPCs SHOULD only be allowed for an autho= rized user.  However
    as NETCONF access control is not standardized and n= ot a mandatory
    part of a NETCONF implementation, it is strongly re= commended, but
    OPTIONAL (although nearly all implementations inclu= de some kind of
    access control).

    A lock (either a partial lock or a global lock) mig= ht prevent other
    users from configuring the system.  The follow= ing mechanisms are in
    place to prevent the misuse of this possibility:
       A user, that is not successfully = authenticated, MUST NOT be
       granted a partial lock.

       Only an authorized user SHOULD be= able to request a partial lock.

       ...
"
----

Discuss:
(2) The complexities of specifying the scope for related operations should = be
highlighted,
along with the consequences of incorrect scoping.
(Steve's review
includes a specific example of the results when the scope is specified with= out
considering related operations.)

I would also recommend adding a pointer in the security considerations to section 2.1.1.3, where
the dangers of multiple managers in a semi-coordinated
mode are detailed.  The results are
sufficiently bad to merit a reminder in the

----
ANSWER: The complexities of specifying the scope and some related issues ar= e pointed out in 2.4.1
"
    o  If part of the running datastore is locked,= this has no effect on
       any unlocked parts of the datasto= re.  If this is a problem (e.g.,
       changes depend on data values or = nodes outside the protected part
       of the datastore), these nodes SH= OULD be included in the protected
       area of the lock.

    o  Configuration data can be edited both insid= e and outside the
       protected area of a lock.  I= t is the responsibility of the NETCONF
       client application to lock all re= levant parts of the datastore
       that are crucial for a specific m= anagement action.
"

Due to other comments the possibility of locking the candidate database hav= e been removed and
with that the whole use case (and the chapter 2.1.1.3).
----


Comment [2009-08-13]:
Steve's review included a number of editorial comments the authors may wish= to
consider.

----
ANSWER: Comments accepted, document updated. See the already stored -10 dra= ft for details.
----


Please indicate if you can accept these answers!

regards Balazs


--
Balazs Lengyel           =             Eri= csson Hungary Ltd.
System Manager
ECN: 831 7320           &= nbsp;           &nbs= p;Fax: +36 1 4377792
Tel: +36-1-437-7320          &= nbsp;       email: Balazs.Lengyel@ericsson.com

--_000_C701EC1D176D4timpolknistgov_-- From bertietf@bwijnen.net Mon Oct 19 07:32: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 0C86C28C102; Mon, 19 Oct 2009 07:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.199 X-Spam-Level: X-Spam-Status: No, score=-8.199 tagged_above=-999 required=5 tests=[AWL=2.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xo5gB-W0yWv0; Mon, 19 Oct 2009 07:32:35 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id C5DBD28C0FA; Mon, 19 Oct 2009 07:32:34 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MztHL-0003Og-EC; Mon, 19 Oct 2009 16:32:12 +0200 Received: from guest-24.ripe.net (chimp.ripe.net [193.0.1.199]) by herring.ripe.net (Postfix) with ESMTP id 5FBCB2F592; Mon, 19 Oct 2009 16:32:07 +0200 (CEST) Message-ID: <4ADC7867.3090500@bwijnen.net> Date: Mon, 19 Oct 2009 16:32:07 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Polk, William T." References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd409c482499d08107af669c968014b6920 Cc: "iesg@ietf.org" , netconf mailing list , "netconf-chairs@tools.ietf.org" Subject: Re: [Netconf] Netconf-partial-lock comment/discuss X-BeenThere: netconf@ietf.org X-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, 19 Oct 2009 14:32:36 -0000 Thanks TIm, Bert Wijnen Document shepherd Polk, William T. wrote: > Hi Balazs, > > Looks great! I have cleared. > > Thnaks, > > Tim > > > On 10/19/09 8:45 AM, "Balazs Lengyel" wrote: > > Hello Tim, > In the tracker https://datatracker.ietf.org/idtracker/ballot/3035 > about the > draft-ietf-netconf-partial-lock-09 you have the comment: > > Discuss [2009-08-13]: > [revised discuss: I now agree that 4741 is not updated by this spec.] > > The following two issues (initially raised in Steve Hanna's late > secdir review > posted Monday > August 11, see the email for the gory details) are also blocking: > > (1) The document assumes an access control mechanism is in place, > but does not > actually > impose this as a requirement. I would like to see this language > strengthened, since I do > not see reasonable deployment scenarios that leverage > partial locking and do not require > access control. That is, if partial lock is > supported an appropriate access control mechanism > MUST also be in place. > > ---- > ANSWER: Updated text in 2.4.1 to indicate authentication is > MANDATORY and access control (if > implemented) must be also passed. Access control is not > standardized for NETCONF so we cant > make it mandatory, however it is strongly recommended (In the > security section). If access > control is implemented by the Netconf server, partial-lock must be > subject to it. Today > practically all implementations implement access control even if > in a proprietary way, so the > situation is quite good. Updated security section to indicate > this. Excerpts from the already > stored -10 draft: > 2.4.1 > " A partial lock operation MUST fail if: > > o The requesting user is not successfully authenticated. > > o The NETCONF server implements access control, and the > locking user > does not have sufficient access rights. The exact handling of > access rights is outside the scope of this document, but it is > assumed that there is an access control system that MAY deny or > allow the partial lock operation. > " > > 3. Security Considerations > > " The same considerations are relevant as for the base NETCONF > Protocol > [NETCONF]. and RPCs MUST only be > allowed for an authenticated user. and unlock> RPCs SHOULD only be allowed for an authorized user. > However > as NETCONF access control is not standardized and not a mandatory > part of a NETCONF implementation, it is strongly recommended, but > OPTIONAL (although nearly all implementations include some kind of > access control). > > A lock (either a partial lock or a global lock) might prevent > other > users from configuring the system. The following mechanisms > are in > place to prevent the misuse of this possibility: > > A user, that is not successfully authenticated, MUST NOT be > granted a partial lock. > > Only an authorized user SHOULD be able to request a partial > lock. > > ... > " > ---- > > Discuss: > (2) The complexities of specifying the scope for related > operations should be > highlighted, > along with the consequences of incorrect scoping. > (Steve's review > includes a specific example of the results when the scope is > specified without > considering related operations.) > > I would also recommend adding a pointer in the security > considerations to > section 2.1.1.3, where > the dangers of multiple managers in a semi-coordinated > mode are detailed. The results are > sufficiently bad to merit a reminder in the > > ---- > ANSWER: The complexities of specifying the scope and some related > issues are pointed out in 2.4.1 > " > o If part of the running datastore is locked, this has no > effect on > any unlocked parts of the datastore. If this is a problem > (e.g., > changes depend on data values or nodes outside the > protected part > of the datastore), these nodes SHOULD be included in the > protected > area of the lock. > > o Configuration data can be edited both inside and outside the > protected area of a lock. It is the responsibility of the > NETCONF > client application to lock all relevant parts of the datastore > that are crucial for a specific management action. > " > > Due to other comments the possibility of locking the candidate > database have been removed and > with that the whole use case (and the chapter 2.1.1.3). > ---- > > > Comment [2009-08-13]: > Steve's review included a number of editorial comments the authors > may wish to > consider. > > ---- > ANSWER: Comments accepted, document updated. See the already > stored -10 draft for details. > ---- > > > Please indicate if you can accept these answers! > > regards Balazs > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > System Manager > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email: > Balazs.Lengyel@ericsson.com > From mehmet.ersue@nsn.com Tue Oct 20 05:36: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 5851B3A63EB for ; Tue, 20 Oct 2009 05:36: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOXlt-iV34-8 for ; Tue, 20 Oct 2009 05:36:23 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id E542B3A688C for ; Tue, 20 Oct 2009 05:36:22 -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 n9KCaR4K012664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Oct 2009 14:36:27 +0200 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 n9KCaLZe014595; Tue, 20 Oct 2009 14:36:26 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 14:36:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Oct 2009 14:36:24 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64031460@DEMUEXC006.nsn-intra.net> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D1A9F69CD@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for draft-ietf-netconf-monitoring-09 Thread-Index: AcpM8tHJxxCBJN7QSL2T+SkMdEFmTwAABoPAASNfCEA= References: <085091CB2CA14E4B8B163FFC37C84E9D1A9F69CD@zcarhxm0.corp.nortel.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 20 Oct 2009 12:36:25.0862 (UTC) FILETIME=[F05B3260:01CA5181] Subject: [Netconf] WGLC for draft-ietf-netconf-monitoring-09 X-BeenThere: netconf@ietf.org X-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, 20 Oct 2009 12:36:24 -0000 Dear NETCONF WG,=20 we had a good discussion on the NETCONF monitoring=20 draft since the last WGLC in July.=20 The draft Mark and Martin submitted solves the issues=20 raised on the maillist and introduces the YANG model=20 as normative. The new version of the draft appears to=20 be stable for a final WGLC before we go one step further.=20 With this mail we start a new WGLC for the NETCONF=20 monitoring draft, which is planned to publish as a=20 Proposed Standard RFC. The WGLC will run until=20 November 2, 2009.=20 All WG members PLEASE REVIEW the draft again and send=20 your comments to the NETCONF maillist: http://tools.ietf.org/html/draft-ietf-netconf-monitoring-09 Thank you.=20 Mehmet =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Mark Scott > Sent: Wednesday, October 14, 2009 7:47 PM > To: netconf@ietf.org > Subject: [Netconf] FW: New Version Notification=20 > fordraft-ietf-netconf-monitoring-09 >=20 > Hello, >=20 > A new version (v9) of the NETCONF Monitoring Schema draft has=20 > been posted. >=20 > This version addresses mailing list comments received on v8: > - reversion of 'session-type' to 'transport' > - element naming consistency. All lowerCamelCase names have=20 > been converted to 'hyphen-delimited' or=20 > 'netconf-style-naming' as it is sometimes referred to on the=20 > ML. E.g. 'sessionType' -> 'session-type'. This change=20 > impacts both the draft text and yang module. =20 > - operation updated: > - now has only one mandatory parameter, 'identifier' > - updated negative responses, including the rpc=20 > operation description in yang module > - comments added to the yang module indicating that the=20 > definition of 'session-id' is consistent with 4741bis=20 > 'session-id-type' and could be imported from that pending=20 > RFC. Similar for 'netconf-datastore-type'. This was in=20 > favour of adding further dependencies and delays by waiting=20 > for 4741bis to complete. > =20 > Please direct any comments on this version to the mailing list. >=20 > cheers, > Mark >=20 >=20 > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 > Sent: Wednesday, October 14, 2009 1:22 PM > To: Scott, Mark (CAR:2N00) > Cc: mbj@tail-f.com > Subject: New Version Notification for=20 > draft-ietf-netconf-monitoring-09=20 >=20 >=20 > A new version of I-D, draft-ietf-netconf-monitoring-09.txt=20 > has been successfuly submitted by Mark Scott and posted to=20 > the IETF repository. >=20 > Filename: draft-ietf-netconf-monitoring > Revision: 09 > Title: NETCONF Monitoring Schema > Creation_date: 2009-10-14 > WG ID: netconf > Number_of_pages: 30 >=20 > Abstract: > This document defines a NETCONF data model to be used to monitor the > NETCONF protocol. The monitoring data model includes information > about NETCONF datastores, sessions, locks 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. > =20 > =20 >=20 >=20 > The IETF Secretariat. >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From dromasca@avaya.com Tue Oct 20 06:08: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 E391A3A69B7; Tue, 20 Oct 2009 06:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 SFFlHqj3o02v; Tue, 20 Oct 2009 06:08:36 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 779B63A6947; Tue, 20 Oct 2009 06:08:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,591,1249272000"; d="scan'208";a="160815687" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Oct 2009 09:08:41 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 20 Oct 2009 09:08:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Oct 2009 15:08:26 +0200 Message-ID: In-Reply-To: <4ADC6121.90908@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Netconf-partial-lock comment/discuss Thread-Index: AcpQuxLSxHQAufFqTKu2JDlfTzBACgAyzrAA References: <4ADC6121.90908@ericsson.com> From: "Romascanu, Dan (Dan)" To: "Balazs Lengyel" , Cc: netconf mailing list , iesg@ietf.org Subject: Re: [Netconf] Netconf-partial-lock comment/discuss X-BeenThere: netconf@ietf.org X-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, 20 Oct 2009 13:08:37 -0000 This looks fine. I have cleared my DISCUSS and changed my vote to a 'Yes'.=20 Thank you for addressing my concerns.=20 Regards, Dan =20 > -----Original Message----- > From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com]=20 > Sent: Monday, October 19, 2009 2:53 PM > To: netconf-chairs@tools.ietf.org; Romascanu, Dan (Dan) > Cc: netconf mailing list; iesg@ietf.org > Subject: Netconf-partial-lock comment/discuss >=20 > Hello Dan, > In the tracker=20 > https://datatracker.ietf.org/idtracker/ballot/3035 about the > draft-ietf-netconf-partial-lock-09 you have the comment: >=20 > Discuss [2009-08-12]: > Late discussions among the editors and implementers of the=20 > NETCONF standard raised the issue of possibly removing=20 > partial-lock for startup, since it was clarified in 4741bis=20 > that startup cannot be modified with edit-config. I am=20 > holding a DISCUSS until the WG reaches the consensus on this issue. >=20 > ANSWER: startup and candidate datastores removed from the=20 > scope in the already stored -10 draft. They can not be locked=20 > with partial-lock. Startup was removed due to the argument=20 > you raised, candidate because: > - partial-locking was always aimed predominantly towards the=20 > running database.=20 > Partially-Locking the candidate was always seen as a lesser=20 > use-case included for completeness. > - a number of people objected that having partial locking=20 > with a global commit operation will lead to problems > - the workgroup consensus was not broad enough >=20 >=20 >=20 > Please indicate if you can accept these answers! >=20 > regards Balazs >=20 >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > System Manager > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email:=20 > Balazs.Lengyel@ericsson.com >=20 From bertietf@bwijnen.net Tue Oct 20 07:01: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 258A03A69B4; Tue, 20 Oct 2009 07:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCoRX0Qh3+OG; Tue, 20 Oct 2009 07:01:57 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 898EF3A67A6; Tue, 20 Oct 2009 07:01:57 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1N0FHd-0003f7-Dn; Tue, 20 Oct 2009 16:01:58 +0200 Received: from guest-24.ripe.net (dog.ripe.net [193.0.1.217]) by herring.ripe.net (Postfix) with ESMTP id 5B9312F592; Tue, 20 Oct 2009 16:01:53 +0200 (CEST) Message-ID: <4ADDC2D1.1080309@bwijnen.net> Date: Tue, 20 Oct 2009 16:01:53 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4ADC6121.90908@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4c9c8790407d8ec2d9c591696db2408c6 Cc: iesg@ietf.org, netconf mailing list , netconf-chairs@tools.ietf.org Subject: Re: [Netconf] Netconf-partial-lock comment/discuss X-BeenThere: netconf@ietf.org X-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, 20 Oct 2009 14:01:59 -0000 Thanks Dan, So the last DISCUSS we're dealing with is the one from Alexey. Lookingat that right now. Bert Wijnen Document shepherd Romascanu, Dan (Dan) wrote: > This looks fine. I have cleared my DISCUSS and changed my vote to a > 'Yes'. > > Thank you for addressing my concerns. > > Regards, > > Dan > > > >> -----Original Message----- >> From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] >> Sent: Monday, October 19, 2009 2:53 PM >> To: netconf-chairs@tools.ietf.org; Romascanu, Dan (Dan) >> Cc: netconf mailing list; iesg@ietf.org >> Subject: Netconf-partial-lock comment/discuss >> >> Hello Dan, >> In the tracker >> https://datatracker.ietf.org/idtracker/ballot/3035 about the >> draft-ietf-netconf-partial-lock-09 you have the comment: >> >> Discuss [2009-08-12]: >> Late discussions among the editors and implementers of the >> NETCONF standard raised the issue of possibly removing >> partial-lock for startup, since it was clarified in 4741bis >> that startup cannot be modified with edit-config. I am >> holding a DISCUSS until the WG reaches the consensus on this issue. >> >> ANSWER: startup and candidate datastores removed from the >> scope in the already stored -10 draft. They can not be locked >> with partial-lock. Startup was removed due to the argument >> you raised, candidate because: >> - partial-locking was always aimed predominantly towards the >> running database. >> Partially-Locking the candidate was always seen as a lesser >> use-case included for completeness. >> - a number of people objected that having partial locking >> with a global commit operation will lead to problems >> - the workgroup consensus was not broad enough >> >> >> >> Please indicate if you can accept these answers! >> >> regards Balazs >> >> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> System Manager >> ECN: 831 7320 Fax: +36 1 4377792 >> Tel: +36-1-437-7320 email: >> Balazs.Lengyel@ericsson.com >> >> > > > From root@core3.amsl.com Tue Oct 20 08:30:02 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 E618328C127; Tue, 20 Oct 2009 08:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091020153001.E618328C127@core3.amsl.com> Date: Tue, 20 Oct 2009 08:30:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-partial-lock-11.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, 20 Oct 2009 15:30:02 -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 : Partial Lock RPC for NETCONF Author(s) : B. Lengyel, M. Bjorklund Filename : draft-ietf-netconf-partial-lock-11.txt Pages : 29 Date : 2009-10-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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-partial-lock-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-partial-lock-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-20081902.I-D@ietf.org> --NextPart-- From balazs.lengyel@ericsson.com Tue Oct 20 08:32: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 A1C6A3A6A24 for ; Tue, 20 Oct 2009 08:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tu-ssRZRvoG for ; Tue, 20 Oct 2009 08:32:35 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D43E63A6863 for ; Tue, 20 Oct 2009 08:32:34 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-6b-4addd819b995 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 15.3B.24026.918DDDA4; Tue, 20 Oct 2009 17:32:41 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 17:32:41 +0200 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 17:32:40 +0200 Message-ID: <4ADDD818.1020900@ericsson.com> Date: Tue, 20 Oct 2009 17:32:40 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: netconf mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2009 15:32:40.0912 (UTC) FILETIME=[8F93C500:01CA519A] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Partial-lock updates -10 and -11 X-BeenThere: netconf@ietf.org X-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, 20 Oct 2009 15:32:38 -0000 Hello, The partial-lock draft was updated due to the IESG review. One major change: removal of the candidate and startup configurations from the scope of the partial-lock. All other changes are minor clarifications. Balazs From bertietf@bwijnen.net Tue Oct 20 10:58:27 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 4E1843A677E for ; Tue, 20 Oct 2009 10:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.161 X-Spam-Level: X-Spam-Status: No, score=0.161 tagged_above=-999 required=5 tests=[AWL=0.604, 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 Imw+kA8JDDV8 for ; Tue, 20 Oct 2009 10:58:26 -0700 (PDT) Received: from relay.versatel.net (relay56.tele2.vuurwerk.nl [62.250.3.56]) by core3.amsl.com (Postfix) with ESMTP id 44AD13A679C for ; Tue, 20 Oct 2009 10:58:25 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1N0Iye-0002ve-Dj; Tue, 20 Oct 2009 19:58:32 +0200 Message-ID: <88EF7CD027DB43E196C0390074F90161@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "netconf mailing list" References: <4ADDD818.1020900@ericsson.com> In-Reply-To: <4ADDD818.1020900@ericsson.com> Date: Tue, 20 Oct 2009 19:58:00 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_15F4_01CA51BF.A024A540" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Subject: [Netconf] We're done: Partial-lock-11 is the latest and final version X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 17:58:27 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_15F4_01CA51BF.A024A540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Netconf WG participants, you have all seen the responses that Balazs made to the 5 ADs who held a DISCUSS. As a result, balzs did a new rev 11 to address=20 a small (in my view rather) editorial fix. The text was also in the response from Alexey. This coming Thursday, the IESG has a telechat. I would urge any WG participant who thinks that there are still issues = to=20 bring them up before Thursday 22nd of October (so today or Wednesday).=20 If we do not get any, then I hereby declare consensus and ask our AD to move the document into the RFC-Editor queue.=20 Thanks to Balazs and Martin! Bert Wijnen co-chair of NETCONF WG partial loack document shepherd. ----- Original Message -----=20 From: Balazs Lengyel=20 To: netconf mailing list=20 Sent: Tuesday, October 20, 2009 5:32 PM Subject: [Netconf] Partial-lock updates -10 and -11 Hello, The partial-lock draft was updated due to the IESG review. One major change: removal of the candidate and startup configurations = from the scope of the=20 partial-lock. All other changes are minor clarifications. Balazs ------=_NextPart_000_15F4_01CA51BF.A024A540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Netconf WG participants,
 
you have all seen the responses that Balazs made to = the 5=20 ADs
who held a DISCUSS. As a result, balzs did a = new rev 11=20 to address
a small (in my view rather) editorial fix. The text = was also=20 in the
response from Alexey.
 
This coming Thursday, the IESG has a = telechat.
I would urge any WG participant who thinks that = there are=20 still issues to
bring them up before Thursday 22nd of October (so = today or=20 Wednesday). 
 
If we do not get any, then I hereby declare = consensus and ask=20 our AD to
move the document into the RFC-Editor queue. =
 
Thanks to Balazs and Martin!
 
Bert Wijnen
co-chair of NETCONF WG
partial loack document shepherd.
 
----- Original Message -----
From:=20 Balazs Lengyel
Sent: Tuesday, October 20, 2009 = 5:32=20 PM
Subject: [Netconf] Partial-lock = updates=20 -10 and -11

Hello,
The=20 partial-lock draft was updated due to the IESG review.

One = major=20 change: removal of the candidate and startup configurations from the = scope of=20 the
partial-lock.

All other changes are minor=20 clarifications.

Balazs
------=_NextPart_000_15F4_01CA51BF.A024A540-- From andy@netconfcentral.com Tue Oct 20 11:20:18 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 B4D0E28C192 for ; Tue, 20 Oct 2009 11:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 UC+itBwtjLiq for ; Tue, 20 Oct 2009 11:20:18 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id E298E28C186 for ; Tue, 20 Oct 2009 11:20:17 -0700 (PDT) Received: (qmail 86518 invoked from network); 20 Oct 2009 18:20:23 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 20 Oct 2009 18:20:23 -0000 X-YMail-OSG: 5LeP4kwVM1ntZyXCJkm._iDICerGe5A0Om.UbUKF3NQoJKKbU0z.KTnI4v9PmwDkfvboUVwzqhr1llF1d3oFJLA8NJE19mVF.hC893bqJqrFtGOANjaXt9RJ3d0qNRvhgBnEq8twd6M4eZfdOHgIPXb8e_IKFsqKU10ERkgAVCgUcWVGJIZhX06YHKmPPZwbqMX1WfYtqG8eVPrRrptUw3ieHTs9WOrERG503GKTJZCVgMLq3BelbANFkM3dmKpYj6xKMliQVTQSqSux4P4fJq6wmSsXwzXg6c9xIrxrucHFwXP3Rw6eioirjCStFnuApV.iWCfuBjZnUV.NqSCPzz0JUn6ztdXEgNZmZFk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ADDFF97.5040407@netconfcentral.com> Date: Tue, 20 Oct 2009 11:21:11 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <4ADDD818.1020900@ericsson.com> <88EF7CD027DB43E196C0390074F90161@BertLaptop> In-Reply-To: <88EF7CD027DB43E196C0390074F90161@BertLaptop> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf mailing list Subject: Re: [Netconf] We're done: Partial-lock-11 is the latest and final version X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:20:18 -0000 Bert Wijnen (IETF) wrote: > Dear Netconf WG participants, > > you have all seen the responses that Balazs made to the 5 ADs > who held a DISCUSS. As a result, balzs did a new rev 11 to address > a small (in my view rather) editorial fix. The text was also in the > response from Alexey. > > This coming Thursday, the IESG has a telechat. > I would urge any WG participant who thinks that there are still issues to > bring them up before Thursday 22nd of October (so today or Wednesday). > > If we do not get any, then I hereby declare consensus and ask our AD to > move the document into the RFC-Editor queue. > I reviewed the diffs between -09 to -10, and -10 to -11. Looks good to me. All my concerns have been addressed. thanks, Andy > Thanks to Balazs and Martin! > > Bert Wijnen > co-chair of NETCONF WG > partial loack document shepherd. > > ----- Original Message ----- > > *From:* Balazs Lengyel > *To:* netconf mailing list > *Sent:* Tuesday, October 20, 2009 5:32 PM > *Subject:* [Netconf] Partial-lock updates -10 and -11 > > Hello, > The partial-lock draft was updated due to the IESG review. > > One major change: removal of the candidate and startup > configurations from the scope of the > partial-lock. > > All other changes are minor clarifications. > > Balazs > > > ------------------------------------------------------------------------ > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From bertietf@bwijnen.net Tue Oct 20 11:32: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 34DE53A6944 for ; Tue, 20 Oct 2009 11:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.041 X-Spam-Level: X-Spam-Status: No, score=0.041 tagged_above=-999 required=5 tests=[AWL=0.483, 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 axzoh6LBk+mo for ; Tue, 20 Oct 2009 11:32:39 -0700 (PDT) Received: from relay.versatel.net (relay56.tele2.vuurwerk.nl [62.250.3.56]) by core3.amsl.com (Postfix) with ESMTP id C09AF28C0DD for ; Tue, 20 Oct 2009 11:32:37 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1N0JVk-00061Q-Be; Tue, 20 Oct 2009 20:32:44 +0200 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Andy Bierman" References: <4ADDD818.1020900@ericsson.com> <88EF7CD027DB43E196C0390074F90161@BertLaptop> <4ADDFF97.5040407@netconfcentral.com> In-Reply-To: <4ADDFF97.5040407@netconfcentral.com> Date: Tue, 20 Oct 2009 20:27:37 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_16A1_01CA51C3.C3AD0850" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Cc: netconf mailing list Subject: Re: [Netconf] We're done: Partial-lock-11 is the latest and final version X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:32:40 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_16A1_01CA51C3.C3AD0850 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Andy. Such positive feedback is very welcome too! Bert document shepherd ----- Original Message -----=20 From: Andy Bierman=20 To: Bert Wijnen (IETF)=20 Cc: netconf mailing list=20 Sent: Tuesday, October 20, 2009 8:21 PM Subject: Re: [Netconf] We're done: Partial-lock-11 is the latest and = final version Bert Wijnen (IETF) wrote: > Dear Netconf WG participants, > =20 > you have all seen the responses that Balazs made to the 5 ADs > who held a DISCUSS. As a result, balzs did a new rev 11 to address > a small (in my view rather) editorial fix. The text was also in the > response from Alexey. > =20 > This coming Thursday, the IESG has a telechat. > I would urge any WG participant who thinks that there are still = issues to > bring them up before Thursday 22nd of October (so today or = Wednesday).=20 > =20 > If we do not get any, then I hereby declare consensus and ask our AD = to > move the document into the RFC-Editor queue. > =20 I reviewed the diffs between -09 to -10, and -10 to -11. Looks good to me. All my concerns have been addressed. thanks, Andy > Thanks to Balazs and Martin! > =20 > Bert Wijnen > co-chair of NETCONF WG > partial loack document shepherd. > =20 > ----- Original Message ----- >=20 > *From:* Balazs Lengyel > *To:* netconf mailing list > *Sent:* Tuesday, October 20, 2009 5:32 PM > *Subject:* [Netconf] Partial-lock updates -10 and -11 >=20 > Hello, > The partial-lock draft was updated due to the IESG review. >=20 > One major change: removal of the candidate and startup > configurations from the scope of the > partial-lock. >=20 > All other changes are minor clarifications. >=20 > Balazs >=20 >=20 > = ------------------------------------------------------------------------ >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -------------------------------------------------------------------------= ----- No virus found in this incoming message. Checked by AVG - www.avg.com=20 Version: 8.5.422 / Virus Database: 270.14.23/2448 - Release Date: = 10/20/09 10:43:00 ------=_NextPart_000_16A1_01CA51C3.C3AD0850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks Andy.
 
Such positive feedback is very welcome = too!
 
Bert
document shepherd
----- Original Message -----
From:=20 Andy=20 Bierman
Sent: Tuesday, October 20, 2009 = 8:21=20 PM
Subject: Re: [Netconf] We're = done:=20 Partial-lock-11 is the latest and final version

Bert Wijnen (IETF) wrote:
> Dear Netconf WG=20 participants,
> 
> you have all seen the responses = that=20 Balazs made to the 5 ADs
> who held a DISCUSS. As a result, = balzs did a=20 new rev 11 to address
> a small (in my view rather) editorial = fix. The=20 text was also in the
> response from Alexey.
>  =
> This=20 coming Thursday, the IESG has a telechat.
> I would urge any WG=20 participant who thinks that there are still issues to
> bring = them up=20 before Thursday 22nd of October (so today or Wednesday). =
> =20
> If we do not get any, then I hereby declare consensus and ask = our AD=20 to
> move the document into the RFC-Editor queue.
> =20

I reviewed the diffs between -09 to -10, and -10 to = -11.
Looks good=20 to me.  All my concerns have been=20 addressed.

thanks,
Andy

> Thanks to Balazs and=20 Martin!
> 
> Bert Wijnen
> co-chair of NETCONF = WG
> partial loack document shepherd.
> 
> = -----=20 Original Message -----
>
>     = *From:* Balazs=20 Lengyel <mailto:balazs.lengyel@ericsso= n.com>
>    =20 *To:* netconf mailing list <mailto:netconf@ietf.org>
>&= nbsp;   =20 *Sent:* Tuesday, October 20, 2009 5:32 = PM
>    =20 *Subject:* [Netconf] Partial-lock updates -10 and -11
>=20
>     = Hello,
>     The=20 partial-lock draft was updated due to the IESG review.
>=20
>     One major change: removal of the = candidate=20 and startup
>     configurations from the = scope of=20 the
>     partial-lock.
>=20
>     All other changes are minor=20 clarifications.
>
>     = Balazs
>=20
>
>=20 = ------------------------------------------------------------------------<= BR>>=20
> _______________________________________________
> = Netconf=20 mailing list
> Netconf@ietf.org
> https://www.ietf.o= rg/mailman/listinfo/netconf


No virus found in this incoming message.
Checked by AVG = - www.avg.com
Version: 8.5.422 / = Virus=20 Database: 270.14.23/2448 - Release Date: 10/20/09=20 10:43:00
------=_NextPart_000_16A1_01CA51C3.C3AD0850-- From balazs.lengyel@ericsson.com Wed Oct 21 09:02: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 8398D3A6844; Wed, 21 Oct 2009 09:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WrCuhU7GFZY; Wed, 21 Oct 2009 09:02:18 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 30F153A68CC; Wed, 21 Oct 2009 09:02:17 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-09-4adf309147cf Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 06.C5.04191.1903FDA4; Wed, 21 Oct 2009 18:02:25 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 18:02:25 +0200 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 18:02:24 +0200 Message-ID: <4ADF3090.7090903@ericsson.com> Date: Wed, 21 Oct 2009 18:02:24 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: Phil Shafer References: <200909011930.n81JU7WS093379@idle.juniper.net> In-Reply-To: <200909011930.n81JU7WS093379@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2009 16:02:24.0779 (UTC) FILETIME=[E14205B0:01CA5267] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list , netmod@ietf.org Subject: Re: [Netconf] [netmod] meaning of default X-BeenThere: netconf@ietf.org X-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, 21 Oct 2009 16:02:19 -0000 Hello, I have the feeling that we should make with-defaults MANDATORY for all nodes using YANG. (Currently report-all is the only mode that is mandatory to support in with-defaults.) Opinions? Balazs On 09/01/09 21:30, Phil Shafer wrote: > Andy Bierman writes: >> You want to force your way of thinking on everybody >> else by insisting that your server does not need >> to ever make the full data-set available to any client, >> or to even let the client know what sort of 'server-pruning' >> is being done. > > The current scheme in YANG allows the server to behave in any of > the three styles listed in the with-defaults draft. We have > sufficient flexibility to allow you to work the way you want, and > to allow others to work the way they work. This is good. > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From phil@juniper.net Wed Oct 21 09:21: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 DF75C28C0F5; Wed, 21 Oct 2009 09:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 ntzmcPrVLJHF; Wed, 21 Oct 2009 09:21:25 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 7F81128B56A; Wed, 21 Oct 2009 09:21:22 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSt81CkqdB5uFxpnA/nMRezbp/EamwCFm@postini.com; Wed, 21 Oct 2009 09:21:34 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.375.2; Wed, 21 Oct 2009 09:16:30 -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); Wed, 21 Oct 2009 09:16:30 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:16:28 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:16:28 -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 n9LGGQj38826; Wed, 21 Oct 2009 09:16:27 -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 n9LG3VNP062477; Wed, 21 Oct 2009 16:03:31 GMT (envelope-from phil@idle.juniper.net) Message-ID: <200910211603.n9LG3VNP062477@idle.juniper.net> To: Balazs Lengyel In-Reply-To: <4ADF3090.7090903@ericsson.com> Date: Wed, 21 Oct 2009 12:03:31 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Oct 2009 16:16:28.0831 (UTC) FILETIME=[D85A22F0:01CA5269] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf mailing list , netmod@ietf.org Subject: Re: [Netconf] [netmod] meaning of default X-BeenThere: netconf@ietf.org X-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, 21 Oct 2009 16:21:26 -0000 Balazs Lengyel writes: >I have the feeling that we should make with-defaults MANDATORY for all nodes using YANG. >(Currently report-all is the only mode that is mandatory to support in with-defaults.) >Opinions? I disagree. There's nothing in YANG that requires with-defaults. Thanks, Phil From andy@netconfcentral.com Wed Oct 21 09:47: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 27FF228C101 for ; Wed, 21 Oct 2009 09:47:23 -0700 (PDT) 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 Ap1fSc5Msf6P for ; Wed, 21 Oct 2009 09:47:23 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id EE7CC3A68CC for ; Wed, 21 Oct 2009 09:47:19 -0700 (PDT) Received: (qmail 73253 invoked from network); 21 Oct 2009 16:40:49 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@67.125.158.26 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 21 Oct 2009 16:40:49 -0000 X-YMail-OSG: .TwrpEYVM1n9OvV4CunFH4S2ZM0evyXA0BLhwM9KKExhQoNXlynLZTggzn9hwY3t7o8ayBq25zuAWcJgiZPRQFzsB88gtf3r6YS4U9SyURwR4y3JvY09EJhiC.FjJrQQtYX0a56JLFG8QTpkerhyPwqNlizzaBcHYYtoHj2QGVt_KpL5ajHThBEkzjpmWqsFZzVW06onu0aQz8_I6O271evxBVL6vm1TFbTtkHDjPRutY3l46z8aD33nlU6XHXx631EZIiGD278- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ADF39C5.7040100@netconfcentral.com> Date: Wed, 21 Oct 2009 09:41:41 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Balazs Lengyel References: <200909011930.n81JU7WS093379@idle.juniper.net> <4ADF3090.7090903@ericsson.com> In-Reply-To: <4ADF3090.7090903@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, netconf mailing list Subject: Re: [Netconf] [netmod] meaning of default X-BeenThere: netconf@ietf.org X-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, 21 Oct 2009 16:47:23 -0000 Balazs Lengyel wrote: > Hello, > I have the feeling that we should make with-defaults MANDATORY for all > nodes using YANG. > (Currently report-all is the only mode that is mandatory to support in > with-defaults.) > Opinions? I was thinking that, until Phil explained to us that a system-created node (not a YANG default) is an explicit node. Every defaults style MUST return s-c leafs. The leafs that can get left out are YANG defaults. Here are some open issues that impact the reliability of the meta-data the client needs to derive the proper defaults: I think MUST implement with-defaults is a more user-friendly solution than the following: * Agree that using revision statements is mandatory * Agree that the server MUST advertise all its modules in the * Agreed that import/include by revision SHOULD be used in vendor modules and MUST (+) be used in standard modules. + I am not convinced mandatory import-by-rev is a workable solution. I think it will lead to a rats-nest of version dependencies. Instead, YANG should specify that the most recent revision date supported by the server MUST be used if no revision-date is provided. E.g, A -> B -> C, but now A wants to import the new version of C, but also wants B to use the same version of C; otherwise typedefs/groupings in B are out-of-synch with those in A. If vendor(A) is not vendor(B), then updating B may be difficult or impossible. In the IETF, it will mean republishing RFCs just to change 1 import-stmt, which could turn into a boiler-plate/process nightmare. > Balazs Andy From bertietf@bwijnen.net Thu Oct 22 03:04: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 0ACCD3A688B; Thu, 22 Oct 2009 03:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.705 X-Spam-Level: X-Spam-Status: No, score=0.705 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_05=-1.11, 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 x-qbYkD2M2yz; Thu, 22 Oct 2009 03:04:42 -0700 (PDT) Received: from relay.versatel.net (relay56.tele2.vuurwerk.nl [62.250.3.56]) by core3.amsl.com (Postfix) with ESMTP id 8C3163A67E7; Thu, 22 Oct 2009 03:04:40 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1N0uXI-0001Dz-B3; Thu, 22 Oct 2009 12:04:48 +0200 Message-ID: <31F77FB0A0C44C79ABEFAE55E0971A74@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" , "Romascanu, Dan \(Dan\)" Date: Thu, 22 Oct 2009 12:03:57 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_057F_01CA530F.BC01CD50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Cc: IESG Subject: [Netconf] We're finished with the parial-lock document X-BeenThere: netconf@ietf.org X-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, 22 Oct 2009 10:04:43 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_057F_01CA530F.BC01CD50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable NETCONF WG participants and Dan, All DISCUSSes have now been cleared. The WG has in my view now WG CONSESUS on the latest small changes that were made to address the IESG DISCUSS comments. Revision 11 is the final version. I hereby ask our AD (Dan) to confirm and publish IESG approval and to get the document into the RFC-Editor queue. Thanks to all, Bert Wijnen document shepherd. p.s. I am now on vacation for a week ----- Original Message -----=20 From: Bert Wijnen (IETF)=20 To: netconf mailing list=20 Sent: Tuesday, October 20, 2009 7:58 PM Subject: [Netconf] We're done: Partial-lock-11 is the latest and = finalversion Dear Netconf WG participants, you have all seen the responses that Balazs made to the 5 ADs who held a DISCUSS. As a result, balzs did a new rev 11 to address=20 a small (in my view rather) editorial fix. The text was also in the response from Alexey. This coming Thursday, the IESG has a telechat. I would urge any WG participant who thinks that there are still issues = to=20 bring them up before Thursday 22nd of October (so today or Wednesday).=20 If we do not get any, then I hereby declare consensus and ask our AD to move the document into the RFC-Editor queue.=20 Thanks to Balazs and Martin! Bert Wijnen co-chair of NETCONF WG partial loack document shepherd. ----- Original Message -----=20 From: Balazs Lengyel=20 To: netconf mailing list=20 Sent: Tuesday, October 20, 2009 5:32 PM Subject: [Netconf] Partial-lock updates -10 and -11 Hello, The partial-lock draft was updated due to the IESG review. One major change: removal of the candidate and startup configurations = from the scope of the=20 partial-lock. All other changes are minor clarifications. Balazs -------------------------------------------------------------------------= ------- _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf -------------------------------------------------------------------------= ------- No virus found in this incoming message. Checked by AVG - www.avg.com=20 Version: 8.5.422 / Virus Database: 270.14.23/2448 - Release Date: = 10/20/09 10:43:00 -------------------------------------------------------------------------= ------- No virus found in this incoming message. Checked by AVG - www.avg.com=20 Version: 8.5.423 / Virus Database: 270.14.25/2450 - Release Date: = 10/21/09 16:44:00 ------=_NextPart_000_057F_01CA530F.BC01CD50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
NETCONF WG participants and Dan,
 
All DISCUSSes have now been = cleared.
The WG has in my view now WG CONSESUS on = the=20 latest
small changes that were made to address = the IESG=20 DISCUSS
comments. Revision 11 is the final = version.
 
I hereby ask our AD (Dan) to confirm and = publish=20 IESG approval
and to get the document into the = RFC-Editor=20 queue.
 
Thanks to all,
Bert Wijnen
document shepherd.
 
p.s. I am now on vacation for a = week
 
 
----- Original Message -----=20
From: Bert = Wijnen=20 (IETF)
Sent: Tuesday, October 20, 2009 7:58 PM
Subject: [Netconf] We're done: Partial-lock-11 is the latest = and=20 finalversion

Dear Netconf WG participants,
 
you have all seen the responses that Balazs made to = the 5=20 ADs
who held a DISCUSS. As a result, balzs did a = new rev 11=20 to address
a small (in my view rather) editorial fix. The text = was also=20 in the
response from Alexey.
 
This coming Thursday, the IESG has a = telechat.
I would urge any WG participant who thinks that = there are=20 still issues to
bring them up before Thursday 22nd of October (so = today or=20 Wednesday). 
 
If we do not get any, then I hereby declare = consensus and ask=20 our AD to
move the document into the RFC-Editor queue. =
 
Thanks to Balazs and Martin!
 
Bert Wijnen
co-chair of NETCONF WG
partial loack document shepherd.
 
----- Original Message -----
From:=20 Balazs Lengyel
Sent: Tuesday, October 20, 2009 = 5:32=20 PM
Subject: [Netconf] Partial-lock = updates=20 -10 and -11

Hello,
The partial-lock draft was updated = due to=20 the IESG review.

One major change: removal of the candidate and = startup=20 configurations from the scope of the
partial-lock.

All = other=20 changes are minor clarifications.

Balazs

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


No virus found in this incoming message.
Checked by AVG -=20 www.avg.com
Version: 8.5.422 / Virus Database: 270.14.23/2448 - = Release=20 Date: 10/20/09 10:43:00


No virus found in this incoming message.
Checked by AVG -=20 www.avg.com
Version: 8.5.423 / Virus Database: 270.14.25/2450 - = Release=20 Date: 10/21/09 16:44:00
------=_NextPart_000_057F_01CA530F.BC01CD50-- From balazs.lengyel@ericsson.com Thu Oct 22 03:25: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 EB67C3A68AB for ; Thu, 22 Oct 2009 03:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ye43zFl5h+Cq for ; Thu, 22 Oct 2009 03:25:50 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 6F7D43A6981 for ; Thu, 22 Oct 2009 03:25:50 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-e3-4ae0333665fe Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 6D.CC.24026.63330EA4; Thu, 22 Oct 2009 12:25:58 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 12:25:55 +0200 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 12:25:54 +0200 Message-ID: <4AE03331.6000201@ericsson.com> Date: Thu, 22 Oct 2009 12:25:53 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: Phil Shafer References: <200909251557.n8PFvhQB009338@idle.juniper.net> In-Reply-To: <200909251557.n8PFvhQB009338@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2009 10:25:54.0174 (UTC) FILETIME=[0921F1E0:01CA5302] X-Brightmail-Tracker: AAAAAA== Cc: "netconf@ietf.org" Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03 X-BeenThere: netconf@ietf.org X-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, 22 Oct 2009 10:25:52 -0000 Hello, A late comment. The cost of storage needed to store whether a leaf was set explicitly is usually cheap, BUT the cost of adapting an existing configuration datastore and configuration handling logic is EXPENSIVE. So if we would make explicit mandatory for Netconf would significantly raise adaptation costs for many existing devices. Balazs On 09/25/09 17:57, Phil Shafer wrote: > Andy Bierman writes: >> It is wrong to assume >> that NV-storage of 1 XML file is somehow a burden for >> every platform running NETCONF. > > Well, it's wrong to assume that a platform running NETCONF uses XML > for anything more than parsing content off the wire. The JUNOS > config database is not XML, nor are our NV-storage contents. > > Also the storage needs for "explicit" or "trim" are not similar to > "report-all". For example, the JUNOS list element for static routes > has nearly 75 leafs under it, of which 2-3 are typically set. > Assuming they all have default (which they don't, but...), the > customer that loads 50,000 static routes has a impact (with 32 bytes > overhead per list instance plus, say, 12 bytes per leaf instance) > of 2.8M for explicit and 46.6M for report-all. > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com From root@core3.amsl.com Thu Oct 22 10:00: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 87DB23A6995; Thu, 22 Oct 2009 10:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091022170001.87DB23A6995@core3.amsl.com> Date: Thu, 22 Oct 2009 10:00:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-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, 22 Oct 2009 17:00: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 : With-defaults capability for NETCONF Author(s) : A. Bierman, B. Lengyel Filename : draft-ietf-netconf-with-defaults-04.txt Pages : 15 Date : 2009-10-22 The NETCONF protocol defines ways to read configuration data from a NETCONF server. Part of this data is not set by the NETCONF client, but rather a default value is used. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to send it to the client. In other situations the NETCONF client will need this data as part of the NETCONF messages. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to control whether default values are part of NETCONF messages or output to the target URL. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-with-defaults-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-with-defaults-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-22095922.I-D@ietf.org> --NextPart-- From balazs.lengyel@ericsson.com Thu Oct 22 10:02:06 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 EDF483A6959 for ; Thu, 22 Oct 2009 10:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvEy71YCHNaM for ; Thu, 22 Oct 2009 10:02:06 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id CE8E43A68A0 for ; Thu, 22 Oct 2009 10:02:05 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-44-4ae090162b1a Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 7C.E8.04191.61090EA4; Thu, 22 Oct 2009 19:02:14 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 19:02:14 +0200 Received: from [159.107.230.170] ([159.107.230.170]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 19:02:13 +0200 Message-ID: <4AE09015.8090201@ericsson.com> Date: Thu, 22 Oct 2009 19:02:13 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-DK; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: netconf mailing list Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2009 17:02:13.0955 (UTC) FILETIME=[66FC9130:01CA5339] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Fwd: New Version Notification for draft-ietf-netconf-with-defaults-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: Thu, 22 Oct 2009 17:02:07 -0000 Hello, Main change is an update to the definition of default. The updates include adding other management interfaces eg. CLI, SNMP in the definitions. Balazs -------- Original Message -------- Subject: New Version Notification for draft-ietf-netconf-with-defaults-04 Date: Thu, 22 Oct 2009 09:59:22 -0700 (PDT) From: IETF I-D Submission Tool To: balazs.lengyel@ericsson.com CC: andy@netconfcentral.com A new version of I-D, draft-ietf-netconf-with-defaults-04.txt has been successfuly submitted by Balazs Lengyel and posted to the IETF repository. Filename: draft-ietf-netconf-with-defaults Revision: 04 Title: With-defaults capability for NETCONF Creation_date: 2009-10-22 WG ID: netconf Number_of_pages: 15 Abstract: The NETCONF protocol defines ways to read configuration data from a NETCONF server. Part of this data is not set by the NETCONF client, but rather a default value is used. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to send it to the client. In other situations the NETCONF client will need this data as part of the NETCONF messages. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to control whether default values are part of NETCONF messages or output to the target URL. The IETF Secretariat. From wwwrun@core3.amsl.com Mon Oct 26 08:45:54 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 0122D28C293; Mon, 26 Oct 2009 08:45:53 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20091026154554.0122D28C293@core3.amsl.com> Date: Mon, 26 Oct 2009 08:45:53 -0700 (PDT) Cc: Internet Architecture Board , netconf mailing list , netconf chair , RFC Editor Subject: [Netconf] Protocol Action: 'Partial Lock RPC for NETCONF' 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: Mon, 26 Oct 2009 15:45:54 -0000 The IESG has approved the following document: - 'Partial Lock RPC for NETCONF ' 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-partial-lock-11.txt Technical Summary 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 The working group went over several versions of the 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 preliminary implementations of this protocol and updates to comply with this spec are in plan. Others are planning to implement this spec too. Personnel Bert Wijnen is the document shepherd, Dan Romascanu is the shepherding AD. From dromasca@avaya.com Mon Oct 26 08:56: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 DD8F228C279 for ; Mon, 26 Oct 2009 08:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N42CNTVk2RLD for ; Mon, 26 Oct 2009 08:56:56 -0700 (PDT) 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 13E7528C112 for ; Mon, 26 Oct 2009 08:56:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,626,1249272000"; d="scan'208";a="178193226" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 26 Oct 2009 11:57:08 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 26 Oct 2009 11:57:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 16:57:04 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Protocol Action: 'Partial Lock RPC for NETCONF' toProposed Standard Thread-Index: AcpWU+dWXe8Uwue4TPKHORZAD0NwEwAAPxYw From: "Romascanu, Dan (Dan)" To: "netconf mailing list" Subject: [Netconf] FW: Protocol Action: 'Partial Lock RPC for NETCONF' toProposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:56:57 -0000 Congratulations to the editors, chairs, and the whole WG for achieving this milestone.=20 Regards, Dan -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of The IESG Sent: Monday, October 26, 2009 5:46 PM To: IETF-Announce Cc: Internet Architecture Board; netconf mailing list; netconf chair; RFC Editor Subject: [Netconf] Protocol Action: 'Partial Lock RPC for NETCONF' toProposed Standard The IESG has approved the following document: - 'Partial Lock RPC for NETCONF ' 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-partial-lock-11.t xt Technical Summary 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 The working group went over several versions of the 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 preliminary implementations of this protocol and updates to comply with this spec are in plan. Others are planning to implement this spec too. Personnel Bert Wijnen is the document shepherd, Dan Romascanu is the shepherding AD. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From mehmet.ersue@nsn.com Mon Oct 26 10:00:04 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 CC0B428C2EA for ; Mon, 26 Oct 2009 10:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id calh1s5fvs8V for ; Mon, 26 Oct 2009 10:00:03 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 526D428C2A2 for ; Mon, 26 Oct 2009 10:00:03 -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 n9QH09F9020310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Oct 2009 18:00:09 +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 n9QH08XR019868; Mon, 26 Oct 2009 18:00:09 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 18:00:08 +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, 26 Oct 2009 18:00:07 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640A9332@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: Protocol Action: 'Partial Lock RPC for NETCONF'toProposed Standard Thread-Index: AcpWU+dWXe8Uwue4TPKHORZAD0NwEwAAPxYwAAIk0rA= References: From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Romascanu, Dan (Dan)" , "netconf mailing list" X-OriginalArrivalTime: 26 Oct 2009 17:00:08.0601 (UTC) FILETIME=[C5EC1090:01CA565D] Subject: Re: [Netconf] FW: Protocol Action: 'Partial Lock RPC for NETCONF'toProposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 17:00:04 -0000 Congratulations!!=20 (also on behalf of Bert, who is in vacation). Cheers, Mehmet =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Romascanu,=20 > Dan (Dan) > Sent: Monday, October 26, 2009 4:57 PM > To: netconf mailing list > Subject: [Netconf] FW: Protocol Action: 'Partial Lock RPC for=20 > NETCONF'toProposed Standard >=20 >=20 > Congratulations to the editors, chairs, and the whole WG for=20 > achieving > this milestone.=20 >=20 > Regards, >=20 > Dan >=20 >=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of The IESG > Sent: Monday, October 26, 2009 5:46 PM > To: IETF-Announce > Cc: Internet Architecture Board; netconf mailing list; netconf chair; > RFC Editor > Subject: [Netconf] Protocol Action: 'Partial Lock RPC for NETCONF' > toProposed Standard >=20 > The IESG has approved the following document: >=20 > - 'Partial Lock RPC for NETCONF ' > as a Proposed Standard >=20 >=20 > This document is the product of the Network Configuration=20 > Working Group. >=20 >=20 > The IESG contact persons are Dan Romascanu and Ron Bonica. >=20 > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-partial > -lock-11.t > xt >=20 > Technical Summary >=20 > The NETCONF protocol defines the lock and unlock RPCs, used to lock > entire configuration datastores. In some situations, a way to=20 > lock only > parts of a configuration datastore is required. This document=20 > defines a > capability-based extension to the NETCONF protocol for=20 > locking portions > of a configuration datastore. >=20 > Working Group Summary >=20 > The working group went over several versions of the document. The > comments and reviews helped improve the document a lot and=20 > brought us to > consensus on the 7th revision of the docuemnt. >=20 > Document Quality >=20 > There are preliminary implementations of this protocol and updates to > comply with this spec are in plan. Others are planning to=20 > implement this > spec too. >=20 > Personnel >=20 > Bert Wijnen is the document shepherd, Dan Romascanu is the shepherding > AD. >=20 > _______________________________________________ > 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 >=20 From dbharrington@comcast.net Thu Oct 29 14:16:22 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 4360E3A6A6B for ; Thu, 29 Oct 2009 14:16:22 -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 QDyCQWk7ls6A for ; Thu, 29 Oct 2009 14:16:21 -0700 (PDT) Received: from QMTA14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by core3.amsl.com (Postfix) with ESMTP id 4081D3A6A6A for ; Thu, 29 Oct 2009 14:16:21 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA14.westchester.pa.mail.comcast.net with comcast id ybfL1c0040QuhwU5ElGe43; Thu, 29 Oct 2009 21:16:38 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA02.westchester.pa.mail.comcast.net with comcast id ylGe1c006284sdk3NlGeeN; Thu, 29 Oct 2009 21:16:38 +0000 From: "David B Harrington" To: References: <20091026154554.0122D28C293@core3.amsl.com> Date: Thu, 29 Oct 2009 17:16:37 -0400 Message-ID: <0d7f01ca58dd$19a7bb40$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20091026154554.0122D28C293@core3.amsl.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcpWU7rQMKIdozDwT4Gkps2PITpLGACiUfxA Subject: Re: [Netconf] Protocol Action: 'Partial Lock RPC for NETCONF' toProposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 21:16:22 -0000 Congratulations dbh > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of The IESG > Sent: Monday, October 26, 2009 11:46 AM > To: IETF-Announce > Cc: Internet Architecture Board; netconf mailing list; > netconf chair; RFC Editor > Subject: [Netconf] Protocol Action: 'Partial Lock RPC for > NETCONF' toProposed Standard > > The IESG has approved the following document: > > - 'Partial Lock RPC for NETCONF ' > 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-partial > -lock-11.txt > > Technical Summary > > 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 > > The working group went over several versions of the > 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 preliminary implementations of this protocol > and updates to comply with this spec are in plan. Others > are planning to implement this spec too. > > Personnel > > Bert Wijnen is the document shepherd, Dan Romascanu is the shepherding > AD. > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From mehmet.ersue@nsn.com Fri Oct 30 08:10: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 5029B3A697D for ; Fri, 30 Oct 2009 08:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZX2oPXAoeP5 for ; Fri, 30 Oct 2009 08:10:58 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 99C9A3A6969 for ; Fri, 30 Oct 2009 08:10:57 -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 n9UFBB2r030626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Oct 2009 16:11:11 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9UFBAhr006964; Fri, 30 Oct 2009 16:11:10 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 16:10:53 +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: Fri, 30 Oct 2009 16:10:51 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640E0B05@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64031460@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WGLC for draft-ietf-netconf-monitoring-09 Thread-Index: AcpM8tHJxxCBJN7QSL2T+SkMdEFmTwAABoPAASNfCEAB/DAFYA== References: <085091CB2CA14E4B8B163FFC37C84E9D1A9F69CD@zcarhxm0.corp.nortel.com> <80A0822C5E9A4440A5117C2F4CD36A64031460@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 30 Oct 2009 15:10:53.0042 (UTC) FILETIME=[2C282520:01CA5973] Subject: Re: [Netconf] WGLC for draft-ietf-netconf-monitoring-09 X-BeenThere: netconf@ietf.org X-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, 30 Oct 2009 15:10:59 -0000 Hi All, this is a friendly reminder for the WGLC of the=20 draft "NETCONF monitoring draft", which runs=20 until November 2. I would like to ask all to give the monitoring=20 draft a chance and send your comments to the=20 NETCONF maillist. We are planning to bring the draft in the NETCONF=20 session at IETF 76 to the next stage. So, please=20 help to get it stable. Thank you. Mehmet =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue,=20 > Mehmet (NSN - DE/Munich) > Sent: Tuesday, October 20, 2009 2:36 PM > To: netconf@ietf.org > Subject: [Netconf] WGLC for draft-ietf-netconf-monitoring-09 >=20 >=20 > Dear NETCONF WG,=20 >=20 > we had a good discussion on the NETCONF monitoring=20 > draft since the last WGLC in July.=20 >=20 > The draft Mark and Martin submitted solves the issues=20 > raised on the maillist and introduces the YANG model=20 > as normative. The new version of the draft appears to=20 > be stable for a final WGLC before we go one step further.=20 >=20 > With this mail we start a new WGLC for the NETCONF=20 > monitoring draft, which is planned to publish as a=20 > Proposed Standard RFC. The WGLC will run until=20 > November 2, 2009.=20 >=20 >=20 > All WG members PLEASE REVIEW the draft again and send=20 > your comments to the NETCONF maillist: >=20 > http://tools.ietf.org/html/draft-ietf-netconf-monitoring-09 >=20 > Thank you.=20 >=20 > Mehmet > =20 >=20 > > -----Original Message----- > > From: netconf-bounces@ietf.org=20 > > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Mark Scott > > Sent: Wednesday, October 14, 2009 7:47 PM > > To: netconf@ietf.org > > Subject: [Netconf] FW: New Version Notification=20 > > fordraft-ietf-netconf-monitoring-09 > >=20 > > Hello, > >=20 > > A new version (v9) of the NETCONF Monitoring Schema draft has=20 > > been posted. > >=20 > > This version addresses mailing list comments received on v8: > > - reversion of 'session-type' to 'transport' > > - element naming consistency. All lowerCamelCase names have=20 > > been converted to 'hyphen-delimited' or=20 > > 'netconf-style-naming' as it is sometimes referred to on the=20 > > ML. E.g. 'sessionType' -> 'session-type'. This change=20 > > impacts both the draft text and yang module. =20 > > - operation updated: > > - now has only one mandatory parameter, 'identifier' > > - updated negative responses, including the rpc=20 > > operation description in yang module > > - comments added to the yang module indicating that the=20 > > definition of 'session-id' is consistent with 4741bis=20 > > 'session-id-type' and could be imported from that pending=20 > > RFC. Similar for 'netconf-datastore-type'. This was in=20 > > favour of adding further dependencies and delays by waiting=20 > > for 4741bis to complete. > > =20 > > Please direct any comments on this version to the mailing list. > >=20 > > cheers, > > Mark > >=20 > >=20 > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 > > Sent: Wednesday, October 14, 2009 1:22 PM > > To: Scott, Mark (CAR:2N00) > > Cc: mbj@tail-f.com > > Subject: New Version Notification for=20 > > draft-ietf-netconf-monitoring-09=20 > >=20 > >=20 > > A new version of I-D, draft-ietf-netconf-monitoring-09.txt=20 > > has been successfuly submitted by Mark Scott and posted to=20 > > the IETF repository. > >=20 > > Filename: draft-ietf-netconf-monitoring > > Revision: 09 > > Title: NETCONF Monitoring Schema > > Creation_date: 2009-10-14 > > WG ID: netconf > > Number_of_pages: 30 > >=20 > > Abstract: > > This document defines a NETCONF data model to be used to monitor the > > NETCONF protocol. The monitoring data model includes information > > about NETCONF datastores, sessions, locks and statistics. This data > > facilitates the management of a NETCONF server. This document also > > defines methods for NETCONF clients to discover data models=20 > supported > > by a NETCONF server and defines a new NETCONF operation > > to retrieve them. > > =20 > > =20 > >=20 > >=20 > > The IETF Secretariat. > >=20 > >=20 > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From mehmet.ersue@nsn.com Fri Oct 30 08:25: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 327D83A6768 for ; Fri, 30 Oct 2009 08:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsQrHE0uyT4K for ; Fri, 30 Oct 2009 08:25:13 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 056BB3A692D for ; Fri, 30 Oct 2009 08:25:12 -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 n9UFP1ZH024209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Oct 2009 16:25:01 +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 n9UFP1n9017504; Fri, 30 Oct 2009 16:25:01 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 16:25:01 +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_01CA5975.255D5560" Date: Fri, 30 Oct 2009 16:24:59 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640E0B0A@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Webex setup for the IETF76 NETCONF WG Session Thread-Index: AcpZdSTn/SB4WLc+Tv6rovhZ8CwMhA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 30 Oct 2009 15:25:01.0212 (UTC) FILETIME=[25B49DC0:01CA5975] Cc: ext Alexa Morris Subject: [Netconf] Webex setup for the IETF76 NETCONF WG 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, 30 Oct 2009 15:25:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5975.255D5560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, IETF secretary kindly organized a Webex setup for remote=20 attendance in the IETF76 NETCONF WG session. The NETCONF WG session is on Monday, November 9, 2009=20 at 15:20 - 17:20 UTC/GMT +9 hours (=3D=3D 07:20-09:20 CET or=20 23:20 - 01:20 PT). Webex and conference access information will be sent out to=20 the NETCONF maillist early enough before the NETCONF session. Cheers, Mehmet ------_=_NextPart_001_01CA5975.255D5560 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Webex setup for the IETF76 NETCONF WG Session

Dear NETCONF WG,

IETF secretary kindly organized a = Webex setup for remote
attendance in the IETF76 NETCONF WG = session.

The NETCONF WG session is on Monday, = November 9, 2009
at 15:20 - 17:20 UTC/GMT +9 hours = (=3D=3D 07:20-09:20 CET or
23:20 - 01:20 PT).

Webex and conference access = information will be sent out to
the NETCONF maillist early enough = before the NETCONF session.

Cheers,
Mehmet

------_=_NextPart_001_01CA5975.255D5560-- From bertietf@bwijnen.net Fri Oct 30 14:44: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 093D43A6916 for ; Fri, 30 Oct 2009 14:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.885 X-Spam-Level: X-Spam-Status: No, score=-8.885 tagged_above=-999 required=5 tests=[AWL=1.714, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lp+frg2ka9Gw for ; Fri, 30 Oct 2009 14:44:24 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id CDD053A68E7 for ; Fri, 30 Oct 2009 14:44:23 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1N3zGp-0005dH-DQ; Fri, 30 Oct 2009 22:44:36 +0100 Received: from BWMACBOOK.local (dog.ripe.net [193.0.1.217]) by herring.ripe.net (Postfix) with ESMTP id 3E8852F583; Fri, 30 Oct 2009 22:44:31 +0100 (CET) Message-ID: <4AEB5E3F.6010602@bwijnen.net> Date: Fri, 30 Oct 2009 22:44:31 +0100 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <80A0822C5E9A4440A5117C2F4CD36A640A9332@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640A9332@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd45ba0b36a0501eb2c49a53fbbc40e5595 Cc: netconf mailing list Subject: Re: [Netconf] FW: Protocol Action: 'Partial Lock RPC for NETCONF'toProposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 21:44:25 -0000 Indeed Congrats to all. For me... it feels like a nice birth-day present (26th was my birthday). But I am much more happy for the ditors/authors and the WG to see \that we have another del Bert... just back from a relaxing vacation without email. Ersue, Mehmet (NSN - DE/Munich) wrote: > Congratulations!! > (also on behalf of Bert, who is in vacation). > > Cheers, > Mehmet > > > >> -----Original Message----- >> From: netconf-bounces@ietf.org >> [mailto:netconf-bounces@ietf.org] On Behalf Of ext Romascanu, >> Dan (Dan) >> Sent: Monday, October 26, 2009 4:57 PM >> To: netconf mailing list >> Subject: [Netconf] FW: Protocol Action: 'Partial Lock RPC for >> NETCONF'toProposed Standard >> >> >> Congratulations to the editors, chairs, and the whole WG for >> achieving >> this milestone. >> >> Regards, >> >> Dan >> >> >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >> Behalf Of The IESG >> Sent: Monday, October 26, 2009 5:46 PM >> To: IETF-Announce >> Cc: Internet Architecture Board; netconf mailing list; netconf chair; >> RFC Editor >> Subject: [Netconf] Protocol Action: 'Partial Lock RPC for NETCONF' >> toProposed Standard >> >> The IESG has approved the following document: >> >> - 'Partial Lock RPC for NETCONF ' >> 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-partial >> -lock-11.t >> xt >> >> Technical Summary >> >> 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 >> >> The working group went over several versions of the 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 preliminary implementations of this protocol and updates to >> comply with this spec are in plan. Others are planning to >> implement this >> spec too. >> >> Personnel >> >> Bert Wijnen is the document shepherd, Dan Romascanu is the shepherding >> AD. >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > >