From mehmet.ersue@nsn.com Tue Jun 1 01:49:47 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C2243A6925 for ; Tue, 1 Jun 2010 01:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, 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 wL56OpRsr+jd for ; Tue, 1 Jun 2010 01:49:46 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id E5C533A68C0 for ; Tue, 1 Jun 2010 01:49:45 -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 o518nNx8006366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Jun 2010 10:49:24 +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 o518nNF9006035; Tue, 1 Jun 2010 10:49:23 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Jun 2010 10:49:22 +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, 1 Jun 2010 10:49:22 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A648E48D8@DEMUEXC006.nsn-intra.net> In-Reply-To: <20100531.203427.218922716.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: I-D Action:draft-ietf-netconf-monitoring-13.txt Thread-Index: AcsA8FTqrqlRhM8lR0204Kp2u1ZjLAAda6BQ References: <4BFD6273.6050304@iwl.com><4C03E8C0.2010401@iwl.com> <20100531.203427.218922716.mbj@tail-f.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Martin Bjorklund" , "ext Mark Scott" , "ext Romascanu, Dan (Dan)" X-OriginalArrivalTime: 01 Jun 2010 08:49:22.0783 (UTC) FILETIME=[54E64EF0:01CB0167] Cc: netconf@ietf.org Subject: Re: [Netconf] FW: I-D Action:draft-ietf-netconf-monitoring-13.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, 01 Jun 2010 08:49:47 -0000 Hi All, IIRC we agreed in the past not to be dependent on 4741bis and I=20 also believe it makes sense that other documents (like 4741bis) don't=20 have to import basic netconf-types from monitoring doc.=20 4741bis or an other document can define a generic (to be imported=20 by other modules) set of netconf-types. If we then do a monitoring-bis=20 later this can be imported. I would suggest to use uint32 in the monitoring draft and NOT to=20 define a specific type. As I see on ML there seems to be already an agreement on this.=20 So, I would like to ask the editors to make this very last change and=20 to submit a final revision. Mehmet (document shepherd) > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Martin Bjorklund > Sent: Monday, May 31, 2010 8:34 PM > To: andyb@iwl.com > Cc: netconf@ietf.org > Subject: Re: [Netconf] FW: I-D=20 > Action:draft-ietf-netconf-monitoring-13.txt >=20 > Andy Bierman wrote: > > Romascanu, Dan (Dan) wrote: > > > =20 > > > > > > =20 > > >> -----Original Message----- > > >> From: netconf-bounces@ietf.org=20 > > >> [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > > >> =20 > > > > > > =20 > > >> I prefer to have all the common NETCONF typedefs in the=20 > > >> draft-ietf-netmod-types draft. (e.g., session-id,=20 > datastore-type). > > >> That is the correct engineering solution. That would also=20 > > >> get published before 4741bis, so ietf-netconf and=20 > > >> ietf-netconf-monitoring can import from a module in this draft. > > >> > > >> =20 > > > > > > This looks cleaner and can be done in theory right now=20 > with the cost of > > > delaying draft-ietf-netmod-types which hangs on the=20 > clearing of a last > > > DISCUSS before being approved by the IESG. However I am=20 > wondering if > > > this is not a futile effort. This will not be the last=20 > typedef that will > > > be needed, and in the future we shall not update each=20 > time that RFC when > > > we need to add one or a few new typedefs. Or shall we?=20 > > > =20 > >=20 > > Another solution is to not use any typedef > > in ietf-netconf-monitoring. Just use uint32 > > instead. >=20 > I think this is a reasonable way forward. We should remove the two > session-id types from monitoring, and just use unit32. >=20 > > IMO, we should add > > the ietf-netconf-types module to 4741bis now, and start > > with the session-id-type in ietf-netconf.yang. >=20 > Why can't we just define those types in ietf-netconf? Why do we need > a separate module for the types? Do you expect that module to be > revised more often than ietf-netconf? >=20 >=20 > /martin >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From ietfc@btconnect.com Tue Jun 1 02:42:15 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B96E3A6767 for ; Tue, 1 Jun 2010 02:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=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 mjjz3LASUoWi for ; Tue, 1 Jun 2010 02:42:13 -0700 (PDT) Received: from c2bthomr13.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by core3.amsl.com (Postfix) with ESMTP id 998DA3A6983 for ; Tue, 1 Jun 2010 02:42:12 -0700 (PDT) Received: from pc6 (host86-172-78-59.range86-172.btcentralplus.com [86.172.78.59]) by c2bthomr13.btconnect.com with SMTP id FIX56684; Tue, 1 Jun 2010 10:41:48 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4C04D5DB.025E, actions=tag Message-ID: <011001cb0165$d77cdc00$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Romascanu, Dan \(Dan\)" , , "Martin Bjorklund" References: <75C89D709A9670428520E1CF8DD1344F208D0F317B@EUSAACMS0714.eamcs.ericsson.se> <4BFD57EA.8010103@iwl.com><20100526.192936.236301148.mbj@tail-f.com><4BFD6273.6050304@iwl.com> Date: Tue, 1 Jun 2010 10:15:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B020A.4C04D5E4.01F1,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: netconf@ietf.org Subject: Re: [Netconf] FW: I-D Action:draft-ietf-netconf-monitoring-13.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, 01 Jun 2010 09:42:15 -0000 ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: ; "Martin Bjorklund" Cc: Sent: Monday, May 31, 2010 6:32 PM > > > -----Original Message----- > > From: netconf-bounces@ietf.org > > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > > > I prefer to have all the common NETCONF typedefs in the > > draft-ietf-netmod-types draft. (e.g., session-id, datastore-type). > > That is the correct engineering solution. That would also > > get published before 4741bis, so ietf-netconf and > > ietf-netconf-monitoring can import from a module in this draft. > > > > This looks cleaner and can be done in theory right now with the cost of > delaying draft-ietf-netmod-types which hangs on the clearing of a last > DISCUSS before being approved by the IESG. However I am wondering if > this is not a futile effort. This will not be the last typedef that will > be needed, and in the future we shall not update each time that RFC when > we need to add one or a few new typedefs. Or shall we? Or do as we did with Another Language and place such definitions under IANA control and use Standards Track RFC to amend the IANA definitions Tom Petch > Dan > (speaking as a contributor) From mbj@tail-f.com Tue Jun 1 02:43:54 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C357A3A6959 for ; Tue, 1 Jun 2010 02:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[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 curjh2smzO50 for ; Tue, 1 Jun 2010 02:43:54 -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 F120E3A695E for ; Tue, 1 Jun 2010 02:43:53 -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 0CCEF616002; Tue, 1 Jun 2010 11:43:41 +0200 (CEST) Date: Tue, 01 Jun 2010 11:43:40 +0200 (CEST) Message-Id: <20100601.114340.14799594.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4C03F03D.9070709@iwl.com> References: <4C03F03D.9070709@iwl.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] role of object description-stmt X-BeenThere: netconf@ietf.org X-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, 01 Jun 2010 09:43:55 -0000 Andy Bierman wrote: > So what to put in the description-stmts? When we discussed this last time, I think we said that we should do as for MIBs. YANG modules will, just like MIBs, be extracted from the RFCs and distributed by themselves, so it makes sense to make the modules as self-contained as possible. One extreme is netmod-types. All normative text is specified in description statements. This works just fine for a module with typedefs only. In netconf-monitoring, the text provides a higher level summary of the structure and descriptions in the YANG module. ipfix does something similar; they describe the structure with ascii-art UML diagrams. In general, I think this is a good approach. However, due to 4741 legacy, I agree that ietf-netconf.yang is special. /martin From andyb@iwl.com Tue Jun 1 09:05:35 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327DD3A689E for ; Tue, 1 Jun 2010 09:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.571 X-Spam-Level: X-Spam-Status: No, score=0.571 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_50=0.001, 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 sfcYD4HLN9lh for ; Tue, 1 Jun 2010 09:05:34 -0700 (PDT) Received: from smtp154.dfw.emailsrvr.com (smtp154.dfw.emailsrvr.com [67.192.241.154]) by core3.amsl.com (Postfix) with ESMTP id 67B9E3A6781 for ; Tue, 1 Jun 2010 09:05:34 -0700 (PDT) Received: from relay15.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay15.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 3B03730B0386; Tue, 1 Jun 2010 12:05:21 -0400 (EDT) Received: by relay15.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 6DF9C30B02AA; Tue, 1 Jun 2010 12:05:21 -0400 (EDT) Message-ID: <4C052FC2.3090706@iwl.com> Date: Tue, 01 Jun 2010 09:05:22 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Martin Bjorklund References: <4C03F03D.9070709@iwl.com> <20100601.114340.14799594.mbj@tail-f.com> In-Reply-To: <20100601.114340.14799594.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] role of object description-stmt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 16:05:35 -0000 On 06/01/2010 02:43 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > >> So what to put in the description-stmts? >> > When we discussed this last time, I think we said that we should do as > for MIBs. YANG modules will, just like MIBs, be extracted from the > RFCs and distributed by themselves, so it makes sense to make the > modules as self-contained as possible. > > One extreme is netmod-types. All normative text is specified in > description statements. This works just fine for a module with > typedefs only. In netconf-monitoring, the text provides a higher > level summary of the structure and descriptions in the YANG module. > ipfix does something similar; they describe the structure with > ascii-art UML diagrams. In general, I think this is a good approach. > > However, due to 4741 legacy, I agree that ietf-netconf.yang is > special. > It isn't that special wrt/ IETF process. A MIB module that instruments an IETF protocol is usually in a separate document. If not, the normative text for the protocol is not in the MIB DESCRIPTION clauses. The same will be true for YANG modules. A 'stand-alone' module like ietf-netconf-monitoring is more likely to be the corner-case in the IETF. The description-stmt is needed as a label that can be translated into different languages. (just making sure -- everywhere that YANG allows a description-stmt, a reference-stmt is also allowed? IMO we should use reference-stmt instead of replicating any text outside the YANG module.) > > /martin > > > Andy From root@core3.amsl.com Tue Jun 1 09:45:03 2010 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EE44F3A68C7; Tue, 1 Jun 2010 09:45: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: <20100601164502.EE44F3A68C7@core3.amsl.com> Date: Tue, 1 Jun 2010 09:45:02 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-14.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 16:45:04 -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 : YANG Module for NETCONF Monitoring Author(s) : M. Scott, M. Bjorklund Filename : draft-ietf-netconf-monitoring-14.txt Pages : 40 Date : 2010-06-01 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-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-monitoring-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-01094119.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Jun 1 10:30:10 2010 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7510D3A6995; Tue, 1 Jun 2010 10:30:06 -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: <20100601173009.7510D3A6995@core3.amsl.com> Date: Tue, 1 Jun 2010 10:30:06 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-01.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, 01 Jun 2010 17:30:10 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Using the NETCONF Configuration Protocol over Secure Shell (SSH) Author(s) : M. Wasserman, T. Goddard Filename : draft-ietf-netconf-rfc4742bis-01.txt Pages : 10 Date : 2010-06-01 This document describes a method for invoking and running the NETCONF protocol within a Secure Shell (SSH) session as an SSH subsystem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-rfc4742bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-rfc4742bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-01102656.I-D@ietf.org> --NextPart-- From mrw@lilacglade.org Tue Jun 1 10:35:52 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66D5828C1AD for ; Tue, 1 Jun 2010 10:35:52 -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 MMc0XfLXOWhC for ; Tue, 1 Jun 2010 10:35:52 -0700 (PDT) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id A93993A699C for ; Tue, 1 Jun 2010 10:35:39 -0700 (PDT) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta06.emeryville.ca.mail.comcast.net with comcast id QdcC1e0061bwxycA6hbTYU; Tue, 01 Jun 2010 17:35:27 +0000 Received: from [192.168.0.2] ([174.31.91.30]) by omta18.emeryville.ca.mail.comcast.net with comcast id QhbB1e0030fHozS8ehbLAo; Tue, 01 Jun 2010 17:35:25 +0000 Message-Id: From: Margaret Wasserman To: Netconf In-Reply-To: <20100601173009.7510D3A6995@core3.amsl.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 1 Jun 2010 10:35:10 -0700 References: <20100601173009.7510D3A6995@core3.amsl.com> X-Mailer: Apple Mail (2.936) Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-01.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, 01 Jun 2010 17:35:52 -0000 FYI -- I believe this version contains all of the changes that we have agreed to make to rfc4742-bis. Martin and Juergen, you raised most of the issues with the -00 version -- could you check to make sure that you are satisfied with the changes I've made to address them? If I didn't miss anything, I think this document should be ready for last call. Margaret On Jun 1, 2010, at 10:30 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Network Configuration Working Group > of the IETF. > > > Title : Using the NETCONF Configuration Protocol over > Secure Shell (SSH) > Author(s) : M. Wasserman, T. Goddard > Filename : draft-ietf-netconf-rfc4742bis-01.txt > Pages : 10 > Date : 2010-06-01 > > This document describes a method for invoking and running the NETCONF > protocol within a Secure Shell (SSH) session as an SSH subsystem. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-rfc4742bis-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From mbj@tail-f.com Wed Jun 2 01:11:39 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A96453A6968 for ; Wed, 2 Jun 2010 01:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[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 vDsuz7nQftTw for ; Wed, 2 Jun 2010 01:11:38 -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 4D44E3A6971 for ; Wed, 2 Jun 2010 01:11:37 -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 B9E3A616002; Wed, 2 Jun 2010 10:11:23 +0200 (CEST) Date: Wed, 02 Jun 2010 10:11:23 +0200 (CEST) Message-Id: <20100602.101123.205647377.mbj@tail-f.com> To: mrw@lilacglade.org From: Martin Bjorklund In-Reply-To: References: <20100601173009.7510D3A6995@core3.amsl.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-01.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, 02 Jun 2010 08:11:39 -0000 Hi Margaret, Margaret Wasserman wrote: > I believe this version contains all of the changes that we have agreed > to make to rfc4742-bis. Martin and Juergen, you raised most of the > issues with the -00 version -- could you check to make sure that you > are satisfied with the changes I've made to address them? Most issues are fixed, but I think the change to NETCONF operation was applied in cases where it shouldn't have been. My original point was that the previous version used different terms for the same thing, "operation", "command", "RPC message" etc. We should use one term, "operation", or "NETCONF operation" as you did. But the term operation refers to specific rpcs, e.g. edit-config, close-session etc. When we refer to the layer below operations, we use the term "message" (or "NETCONF message"). The new reference figure we agreed on after long debates will be included in 4741bis: Layer Example +-------------+ +-----------------+ +----------------+ (4) | Content | | Configuration | | Notification | | | | data | | data | +-------------+ +-----------------+ +----------------+ | | | +-------------+ +-----------------+ | (3) | Operations | | | | | | | | | +-------------+ +-----------------+ | | | | +-------------+ +-----------------+ +----------------+ (2) | Messages | | , | | | | | | | | | +-------------+ +-----------------+ +----------------+ | | | +-------------+ +-----------------------------------------+ (1) | Secure | | SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... | | Transports | | | +-------------+ +-----------------------------------------+ As Juergen pointed out, since this is a transport document, it should in most cases just refer to the layer above, i.e. "messages". In some cases, e.g. in section 5 where you refer to close-session, you need to use the term operation. So, each occurance of "operation" needs to be looked at, and either simply changed to "message", or, in some cases, rewrite the sentence. An example of the latter is from 3.1: OLD: The following example shows a capability exchange. Operations sent by the NETCONF client are marked with "C:" and operations sent by the NETCONF server are marked with "S:". NEW: The following example shows a capability exchange. Data sent by the NETCONF client are marked with "C:" and data sent by the NETCONF server are marked with "S:". ---------- Another issue is from section 5, on close-session: the NETCONF server shall respond and close the SSH session channel. s/shall/SHALL/ (or MUST) /martin From mbj@tail-f.com Wed Jun 2 02:45:17 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E56728C162 for ; Wed, 2 Jun 2010 02:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.854 X-Spam-Level: X-Spam-Status: No, score=0.854 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcgyMYNi-1lm for ; Wed, 2 Jun 2010 02:45:14 -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 D189628C123 for ; Wed, 2 Jun 2010 02:45:12 -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 65452616002 for ; Wed, 2 Jun 2010 11:44:59 +0200 (CEST) Date: Wed, 02 Jun 2010 11:44:59 +0200 (CEST) Message-Id: <20100602.114459.178639483.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Netconf] comments on draft-ietf-netconf-with-defaults-08.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, 02 Jun 2010 09:45:17 -0000 Hi, I have reviewed this document, and here are my comments: -------------------------------------------------- 2.1.2. 'report-all' Retrieval This is the first mentioning of " Retrieval". What is it? Aha. On a second reading I think I understand what you mean. I suggest the following text: NEW: 2.1.1. 'report-all' Basic Mode Retrieval When data is retrieved from a server using the 'report-all' basic mode, and the parameter is not present, all data nodes MUST be reported. 2.1.2. 'report-all' Retrieval When data is retrieved with a parameter equal to 'report-all', all data nodes MUST be reported, including any data nodes considered to be default data by the server. And similar for the other modes in 2.2 and 2.3. Also, I think the title of 2.1 is misleading: 2.1. 'report-all' Basic Mode since 2.1.2 applies to *all* basic modes. Actually, the title of section 2 is also misleading. Maybe a solution is to move section 2.1.2 to Section 3, which introduces the parameter. -------------------------------------------------- 2.1.3 2.2.3 and 2.3.3 talks about how the wd:default attribute is to be handled. Shouldn't 2.1.3 also talk about this? If the idea is that a report-all server cannot also support report-all-tagged, this should be mentioned. -------------------------------------------------- 2.1.4 All data nodes MUST be saved in non-volatile storage. If a device advertises :startup and :writable-running, and I create a new list entry in running, the device will create some default nodes. But at this point they are not stored in nv-storage... I would prefer to not talk about n-v at all; and instead say: All data nodes MUST be stored in the NETCONF datastore. (similar for the other modes) -------------------------------------------------- 2.2.3 s/same affect/same effect/ -------------------------------------------------- 2.2.3 and 2.3.3 If all NETCONF sub-operation parameters are valid, What is a "sub-operation parameter"? -------------------------------------------------- 2.2.3 The last sentence says: If the data node within the NETCONF message contains a value in this case, it MUST be equal to the schema default value. What happens otherwise? -------------------------------------------------- 3. The parameter contains one of the three basic mode enumerations defined above, + 'report-all-tagged' -------------------------------------------------- 4.6.1 The document makes a clear distinction between the new capability and the new YANG module. But section 4 mixes the two. Specifically section 4.6.1 talks about the parameter which is defined in the YANG module in section 5. I think the text in 4.6.1 should be moved into the YANG module. -------------------------------------------------- 4.6.1 If an unsupported value is used, the NETCONF server MUST return an with an element. The SHOULD be 'invalid-value', and the SHOULD be 'with-defaults- mode-not-supported'. Why are these SHOULD? I suggest MUST. I also agree with whoever had the comment that the error-app-tag is not really necessary in this case. So I suggest: The MUST be 'invalid-value'. -------------------------------------------------- 4.6.2 The last paragraph starts with: If this editing mode is used, then ... What is "this editing mode"? -------------------------------------------------- The YANG module in section 5. Checking our own rules in netmod-guidelines: $ pyang --ietf ietf-netconf-with-defaults@2010-05-19.yang ietf-netconf-with-defaults@2010-05-19.yang:93: error: IETF rule: statement "grouping" must have a "description" substatement ietf-netconf-with-defaults@2010-05-19.yang:102: error: IETF rule: statement "augment" must have a "description" substatement ietf-netconf-with-defaults@2010-05-19.yang:107: error: IETF rule: statement "augment" must have a "description" substatement ietf-netconf-with-defaults@2010-05-19.yang:112: error: IETF rule: statement "augment" must have a "description" substatement -------------------------------------------------- The XSD in 6. The XSD does not compile. Since the attribute is global, the 'form' attribute cannot be given. OLD: NEW: /martin From mrw@lilacglade.org Wed Jun 2 05:08:41 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37B9628C172 for ; Wed, 2 Jun 2010 05:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 0Fhe0m-cfvZO for ; Wed, 2 Jun 2010 05:08:37 -0700 (PDT) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id DCE0E28C16C for ; Wed, 2 Jun 2010 05:08:37 -0700 (PDT) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta05.emeryville.ca.mail.comcast.net with comcast id QzqV1e0031smiN4A508RUv; Wed, 02 Jun 2010 12:08:25 +0000 Received: from [10.36.0.42] ([98.118.46.178]) by omta20.emeryville.ca.mail.comcast.net with comcast id R08A1e0053qflwq8g08Foa; Wed, 02 Jun 2010 12:08:23 +0000 Message-Id: From: Margaret Wasserman To: Martin Bjorklund In-Reply-To: <20100602.101123.205647377.mbj@tail-f.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 2 Jun 2010 08:06:55 -0400 References: <20100601173009.7510D3A6995@core3.amsl.com> <20100602.101123.205647377.mbj@tail-f.com> X-Mailer: Apple Mail (2.936) Cc: netconf@ietf.org Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-01.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, 02 Jun 2010 12:08:41 -0000 Hi Martin, On Jun 2, 2010, at 4:11 AM, Martin Bjorklund wrote: > > Most issues are fixed, but I think the change to NETCONF operation was > applied in cases where it shouldn't have been. Could you send me a list of the places where you would prefer that I use the term "RPC message", so that we can have a specific proposed change to discuss in the WG? > My original point was > that the previous version used different terms for the same thing, > "operation", "command", "RPC message" etc. We should use one term, > "operation", or "NETCONF operation" as you did. But the term > operation refers to specific rpcs, e.g. edit-config, close-session > etc. When we refer to the layer below operations, we use the term > "message" (or "NETCONF message"). Although I used the term NETCONF command and NETCONF operation interchangeably in the last version, this was the distinction I was trying to make when I used the term "RPC message". However, your previous proposed change (which the WG accepted) included changing RPC message to NETCONF operation, as well. So, if I change all of those occurrences back to "RPC message", I doubt that will work for you either... If you can send a specific set of places where you believe we should use "RPC message", hopefully we can get agreement in the WG on the specific places where that term should be used, instead of NETCONF operation. > > NEW: > > The following example shows a capability exchange. Data sent > by the NETCONF client are marked with "C:" and data sent by the > NETCONF server are marked with "S:". Why "data" instead of "RPC messages"? I don't see "data" as an option in the reference diagram... > Another issue is from section 5, on close-session: > > the NETCONF server > shall respond and close the SSH session channel. > > s/shall/SHALL/ (or MUST) I will make this change in the next version unless anyone objects. Margaret From mbj@tail-f.com Wed Jun 2 06:29:26 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB0003A69B9 for ; Wed, 2 Jun 2010 06:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.654 X-Spam-Level: X-Spam-Status: No, score=0.654 tagged_above=-999 required=5 tests=[AWL=0.100, 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 vr1iXfAwUFu3 for ; Wed, 2 Jun 2010 06:29:25 -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 B76B93A67AD for ; Wed, 2 Jun 2010 06:29:24 -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 36419616004; Wed, 2 Jun 2010 15:29:11 +0200 (CEST) Date: Wed, 02 Jun 2010 15:29:10 +0200 (CEST) Message-Id: <20100602.152910.125098302.mbj@tail-f.com> To: mrw@lilacglade.org From: Martin Bjorklund In-Reply-To: References: <20100602.101123.205647377.mbj@tail-f.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-01.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, 02 Jun 2010 13:29:26 -0000 Hi, Margaret Wasserman wrote: > > Hi Martin, > > On Jun 2, 2010, at 4:11 AM, Martin Bjorklund wrote: > > > > Most issues are fixed, but I think the change to NETCONF operation was > > applied in cases where it shouldn't have been. > > Could you send me a list of the places where you would prefer that I > use the term "RPC message", so that we can have a specific proposed > change to discuss in the WG? Ok. OLD: 1 The SSH client initiates the SSH connection and the SSH server accepts the connection. The NETCONF client sends NETCONF operations, and the NETCONF server responds to those operations. There is no requirement that the NETCONF client reside on the SSH client or that the NETCONF server reside on the SSH server. NEW: The NETCONF client sends NETCONF The SSH client initiates the SSH connection and the SSH server accepts the connection. There is no requirement that the NETCONF client reside on the SSH client or that the NETCONF server reside on the SSH server. (i.e. just delete the sentence about who sends what -- it is not relevant for the transport protocol; the alternative would be to say that each peer sends NETCONF messages) OLD: 1 Although this document gives specific examples of how NETCONF operations are sent over an SSH connection, use of this transport is not restricted to the operations shown in the examples below. This transport can be used for any NETCONF operation. NEW: Although this document gives specific examples of how NETCONF messages are sent over an SSH connection, use of this transport is not restricted to the messages shown in the examples below. This transport can be used for any NETCONF message. OLD: 3.1 The NETCONF server MUST indicate its capabilities by sending an XML document containing a element as soon as the NETCONF session is established. The NETCONF client can parse this operation to determine which NETCONF capabilities are supported by the NETCONF server. NEW: The NETCONF server MUST indicate its capabilities by sending an XML document containing a element as soon as the NETCONF session is established. The NETCONF client can parse this message to determine which NETCONF capabilities are supported by the NETCONF server. OLD: 3.1 The following example shows a capability exchange. Operations sent by the NETCONF client are marked with "C:" and operations sent by the NETCONF server are marked with "S:". NEW: The following example shows a capability exchange. Data sent by the NETCONF client are marked with "C:" and data sent by the NETCONF server are marked with "S:". (The reason is that each line is marked with C: and S: -- this is not an operation; it is just data) OLD: 3.1 Although the example shows the NETCONF server sending a operation followed by the NETCONF client's operation, both sides will send the operation as soon as the NETCONF subsystem is initialized, perhaps simultaneously. NEW: Although the example shows the NETCONF server sending a message followed by the NETCONF client's message, both sides will send the message as soon as the NETCONF subsystem is initialized, perhaps simultaneously. OLD: 5 Exiting NETCONF is accomplished using the operation. A NETCONF server will process NETCONF operations from the NETCONF client in the order in which the are received. When the NETCONF server processes a operation, the NETCONF server shall respond and close the SSH session channel. The NETCONF server MUST NOT process any NETCONF operations received after the operation. NEW: Exiting NETCONF is accomplished using the operation. A NETCONF server will process NETCONF messages from the NETCONF client in the order in which the are received. When the NETCONF server processes a operation, the NETCONF server SHALL respond and close the SSH session channel. The NETCONF server MUST NOT process any NETCONF messages received after the operation. /martin From lhotka@cesnet.cz Wed Jun 2 07:37:48 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CADF93A6839 for ; Wed, 2 Jun 2010 07:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.95 X-Spam-Level: * X-Spam-Status: No, score=1.95 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpquASZU4fit for ; Wed, 2 Jun 2010 07:37:48 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id CD3063A659B for ; Wed, 2 Jun 2010 07:37:47 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id E867B2CDE057 for ; Wed, 2 Jun 2010 16:37:33 +0200 (CEST) From: Ladislav Lhotka To: NETCONF WG Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Jun 2010 16:37:32 +0200 Message-ID: <1275489452.20869.99.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: [Netconf] LL review of -with-defaults X-BeenThere: netconf@ietf.org X-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, 02 Jun 2010 14:37:48 -0000 Hi, I read the entire document, including the appendices. General comments: - I am not happy with the fact that the server reaction to edit-config depends on its basic with-defaults mode. This means that a NETCONF operation (or a series of operations) that succeeds on one server may fail on another, even if their _conceptual_ configuration is identical and they only differ in the basic with-defaults mode. - The details of responses to get/get-config with filters (subtree or XPath) should IMO also be specified. For example, what if a filter explicitly specifies a node that has a default value? - The wd:default attribute seems underspecified, especially when used in edit-config messages. Questions: 1. Is it permitted to attach wd:default to non-leaf nodes? 2. What if a (leaf) node with wd:default="true" specifies a value in its text that is different from the default? Specific comments: ** Sec. 1.1 - term "Default data": The last sentence "Default data is not kept in a configuration datastore." is not true for a report-all style database. ** Sec. 2.1.2 To a casual reader, it may not be entirely clear what the title means. Martin already suggested some improvements, but perhaps it would be simpler to say at the beginning of Sec. 2 that the effective mode for a given data retrieval operation is selected either by the element (with a reference to Sec. 4.6.1) or, if is not present, by the server's basic mode. ** Sec. 2.3.1 What does it exactly mean that "the server set a data node"? Does it apply to an "embedded NETCONF client" that runs on the server? ** Sec. 3, second paragraph OLD "The server must accept the parameter ..." NEW "A server which implements this specification must accept the parameter ..." ** Sec. 3.1, third paragraph s/it is present/if it is present/ ** App. A.2 Does everybody agree that the "conceptual contents" has ALL data, including those that have not been set but have default values, as the example shows? If so, I don't understand why the edit-config behaviour has to differ. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Wed Jun 2 08:05:35 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1743A69E0 for ; Wed, 2 Jun 2010 08:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.831 X-Spam-Level: X-Spam-Status: No, score=0.831 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5rOE0uMlfh4 for ; Wed, 2 Jun 2010 08:05:34 -0700 (PDT) Received: from smtp184.dfw.emailsrvr.com (smtp184.dfw.emailsrvr.com [67.192.241.184]) by core3.amsl.com (Postfix) with ESMTP id 955573A698F for ; Wed, 2 Jun 2010 08:05:34 -0700 (PDT) Received: from relay8.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay8.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id E226140253; Wed, 2 Jun 2010 11:05:21 -0400 (EDT) Received: by relay8.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id A4FC7401E5; Wed, 2 Jun 2010 11:05:21 -0400 (EDT) Message-ID: <4C067334.2000607@iwl.com> Date: Wed, 02 Jun 2010 08:05:24 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ladislav Lhotka References: <1275489452.20869.99.camel@missotis> In-Reply-To: <1275489452.20869.99.camel@missotis> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF WG Subject: Re: [Netconf] LL review of -with-defaults X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 15:05:35 -0000 On 06/02/2010 07:37 AM, Ladislav Lhotka wrote: > Hi, > > I read the entire document, including the appendices. > > General comments: > > - I am not happy with the fact that the server reaction to edit-config > depends on its basic with-defaults mode. This means that a NETCONF > operation (or a series of operations) that succeeds on one server > may fail on another, even if their _conceptual_ configuration is > identical and they only differ in the basic with-defaults mode. > > The reason we have this draft is because there are differences in the way servers treat defaults. According to the YANG spec, schema-default leaves do not exist. Only the 'trim' basic mode actually works this way. It seems odd to set a leaf to a value, yet it still doesn't exist. The 'explicit' and 'report-all' basic modes completely ignore what YANG has to say about schema-default leafs. Should we make them illegal in NETCONF? This is like the vs debate. We could not convince all vendors to re-think their SW designs so they matched just 1 vendor. The with-defaults capability limits the behavior to a small set of variants. > - The details of responses to get/get-config with filters (subtree or > XPath) should IMO also be specified. For example, what if a filter > explicitly specifies a node that has a default value? > > - The wd:default attribute seems underspecified, especially when used > in edit-config messages. Questions: > 1. Is it permitted to attach wd:default to non-leaf nodes? > 2. What if a (leaf) node with wd:default="true" specifies a value in > its text that is different from the default? > > Specific comments: > > ** Sec. 1.1 > - term "Default data": The last sentence "Default data is not kept > in a configuration datastore." is not true for a report-all style > database. > ** Sec. 2.1.2 > To a casual reader, it may not be entirely clear what the title > means. Martin already suggested some improvements, but perhaps it > would be simpler to say at the beginning of Sec. 2 that the > effective mode for a given data retrieval operation is selected > either by the element (with a reference to > Sec. 4.6.1) or, if is not present, by the > server's basic mode. > ** Sec. 2.3.1 > What does it exactly mean that "the server set a data node"? Does > it apply to an "embedded NETCONF client" that runs on the server? > Any node created within the server implementation that is not a schema-default leaf. > ** Sec. 3, second paragraph > OLD > "The server must accept the parameter ..." > NEW > "A server which implements this specification must accept the > parameter ..." > ** Sec. 3.1, third paragraph > s/it is present/if it is present/ > ** App. A.2 > Does everybody agree that the "conceptual contents" has ALL data, > including those that have not been set but have default values, as > the example shows? If so, I don't understand why the edit-config > behaviour has to differ. > Because explicit and report-all basic modes ignore what YANG calls a default and have their own definitions of a database. SQL database implementations do the same thing. > Lada > > Andy From lhotka@cesnet.cz Wed Jun 2 08:26:10 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC2A3A6807 for ; Wed, 2 Jun 2010 08:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.65 X-Spam-Level: * X-Spam-Status: No, score=1.65 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9hzNShl5kOk for ; Wed, 2 Jun 2010 08:26:08 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A6FD93A6875 for ; Wed, 2 Jun 2010 08:26:08 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 010A52CDE05B; Wed, 2 Jun 2010 17:25:54 +0200 (CEST) From: Ladislav Lhotka To: andyb@iwl.com In-Reply-To: <4C067334.2000607@iwl.com> References: <1275489452.20869.99.camel@missotis> <4C067334.2000607@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Jun 2010 17:25:53 +0200 Message-ID: <1275492353.20869.122.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: NETCONF WG Subject: Re: [Netconf] LL review of -with-defaults X-BeenThere: netconf@ietf.org X-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, 02 Jun 2010 15:26:10 -0000 Andy Bierman píše v St 02. 06. 2010 v 08:05 -0700: > On 06/02/2010 07:37 AM, Ladislav Lhotka wrote: > > Hi, > > > > I read the entire document, including the appendices. > > > > General comments: > > > > - I am not happy with the fact that the server reaction to edit-config > > depends on its basic with-defaults mode. This means that a NETCONF > > operation (or a series of operations) that succeeds on one server > > may fail on another, even if their _conceptual_ configuration is > > identical and they only differ in the basic with-defaults mode. > > > > > > The reason we have this draft is > because there are differences in the way > servers treat defaults. So if somebody builds up a large set of automatic configuration scripts, a switch from one platform to another, both supporting NETCONF and the same modules but using different basic with-defaults mode, can easily become a nightmare. > > According to the YANG spec, schema-default leaves > do not exist. Only the 'trim' basic mode actually works Where does the YANG spec say so? I can't find it. > this way. It seems odd to set a leaf to a value, > yet it still doesn't exist. > > The 'explicit' and 'report-all' basic modes completely > ignore what YANG has to say about schema-default leafs. > Should we make them illegal in NETCONF? > > This is like the vs debate. > We could not convince all vendors to re-think their SW designs > so they matched just 1 vendor. The with-defaults capability > limits the behavior to a small set of variants. > ... > > ** Sec. 2.3.1 > > What does it exactly mean that "the server set a data node"? Does > > it apply to an "embedded NETCONF client" that runs on the server? > > > > Any node created within the server implementation > that is not a schema-default leaf. According to the definition of the term in 4741bis (that this draft refers to), "server" is the entire device, not just the NETCONF software. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Jun 2 08:38:11 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D6828C128 for ; Wed, 2 Jun 2010 08:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 f+jdkpuxcrdB for ; Wed, 2 Jun 2010 08:38:09 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EB16828C122 for ; Wed, 2 Jun 2010 08:38:08 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CEBB7C000D; Wed, 2 Jun 2010 17:37:55 +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 I2BYgb1pSQvX; Wed, 2 Jun 2010 17:37:54 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 79C08C0008; Wed, 2 Jun 2010 17:37:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B44D212B4C21; Wed, 2 Jun 2010 17:37:52 +0200 (CEST) Date: Wed, 2 Jun 2010 17:37:52 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100602153751.GA21148@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , NETCONF WG References: <1275489452.20869.99.camel@missotis> <4C067334.2000607@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C067334.2000607@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETCONF WG Subject: Re: [Netconf] LL review of -with-defaults X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 15:38:11 -0000 On Wed, Jun 02, 2010 at 05:05:24PM +0200, Andy Bierman wrote: > The 'explicit' and 'report-all' basic modes completely > ignore what YANG has to say about schema-default leafs. > Should we make them illegal in NETCONF? Can you point me to the section(s) in the YANG spec please? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andyb@iwl.com Wed Jun 2 09:38:19 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C8993A6828 for ; Wed, 2 Jun 2010 09:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.57 X-Spam-Level: X-Spam-Status: No, score=-1.57 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_50=0.001, 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 otRIN5fXhMG7 for ; Wed, 2 Jun 2010 09:38:13 -0700 (PDT) Received: from smtp114.iad.emailsrvr.com (smtp114.iad.emailsrvr.com [207.97.245.114]) by core3.amsl.com (Postfix) with ESMTP id 8467828C0E1 for ; Wed, 2 Jun 2010 09:38:10 -0700 (PDT) Received: from relay31.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay31.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id A284E1B4CFB; Wed, 2 Jun 2010 12:37:57 -0400 (EDT) Received: by relay31.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 5DA7E1B4AB3; Wed, 2 Jun 2010 12:37:57 -0400 (EDT) Message-ID: <4C0688E9.9060205@iwl.com> Date: Wed, 02 Jun 2010 09:38:01 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ladislav Lhotka References: <1275489452.20869.99.camel@missotis> <4C067334.2000607@iwl.com> <1275492353.20869.122.camel@missotis> In-Reply-To: <1275492353.20869.122.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETCONF WG Subject: Re: [Netconf] LL review of -with-defaults X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 16:38:19 -0000 On 06/02/2010 08:25 AM, Ladislav Lhotka wrote: > Andy Bierman píše v St 02. 06. 2010 v 08:05 -0700: > >> On 06/02/2010 07:37 AM, Ladislav Lhotka wrote: >> >>> Hi, >>> >>> I read the entire document, including the appendices. >>> >>> General comments: >>> >>> - I am not happy with the fact that the server reaction to edit-config >>> depends on its basic with-defaults mode. This means that a NETCONF >>> operation (or a series of operations) that succeeds on one server >>> may fail on another, even if their _conceptual_ configuration is >>> identical and they only differ in the basic with-defaults mode. >>> >>> >>> >> The reason we have this draft is >> because there are differences in the way >> servers treat defaults. >> > So if somebody builds up a large set of automatic configuration scripts, > a switch from one platform to another, both supporting NETCONF and the > same modules but using different basic with-defaults mode, can easily > become a nightmare. > not if the client deals with with-defaults, taken from the . This is no different than adjusting the database 'target' and 'save' meta-command based on the candidate, confirmed-commit, startup, and writable-running capabilities. (yangcli does this already). > >> According to the YANG spec, schema-default leaves >> do not exist. Only the 'trim' basic mode actually works >> > Where does the YANG spec say so? I can't find it. > 7.6.1. The leaf's default value The default value of a leaf is the value that the server uses if the leaf does not exist in the data tree. What part of 'does not exist' is unclear? > >> this way. It seems odd to set a leaf to a value, >> yet it still doesn't exist. >> >> The 'explicit' and 'report-all' basic modes completely >> ignore what YANG has to say about schema-default leafs. >> Should we make them illegal in NETCONF? >> >> This is like the vs debate. >> We could not convince all vendors to re-think their SW designs >> so they matched just 1 vendor. The with-defaults capability >> limits the behavior to a small set of variants. >> >> > ... > > >>> ** Sec. 2.3.1 >>> What does it exactly mean that "the server set a data node"? Does >>> it apply to an "embedded NETCONF client" that runs on the server? >>> >>> >> Any node created within the server implementation >> that is not a schema-default leaf. >> > According to the definition of the term in 4741bis (that this draft > refers to), "server" is the entire device, not just the NETCONF > software. > This is an implementation detail. If I implement an auto-generated WEB UI from YANG modules, is this a client or part of the server? If the WEB UI initiates a NETCONF session over the loopback interface, then it is clearly an client. It is uses library calls or some other mechanism than a NETCONF session, then it is not a client. > Lada > > Andy From mbj@tail-f.com Wed Jun 2 09:45:37 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDAB028C136 for ; Wed, 2 Jun 2010 09:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[AWL=-0.650, 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 2gBLaPo1e3fp for ; Wed, 2 Jun 2010 09:45:36 -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 7699328C113 for ; Wed, 2 Jun 2010 09:45:36 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id DE4ED616002; Wed, 2 Jun 2010 18:45:22 +0200 (CEST) Date: Wed, 02 Jun 2010 18:45:22 +0200 (CEST) Message-Id: <20100602.184522.168985517.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4C0688E9.9060205@iwl.com> References: <4C067334.2000607@iwl.com> <1275492353.20869.122.camel@missotis> <4C0688E9.9060205@iwl.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Cc: netconf@ietf.org Subject: Re: [Netconf] LL review of -with-defaults X-BeenThere: netconf@ietf.org X-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, 02 Jun 2010 16:45:37 -0000 Andy Bierman wrote: > On 06/02/2010 08:25 AM, Ladislav Lhotka wrote: > > Andy Bierman p=ED=A8e v St 02. 06. 2010 v 08:05 -0700: > >> According to the YANG spec, schema-default leaves > >> do not exist. Only the 'trim' basic mode actually works > >> = > > Where does the YANG spec say so? I can't find it. > > = > = > = > 7.6.1. The leaf's default value > = > The default value of a leaf is the value that the server uses if t= he > leaf does not exist in the data tree. = > = > What part of 'does not exist' is unclear? This part is clear. But your statement that only trim actually works this way is not correct. If the leaf has a value, regardless of how it was set, then the server does not use the default value for that leaf. This is true for all modes. /martin From andyb@iwl.com Wed Jun 2 09:48:19 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C8928C113 for ; Wed, 2 Jun 2010 09:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.176 X-Spam-Level: X-Spam-Status: No, score=0.176 tagged_above=-999 required=5 tests=[AWL=0.582, BAYES_20=-0.74, 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 YYJnJi+jEFEq for ; Wed, 2 Jun 2010 09:48:18 -0700 (PDT) Received: from smtp184.dfw.emailsrvr.com (smtp184.dfw.emailsrvr.com [67.192.241.184]) by core3.amsl.com (Postfix) with ESMTP id BF5BC28C0E9 for ; Wed, 2 Jun 2010 09:48:18 -0700 (PDT) Received: from relay8.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay8.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 1C8D640160; Wed, 2 Jun 2010 12:48:06 -0400 (EDT) Received: by relay8.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id E248540068; Wed, 2 Jun 2010 12:48:05 -0400 (EDT) Message-ID: <4C068B4A.10305@iwl.com> Date: Wed, 02 Jun 2010 09:48:10 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ladislav Lhotka , NETCONF WG References: <1275489452.20869.99.camel@missotis> <4C067334.2000607@iwl.com> <20100602153751.GA21148@elstar.local> In-Reply-To: <20100602153751.GA21148@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] LL review of -with-defaults X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 16:48:19 -0000 On 06/02/2010 08:37 AM, Juergen Schoenwaelder wrote: > On Wed, Jun 02, 2010 at 05:05:24PM +0200, Andy Bierman wrote: > > >> The 'explicit' and 'report-all' basic modes completely >> ignore what YANG has to say about schema-default leafs. >> Should we make them illegal in NETCONF? >> > Can you point me to the section(s) in the YANG spec please? > 7.6.1. The leaf's default value The default value of a leaf is the value that the server uses if the leaf does not exist in the data tree. This text is carefully worded to allow explicit and report-all modes to exist. Obviously, I did not really mean we should make them illegal. If the leaf does not exist, then the schema-default has significance. Big 'if'. The server decides if the leaf exists or not. If the leaf does exist, the schema default is irrelevant. The leaf is just not a default leaf. The 'trim' mode is the only one that uses the same definition of default as described in 7.6.1. > /js > > Andy From phil@juniper.net Wed Jun 2 10:08:23 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7CE428C113 for ; Wed, 2 Jun 2010 10:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=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 QiEh9hC2pwtS for ; Wed, 2 Jun 2010 10:08:21 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 8664C28B797 for ; Wed, 2 Jun 2010 10:08:06 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTAaP6ADoA/T4kjmrTGhx27lJM4/j94p3@postini.com; Wed, 02 Jun 2010 10:08:09 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.2.254.0; Wed, 2 Jun 2010 10:02:36 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Jun 2010 10:02:36 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jun 2010 10:02:35 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Jun 2010 10:02:35 -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 o52H2YD73414; Wed, 2 Jun 2010 10:02:34 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o52GixZA016822; Wed, 2 Jun 2010 16:44:59 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201006021644.o52GixZA016822@idle.juniper.net> To: In-Reply-To: <4C068B4A.10305@iwl.com> Date: Wed, 2 Jun 2010 12:44:59 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 Jun 2010 17:02:35.0004 (UTC) FILETIME=[65A6A3C0:01CB0275] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF WG Subject: Re: [Netconf] LL review of -with-defaults X-BeenThere: netconf@ietf.org X-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, 02 Jun 2010 17:08:23 -0000 Andy Bierman writes: >This is like the vs debate. >We could not convince all vendors to re-think their SW designs >so they matched just 1 vendor. The with-defaults capability >limits the behavior to a small set of variants. I really don't think this is that hard. A client can generally treat all servers identically. If the model defines a list with one key, one mandatory leaf, and one leaf with a default value, then a client can know that it must send the key and mandatory leafs, and not sending the defaulting leaf will tell the server that it should be using the default value. The client can send this same data to any conformant server and The Right Thing will happen. >The 'trim' mode is the only one that uses the same definition >of default as described in 7.6.1. Couldn't disagree more. Any server implemenation that fails to grok that "The default value of a leaf is the value that the server uses if the leaf does not exist in the data tree" is not likely to survive. But can we please stop ourselves from descending into "Return of the Defaults XXV"? Thanks, Phil From andyb@iwl.com Wed Jun 2 10:37:06 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA593A69DB for ; Wed, 2 Jun 2010 10:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.475 X-Spam-Level: X-Spam-Status: No, score=-1.475 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_50=0.001, 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 rRvg17mmossA for ; Wed, 2 Jun 2010 10:37:05 -0700 (PDT) Received: from smtp134.iad.emailsrvr.com (smtp134.iad.emailsrvr.com [207.97.245.134]) by core3.amsl.com (Postfix) with ESMTP id 0E7253A69B0 for ; Wed, 2 Jun 2010 10:37:05 -0700 (PDT) Received: from relay3.r3.iad.emailsrvr.com (localhost [127.0.0.1]) by relay3.r3.iad.emailsrvr.com (SMTP Server) with ESMTP id 3464B44C049; Wed, 2 Jun 2010 13:36:52 -0400 (EDT) Received: by relay3.r3.iad.emailsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id A1C3544C118; Wed, 2 Jun 2010 13:36:51 -0400 (EDT) Message-ID: <4C0696B8.4010907@iwl.com> Date: Wed, 02 Jun 2010 10:36:56 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Phil Shafer References: <201006021644.o52GixZA016822@idle.juniper.net> In-Reply-To: <201006021644.o52GixZA016822@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF WG Subject: Re: [Netconf] LL review of -with-defaults X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 17:37:06 -0000 On 06/02/2010 09:44 AM, Phil Shafer wrote: > Andy Bierman writes: > >> This is like the vs debate. >> We could not convince all vendors to re-think their SW designs >> so they matched just 1 vendor. The with-defaults capability >> limits the behavior to a small set of variants. >> > I really don't think this is that hard. A client can generally > treat all servers identically. If the model defines a list with > one key, one mandatory leaf, and one leaf with a default value, > then a client can know that it must send the key and mandatory > leafs, and not sending the defaulting leaf will tell the server > that it should be using the default value. The client can send > this same data to any conformant server and The Right Thing will > happen. > good point > >> The 'trim' mode is the only one that uses the same definition >> of default as described in 7.6.1. >> > Couldn't disagree more. Any server implemenation that fails to > grok that "The default value of a leaf is the value that the server > uses if the leaf does not exist in the data tree" is not likely to > survive. > this definition is fine -- the YANG spec is silent on whether the node exists or not. Lada (and others) will want the schema default to indicate how NETCONF operations will behave. It may be hard to always explain that the YANG schema does not help an application use the create/delete operations. It is only partly true that a client can ignore defaults. Many corner-cases exist where 'replace-with-nothing' is either cumbersome or doesn't work. The 'delete' operation is needed in these cases. That's why we need the 'destroy' operation. The 'merge' and 'destroy' operation will work the same on every server, every time. Problem solved. (Now we can stop talking about defaults ;-) > But can we please stop ourselves from descending into "Return of > the Defaults XXV"? > The with-defaults draft is in WGLC, so it is unavoidable. > Thanks, > Phil > > Andy From lhotka@cesnet.cz Wed Jun 2 11:50:49 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDDF428C194 for ; Wed, 2 Jun 2010 11:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.5 X-Spam-Level: * X-Spam-Status: No, score=1.5 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lXAWZlwQbuR for ; Wed, 2 Jun 2010 11:50:45 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id CB51628C17B for ; Wed, 2 Jun 2010 11:50:35 -0700 (PDT) Received: from [172.29.2.216] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 4B3132CDE057; Wed, 2 Jun 2010 20:50:17 +0200 (CEST) From: Ladislav Lhotka To: andyb@iwl.com In-Reply-To: <4C0688E9.9060205@iwl.com> References: <1275489452.20869.99.camel@missotis> <4C067334.2000607@iwl.com> <1275492353.20869.122.camel@missotis> <4C0688E9.9060205@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 02 Jun 2010 20:50:16 +0200 Message-ID: <1275504616.1499.10.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: NETCONF WG Subject: Re: [Netconf] LL review of -with-defaults X-BeenThere: netconf@ietf.org X-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, 02 Jun 2010 18:50:49 -0000 On St, 2010-06-02 at 09:38 -0700, Andy Bierman wrote: > > > > >> According to the YANG spec, schema-default leaves > >> do not exist. Only the 'trim' basic mode actually works > >> > > Where does the YANG spec say so? I can't find it. > > > > > 7.6.1. The leaf's default value > > The default value of a leaf is the value that the server uses if the > leaf does not exist in the data tree. > > What part of 'does not exist' is unclear? But what about the tiny "if"? This sentence - as any implication - says nothing about whether the premise is true or not. > > > > > > >> this way. It seems odd to set a leaf to a value, > >> yet it still doesn't exist. > >> > >> The 'explicit' and 'report-all' basic modes completely > >> ignore what YANG has to say about schema-default leafs. > >> Should we make them illegal in NETCONF? > >> > >> This is like the vs debate. > >> We could not convince all vendors to re-think their SW designs > >> so they matched just 1 vendor. The with-defaults capability > >> limits the behavior to a small set of variants. > >> > >> > > ... > > > > > >>> ** Sec. 2.3.1 > >>> What does it exactly mean that "the server set a data node"? Does > >>> it apply to an "embedded NETCONF client" that runs on the server? > >>> > >>> > >> Any node created within the server implementation > >> that is not a schema-default leaf. > >> > > According to the definition of the term in 4741bis (that this draft > > refers to), "server" is the entire device, not just the NETCONF > > software. > > > > This is an implementation detail. > If I implement an auto-generated WEB UI from YANG modules, > is this a client or part of the server? If the WEB UI initiates > a NETCONF session over the loopback interface, then it is > clearly an client. It is uses library calls or some other > mechanism than a NETCONF session, then it is not a client. I am just saying that it should be absolutely clear what the meaning of "set by server" is, otherwise that "MUST NOT" is very problematic. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Jun 2 23:23:31 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04E13A688B for ; Wed, 2 Jun 2010 23:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 dJEiQCf-9xrm for ; Wed, 2 Jun 2010 23:23:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id AA6703A6830 for ; Wed, 2 Jun 2010 23:23:30 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6700BC0010; Thu, 3 Jun 2010 08:23:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id bb69Jm9nDoKe; Thu, 3 Jun 2010 08:23:16 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0FC4BC000D; Thu, 3 Jun 2010 08:23:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 800DF12B5C07; Thu, 3 Jun 2010 08:23:14 +0200 (CEST) Date: Thu, 3 Jun 2010 08:23:14 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100603062314.GA22278@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , NETCONF WG References: <1275489452.20869.99.camel@missotis> <4C067334.2000607@iwl.com> <20100602153751.GA21148@elstar.local> <4C068B4A.10305@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C068B4A.10305@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETCONF WG Subject: Re: [Netconf] LL review of -with-defaults 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, 03 Jun 2010 06:23:31 -0000 On Wed, Jun 02, 2010 at 06:48:10PM +0200, Andy Bierman wrote: > 7.6.1. The leaf's default value > > The default value of a leaf is the value that the server uses if the > leaf does not exist in the data tree. > > This text is carefully worded to allow explicit and report-all modes > to exist. Obviously, I did not really mean we should make them illegal. > > If the leaf does not exist, then the schema-default has significance. > Big 'if'. The server decides if the leaf exists or not. If the > leaf does exist, the schema default is irrelevant. The leaf > is just not a default leaf. > > The 'trim' mode is the only one that uses the same definition > of default as described in 7.6.1. I very much disagree with your last sentence. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andyb@iwl.com Wed Jun 2 23:25:49 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 926343A67B2 for ; Wed, 2 Jun 2010 23:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_20=-0.74, 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 tdOZeoKleB6f for ; Wed, 2 Jun 2010 23:25:45 -0700 (PDT) Received: from smtp124.iad.emailsrvr.com (smtp124.iad.emailsrvr.com [207.97.245.124]) by core3.amsl.com (Postfix) with ESMTP id 27C7F3A6830 for ; Wed, 2 Jun 2010 23:25:45 -0700 (PDT) Received: from relay22.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay22.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id D47121B41B5; Thu, 3 Jun 2010 02:25:31 -0400 (EDT) Received: by relay22.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 91D881B40DE; Thu, 3 Jun 2010 02:25:31 -0400 (EDT) Message-ID: <4C074AE2.50706@iwl.com> Date: Wed, 02 Jun 2010 23:25:38 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ladislav Lhotka , NETCONF WG References: <1275489452.20869.99.camel@missotis> <4C067334.2000607@iwl.com> <20100602153751.GA21148@elstar.local> <4C068B4A.10305@iwl.com> <20100603062314.GA22278@elstar.local> In-Reply-To: <20100603062314.GA22278@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] LL review of -with-defaults X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 06:25:49 -0000 On 06/02/2010 11:23 PM, Juergen Schoenwaelder wrote: > On Wed, Jun 02, 2010 at 06:48:10PM +0200, Andy Bierman wrote: > > >> 7.6.1. The leaf's default value >> >> The default value of a leaf is the value that the server uses if the >> leaf does not exist in the data tree. >> >> This text is carefully worded to allow explicit and report-all modes >> to exist. Obviously, I did not really mean we should make them illegal. >> >> If the leaf does not exist, then the schema-default has significance. >> Big 'if'. The server decides if the leaf exists or not. If the >> leaf does exist, the schema default is irrelevant. The leaf >> is just not a default leaf. >> >> The 'trim' mode is the only one that uses the same definition >> of default as described in 7.6.1. >> > I very much disagree with your last sentence. > Why? In trim mode, the nodes left out are exactly the schema-default nodes. Which other mode does that? None. > /js > > Andy From j.schoenwaelder@jacobs-university.de Wed Jun 2 23:36:24 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 304863A6814 for ; Wed, 2 Jun 2010 23:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 q57OgcyD5wHu for ; Wed, 2 Jun 2010 23:36:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C238E3A657C for ; Wed, 2 Jun 2010 23:36:17 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A89CBC000D; Thu, 3 Jun 2010 08:36:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id G0YXQr4ffHnP; Thu, 3 Jun 2010 08:36:03 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A41AC0010; Thu, 3 Jun 2010 08:36:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5BEF312B5CB6; Thu, 3 Jun 2010 08:36:02 +0200 (CEST) Date: Thu, 3 Jun 2010 08:36:02 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100603063602.GA22398@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , NETCONF WG References: <1275489452.20869.99.camel@missotis> <4C067334.2000607@iwl.com> <20100602153751.GA21148@elstar.local> <4C068B4A.10305@iwl.com> <20100603062314.GA22278@elstar.local> <4C074AE2.50706@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C074AE2.50706@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETCONF WG Subject: Re: [Netconf] LL review of -with-defaults 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, 03 Jun 2010 06:36:24 -0000 On Thu, Jun 03, 2010 at 08:25:38AM +0200, Andy Bierman wrote: > On 06/02/2010 11:23 PM, Juergen Schoenwaelder wrote: > > On Wed, Jun 02, 2010 at 06:48:10PM +0200, Andy Bierman wrote: > > > > > >> 7.6.1. The leaf's default value > >> > >> The default value of a leaf is the value that the server uses if the > >> leaf does not exist in the data tree. > >> > >> This text is carefully worded to allow explicit and report-all modes > >> to exist. Obviously, I did not really mean we should make them illegal. > >> > >> If the leaf does not exist, then the schema-default has significance. > >> Big 'if'. The server decides if the leaf exists or not. If the > >> leaf does exist, the schema default is irrelevant. The leaf > >> is just not a default leaf. > >> > >> The 'trim' mode is the only one that uses the same definition > >> of default as described in 7.6.1. > >> > > I very much disagree with your last sentence. > > > > Why? > > In trim mode, the nodes left out are exactly > the schema-default nodes. Which other mode > does that? None. The text says: if there is no leaf, the default is used This is not the same as (nor does it imply): if there is a leaf with a default value, it should be removed /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Wed Jun 2 23:37:24 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD8783A6814 for ; Wed, 2 Jun 2010 23:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.45 X-Spam-Level: * X-Spam-Status: No, score=1.45 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93bSEzdjMA-9 for ; Wed, 2 Jun 2010 23:37:24 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7079C3A6850 for ; Wed, 2 Jun 2010 23:37:10 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 38BC02CDE058; Thu, 3 Jun 2010 08:36:56 +0200 (CEST) From: Ladislav Lhotka To: andyb@iwl.com In-Reply-To: <4C074AE2.50706@iwl.com> References: <1275489452.20869.99.camel@missotis> <4C067334.2000607@iwl.com> <20100602153751.GA21148@elstar.local> <4C068B4A.10305@iwl.com> <20100603062314.GA22278@elstar.local> <4C074AE2.50706@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 03 Jun 2010 08:36:55 +0200 Message-ID: <1275547015.28981.26.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: NETCONF WG Subject: Re: [Netconf] LL review of -with-defaults X-BeenThere: netconf@ietf.org X-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, 03 Jun 2010 06:37:25 -0000 Andy Bierman píše v St 02. 06. 2010 v 23:25 -0700: > On 06/02/2010 11:23 PM, Juergen Schoenwaelder wrote: > > On Wed, Jun 02, 2010 at 06:48:10PM +0200, Andy Bierman wrote: > > > > > >> 7.6.1. The leaf's default value > >> > >> The default value of a leaf is the value that the server uses if the > >> leaf does not exist in the data tree. > >> > >> This text is carefully worded to allow explicit and report-all modes > >> to exist. Obviously, I did not really mean we should make them illegal. > >> > >> If the leaf does not exist, then the schema-default has significance. > >> Big 'if'. The server decides if the leaf exists or not. If the > >> leaf does exist, the schema default is irrelevant. The leaf > >> is just not a default leaf. > >> > >> The 'trim' mode is the only one that uses the same definition > >> of default as described in 7.6.1. > >> > > I very much disagree with your last sentence. > > > > Why? > > In trim mode, the nodes left out are exactly > the schema-default nodes. Which other mode > does that? None. I still fail to see the connection with the cited sentence from 7.6.1. For me that sentence defines the relationship between the actual data tree (where some leafs may be missing, depending on the "with-defaults style" of the datastore) and the conceptual configuration that influences the server operations. Lada > > > > /js > > > > > > Andy > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Thu Jun 3 01:53:54 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71D7B3A6960 for ; Thu, 3 Jun 2010 01:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=-0.310, 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 kRmX7iR7cInE for ; Thu, 3 Jun 2010 01:53:53 -0700 (PDT) Received: from smtp164.iad.emailsrvr.com (smtp164.iad.emailsrvr.com [207.97.245.164]) by core3.amsl.com (Postfix) with ESMTP id 4C5333A6915 for ; Thu, 3 Jun 2010 01:53:53 -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 23E7B16D05B; Thu, 3 Jun 2010 04:53:40 -0400 (EDT) Received: by relay6.relay.iad.emailsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id D3C6D16D057; Thu, 3 Jun 2010 04:53:39 -0400 (EDT) Message-ID: <4C076D9B.8010304@iwl.com> Date: Thu, 03 Jun 2010 01:53:47 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ladislav Lhotka References: <1275489452.20869.99.camel@missotis> <4C067334.2000607@iwl.com> <20100602153751.GA21148@elstar.local> <4C068B4A.10305@iwl.com> <20100603062314.GA22278@elstar.local> <4C074AE2.50706@iwl.com> <1275547015.28981.26.camel@missotis> In-Reply-To: <1275547015.28981.26.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETCONF WG Subject: Re: [Netconf] LL review of -with-defaults X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 08:53:54 -0000 On 06/02/2010 11:36 PM, Ladislav Lhotka wrote: > Andy Bierman píše v St 02. 06. 2010 v 23:25 -0700: > >> On 06/02/2010 11:23 PM, Juergen Schoenwaelder wrote: >> >>> On Wed, Jun 02, 2010 at 06:48:10PM +0200, Andy Bierman wrote: >>> >>> >>> >>>> 7.6.1. The leaf's default value >>>> >>>> The default value of a leaf is the value that the server uses if the >>>> leaf does not exist in the data tree. >>>> >>>> This text is carefully worded to allow explicit and report-all modes >>>> to exist. Obviously, I did not really mean we should make them illegal. >>>> >>>> If the leaf does not exist, then the schema-default has significance. >>>> Big 'if'. The server decides if the leaf exists or not. If the >>>> leaf does exist, the schema default is irrelevant. The leaf >>>> is just not a default leaf. >>>> >>>> The 'trim' mode is the only one that uses the same definition >>>> of default as described in 7.6.1. >>>> >>>> >>> I very much disagree with your last sentence. >>> >>> >> Why? >> >> In trim mode, the nodes left out are exactly >> the schema-default nodes. Which other mode >> does that? None. >> > I still fail to see the connection with the cited sentence from 7.6.1. > For me that sentence defines the relationship between the actual data > tree (where some leafs may be missing, depending on the "with-defaults > style" of the datastore) and the conceptual configuration that > influences the server operations. > > Sorry I brought up this topic. It is not relevant to any particular text in any draft so let's drop it. > Lada > Andy From bertietf@bwijnen.net Fri Jun 4 15:18:34 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8913A69F5 for ; Fri, 4 Jun 2010 15:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_INVITATION=-2, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhK1ZGX-aY4v for ; Fri, 4 Jun 2010 15:18:33 -0700 (PDT) Received: from relay.versatel.net (relay58.tele2.vuurwerk.nl [62.250.3.58]) by core3.amsl.com (Postfix) with ESMTP id BCE3D3A6841 for ; Fri, 4 Jun 2010 15:18:30 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1OKfDT-0006aC-Uy for netconf@ietf.org; Sat, 05 Jun 2010 00:18:16 +0200 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Sat, 5 Jun 2010 00:18:09 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18197 Subject: [Netconf] Fw: IETF 78 - Meeting and Sponsorship Information X-BeenThere: netconf@ietf.org X-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, 04 Jun 2010 22:18:34 -0000 WG members for your info and possible follow up. ----- Original Message ----- From: "IETF Secretariat" To: "Working Group Chairs" Sent: Thursday, June 03, 2010 9:51 PM Subject: IETF 78 - Meeting and Sponsorship Information Working Group Chairs, Can you please forward this message to your individual working group emails lists. We want to ensure that as many people as possible are aware of the sponsorship opportunities available at IETF meetings. Thank you. ========================================== 78th IETF Meeting Maastricht, Netherlands July 25-30, 2010 1. Sponsorship Opportunities 2. Registration Types 3. Visas and Letters of Invitation 4. Accommodations & Breakfast Information 5. IETF 79 (Beijing) Visa Information 1) Sponsorship Opportunities There are still sponsorship opportunities and benefits for high profile company/organizational exposure at the upcoming IETF meeting in Maastricht, Netherlands from July 25-30, 2010. All sponsorship fees go directly to fund the operations of the IETF. See the options at: http://www.ietf.org/meeting/78/index.html �Sponsorship Opportunities� under �General�. Each of the sponsorship options provide extended and repeat exposure at this weeklong meeting. Please contact Drew Dvorshak, dvorshak@isoc.org, with any questions and/or to reserve your organization�s spot. Thanks in advance for supporting the critical work of the IETF! 2) Register online at: http://www.ietf.org/meetings/78/ 3) Letters of Invitation and Visas Letters of Invitation After you complete the meeting registration process, you will be given the option to request a letter of invitation. You can request the Letter of Invitation as soon as you finish registration, or at a later time by following the link provided in the confirmation email. Visas Please check the Netherlands Ministry of Foreign Affairs site (http://www.minbuza.nl/en/Services/Consular_Services/Visa) for list of countries with visa exemptions. We recommend you give yourself at least one month to complete the visa process. 4) Accommodations & Breakfast Information http://www.ietf.org/meeting/78/hotel.html 5) If you want to start planning for your trip to IETF 79 in Beijing, we have visa information online here: http://www.ietf.org/meeting/79/visa.html Only 52 days until IETF 78! From bertietf@bwijnen.net Mon Jun 7 08:23:39 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CD0F3A6359 for ; Mon, 7 Jun 2010 08:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.156 X-Spam-Level: ** X-Spam-Status: No, score=2.156 tagged_above=-999 required=5 tests=[HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27fB4bKAPQ4c for ; Mon, 7 Jun 2010 08:23:38 -0700 (PDT) Received: from relay.versatel.net (relay58.tele2.vuurwerk.nl [62.250.3.58]) by core3.amsl.com (Postfix) with ESMTP id 1FE023A8CA7 for ; Sun, 6 Jun 2010 12:18:00 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1OLLM7-0006qu-73 for netconf@ietf.org; Sun, 06 Jun 2010 21:17:59 +0200 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Sun, 6 Jun 2010 21:17:39 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18197 Subject: [Netconf] testing, pls ignore X-BeenThere: netconf@ietf.org X-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, 07 Jun 2010 15:23:39 -0000 Is the mailing list working? Bert Wijnen From andyb@iwl.com Mon Jun 7 10:06:55 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47BD028C381 for ; Mon, 7 Jun 2010 10:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 YGL0kD3bQFIB for ; Mon, 7 Jun 2010 10:06:54 -0700 (PDT) Received: from smtp184.dfw.emailsrvr.com (smtp184.dfw.emailsrvr.com [67.192.241.184]) by core3.amsl.com (Postfix) with ESMTP id E6F503A887A for ; Sun, 6 Jun 2010 09:59:11 -0700 (PDT) Received: from relay8.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay8.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 10687400B9 for ; Sun, 6 Jun 2010 12:59:12 -0400 (EDT) Received: by relay8.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id E470C400A3 for ; Sun, 6 Jun 2010 12:59:11 -0400 (EDT) Message-ID: <4C0BD3FA.3060209@iwl.com> Date: Sun, 06 Jun 2010 09:59:38 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] delete and remove operations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:06:55 -0000 Hi, The WG needs to decide what to do about the delete operation. It is too picky (or is it? -- see below) CURRENT TEXT: create: The configuration data identified by the element containing this attribute is added to the configuration if and only if the configuration data does not already exist in the configuration datastore. If the configuration data exists, an element is returned with an value of data-exists. delete: The configuration data identified by the element containing this attribute is deleted in the configuration datastore identified by the target parameter. Unlike the 'create' operation, there is no error specified for delete. I can't find any text about a data-missing error related to the delete operation. The data-missing error-tag does not specify which operations need to use this error-tag. According to RFC 4741 (and 4741bis), there is no requirement whatsoever to reject a delete operation if the data is missing. This is simply folklore, based on the intent of the WG (at that time). >>> DECISION (applies to 4741bis servers only): ** Option A: Clarify that the delete operation is required to return a data-missing error-tag if the delete target node does not exist. ** Option B: Clarify that the delete operation is not required to return a data-missing error-tag if the delete target node does not exist. ** Option C: Option A + add a new 'remove' operation: NEW: (7.2, operation attribute). remove: The configuration data identified by the element containing this attribute is removed from the configuration datastore identified by the target parameter, if it exists. thanks, Andy From j.schoenwaelder@jacobs-university.de Mon Jun 7 10:23:08 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A2A33A6AD9 for ; Mon, 7 Jun 2010 10:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.951 X-Spam-Level: X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6nEFUKdnNAE for ; Mon, 7 Jun 2010 10:23:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EEB6B28C345 for ; Mon, 7 Jun 2010 09:00:54 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB79FC000F; Mon, 7 Jun 2010 16:45:34 +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 tJZA1DqWUKjf; Mon, 7 Jun 2010 16:45:31 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC9D8C0024; Mon, 7 Jun 2010 16:45:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DCADD12E7518; Mon, 7 Jun 2010 16:45:29 +0200 (CEST) Date: Mon, 7 Jun 2010 16:45:29 +0200 From: Juergen Schoenwaelder To: "Bert (IETF) Wijnen" Message-ID: <20100607144529.GB2918@elstar.local> Mail-Followup-To: "Bert (IETF) Wijnen" , netconf References: <4BFCCBCB.8020109@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BFCCBCB.8020109@bwijnen.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: netconf Subject: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt 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: Mon, 07 Jun 2010 17:23:08 -0000 On Wed, May 26, 2010 at 09:20:43AM +0200, Bert (IETF) Wijnen wrote: > This is a(nother) formal WG Last Call for this this document. > Please review and comment BEFORE June 6th 2010. Here is my review of draft-ietf-netconf-with-defaults-08. Sorry for being a day late but the weather last weekend was just too nice to sit in front of my computer... I still believe the announcement of the basic-mode should be part of RFC 4741bis so that _all_ RFC4741bis implementations announce their basic default handling mode. I regret that we do not solve the more general problem how we report operational state data but instead solve via a new tagging mechanism only for default value identification problem, which I consider a special case of operational state data. Here are all the other little comments I have on the -08 version. I have tried to be constructive, proposing concrete rewordings for some pieces of text. These text messages are meant to help the editor and make my change request clear but other wordings might do equally well; take my wording proposals just as a suggestion. a) p4 says: [...] Part of the configuration data may not be set by the NETCONF client, but rather by a default value from the data model. Reading this as someone who prefers explicit mode and considers defaults as operational state, this sentence is not correct. In explicit more, the default is not part of the explicit configuration. b) p4: s/can be e.g.,/can be obtained from e.g.,/ c) p4 says: Default data: Data considered by a particular server to contain a default value. Default data is not kept in a configuration datastore. Again, the last sentence is not true for an explicit server. d) p4: s/an actual management operation/an explicit management operation/ e) p5: I suggest to remove the following sentence: [...] The nodes that are returned in this case are the only nodes the server considers to exist in the datastore. I do not know what 'this case' refers to nor to I think this sentence is always correct and it seems the sentence is not needed in the first place. f) p5: s/ 'operation'/operation attribute of the operation/ The motivation is to align with the language used in RFC 4741. g) p6: replace this sentence OLD In all these cases the NETCONF client will need default data as part of the NETCONF messages. NEW In all these cases, the NETCONF client will need a mechanism to retrieve default data from a NETCONF server. Motivation: I think we should avoid talking about messages since this whole document is an extension of some operations of the operations layer. h) p6: s/in certain NETCONF messages// Same motivation as above. i) p7: s/'create' operation/'create' operation attribute/ s/'delete' operation/'delete' operation attribute/ Motivation: Align with RFC 4741 terminology. Note this shows up twice on p7. j) p7: I think we need to be more explicit about the tagging: OLD [...] If all NETCONF sub-operation parameters are valid, then the server will treat a tagged data node as a request to return that node to default data. NEW [...] If all NETCONF sub-operation parameters are valid, then the server will treat a wd:default="true" tagged data node as a request to return that node to default data. k): p7/p8: I am confused by this text: If the data node within the NETCONF message contains a value in this case, it MUST be equal to the schema default value. I think "this case" can be dropped. I am not sure whether the intention was to allow an edit-config without a value like this: Anyway, if a value is provided and does not match the default, it would be nice to spell out which error is to be returned. The same sentence can be found at the end of 2.3.3 on page 9. l) p8: s/'create' operation/'create' operation attribute/ s/'delete' operation/'delete' operation attribute/ Motivation: Align with RFC 4741 terminology. Note this shows up twice on p8. m) p9: Reword this sentence: OLD All data nodes that are explicitly set data MUST be saved in non- volatile storage. NEW All data nodes that have been explicitly set MUST be saved in non- volatile storage. m) p9: s/NETCONF operation request messages/NETCONF operations/ n) p9: This seems to be incorrect now that we have tagged mode: The parameter contains one of the three basic mode enumerations defined above, to request that the retrieval operation be performed using the specified defaults handling basic mode. o) Perhaps section 3.1 should become a sub-section of section 2 - this would also fix the above sentence. In particular, tagged report all also impacts the edit-config operation and not just "Retrieval of Default Data", the heading of section 3. The only difference is that the document kind of disallows report-all-tagged as a basic mode. I am also not sure why this restriction is there - I would likely prefer a report-all-tagged over a report-all basic mode server. p) p9: s/variant of 'report-all'/variant of the 'report-all'/ q) p9: broken sentence: OLD A server which supports 'report-all-tagged' MUST also accept the 'wd: default' XML attribute it is present within configuration input to the or operations. NEW A server which supports 'report-all-tagged' MUST also accept the 'wd: default' XML attribute within configuration input to the or operations. r) s/is part of NETCONF messages/is returned by NETCONF operations/ s) p11: Why are these SHOULDs and not MUSTs? If an unsupported value is used, the NETCONF server MUST return an with an element. The SHOULD be 'invalid-value', and the SHOULD be 'with-defaults- mode-not-supported'. t) p12: Is this true for all basic modes? [...] If the wd:default attribute is present and set to 'true', then the server MUST treat the new data node as a request to return that node to its default value (i.e., remove it from the database). u) p12: unclear context: If this editing mode is used, then ... It is unclear to me what "this editing mode" refers to. I suggest to be more explicit. v) p12: s/'nc:operation' attribute/operation attributes/ w) p13: Should we make the prefix ncwd so that all NETCONF related prefixes start with nc? The monitoring ID currently uses ncm. Note that the prefix also shows up in the IANA considerations. x) p14: Attempt rewrite of the first paragraph of the description: OLD "This module 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. NEW "This module defines an extension of the NETCONF protocol that allows a NETCONF client to control how default values are handled by the , , and NETCONF operations. y) p14: with-defaults-mode description rewrite: OLD "Possible modes to report default data in rpc-reply messages."; NEW "Possible modes to report default data."; z) p17: I suggest to simplify the security considerations: OLD The 'with-defaults' capability gives client control over the retrieval of particular types of XML data from a configuration datastore. They only suppress data that can already be retrieved with the standard protocol operations, and do not add any data to the configuration datastore. NEW The 'with-defaults' capability gives clients control over the retrieval of default data from a configuration datastore. The security consideration of [I-D.ietf-netconf-4741bis] apply. A) p18ff: I suggest to s/itf-status/status/g since the prefix is not used consistently and just adds noise to the examples. B) p23: s/dafault/default/ C) p1: An attempt at rewording of the abstract to avoid talking about messages: OLD [...] In other situations the NETCONF client will need this data as part of the NETCONF messages. Not all server implementations treat this default data the same way. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how defaults are handled by the server, and control whether default values are part of NETCONF messages or output to a file. NEW [...] In other situations, the NETCONF client will need default data returned as part of the result of NETCONF configuration retrieval operations. Furthermore, not all server implementations treat default data the same way. This document defines a capability-based extension of the NETCONF protocol that allows clients to discover how defaults are handled by a NETCONF server. In addition, the extension introduces an additional parameter that enables clients to control how default values are handled by , , and NETCONF operations. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bertietf@bwijnen.net Mon Jun 7 11:23:52 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F4193A67AE for ; Mon, 7 Jun 2010 11:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.157 X-Spam-Level: ** X-Spam-Status: No, score=2.157 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7svy+v592Zx for ; Mon, 7 Jun 2010 11:23:51 -0700 (PDT) Received: from relay.versatel.net (relay54.tele2.vuurwerk.nl [62.250.3.54]) by core3.amsl.com (Postfix) with ESMTP id 8CD833A6784 for ; Mon, 7 Jun 2010 11:23:49 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1OLgzF-0002Y8-Ce for netconf@ietf.org; Mon, 07 Jun 2010 20:23:49 +0200 Message-ID: <03ACA4563E064C1FB16FC566FD6C348F@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Mon, 7 Jun 2010 20:23:24 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18197 Subject: [Netconf] netconf mailing list is working again. X-BeenThere: netconf@ietf.org X-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, 07 Jun 2010 18:23:52 -0000 FYI Bert ----- Original Message ----- From: "Steve Young" To: Sent: Monday, June 07, 2010 6:31 PM Subject: FW: www.ietf.org Contact Form Submission Hi Bert, The IETF server virus scanning software received an update which caused it to keep crashing which in turn meant mail was being delayed. Everything should be flowing again now. Best regards, Steve -----Original Message----- From: Cindy Morgan [mailto:cmorgan@amsl.com] Sent: Monday, June 07, 2010 9:14 AM To: Steve Young Subject: Fwd: www.ietf.org Contact Form Submission Begin forwarded message: > From: cmorgan@amsl.com > Date: June 6, 2010 12:28:36 PM PDT > To: cmorgan@amsl.com > Subject: www.ietf.org Contact Form Submission > > This is a contact form submission report. > > Remember, you cannot REPLY to this message. You must create > a NEW message and send it to the desired receipient. > > first_name: Bert > last_name: Wijnen > email: bertietf@bwijnen.net > phone: > contact_method: Email > inquiry: It seems that we can currently not post anything to the > netconf mailing list. I just tried myself, but it does not seem to > get accepted. I have not yet received an error report (10 mins after > posting). > > But here is a report from on of our more active WG participants: > From mbj@tail-f.com Mon Jun 7 13:18:02 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 207ED3A684A for ; Mon, 7 Jun 2010 13:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[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 u7A8hti2X7Tr for ; Mon, 7 Jun 2010 13:18: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 5950C3A6832 for ; Mon, 7 Jun 2010 13:17:58 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id DBED5616001; Mon, 7 Jun 2010 22:17:57 +0200 (CEST) Date: Mon, 07 Jun 2010 22:17:57 +0200 (CEST) Message-Id: <20100607.221757.12186315.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4C0BD3FA.3060209@iwl.com> References: <4C0BD3FA.3060209@iwl.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] delete and remove operations X-BeenThere: netconf@ietf.org X-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, 07 Jun 2010 20:18:02 -0000 Hi, Andy Bierman wrote: > Hi, > > The WG needs to decide what to do about the delete operation. > It is too picky (or is it? -- see below) > > > CURRENT TEXT: > > create: The configuration data identified by the element > containing this attribute is added to the configuration if > and only if the configuration data does not already exist in > the configuration datastore. If the configuration data > exists, an element is returned with an > value of data-exists. > > delete: The configuration data identified by the element > containing this attribute is deleted in the configuration > datastore identified by the target parameter. > > > Unlike the 'create' operation, there is no error specified for delete. > I can't find any text about a data-missing error related to the > delete operation. The data-missing error-tag does not specify which > operations need to use this error-tag. Actually, it says: Description: Request could not be completed because the relevant data model content does not exist. For example, a 'replace' or 'delete' operation was attempted on data that does not exist. The 'replace' part is a bug. > According to RFC 4741 (and 4741bis), there is no requirement whatsoever > to reject a delete operation if the data is missing. This is simply > folklore, based on the intent of the WG (at that time). Hmm. Interesting. However, this is more strict in the YANG document: _ If the operation is "delete" the node is deleted if it exists. If the node does not exist, a "data-missing" error is returned. I wish we found this out earlier :( > >>> DECISION (applies to 4741bis servers only): > > ** Option A: Clarify that the delete operation is required to > return a data-missing error-tag if the delete target > node does not exist. I think this is what current servers do. > ** Option B: Clarify that the delete operation is not required to > return a data-missing error-tag if the delete target > node does not exist. > > ** Option C: Option A + add a new 'remove' operation: Yes! > NEW: (7.2, operation attribute). > > remove: The configuration data identified by the element > containing this attribute is removed from the configuration > datastore identified by the target parameter, if it exists. > /martin From andyb@iwl.com Mon Jun 7 13:33:26 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426B43A67B1 for ; Mon, 7 Jun 2010 13:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[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 GS3lOgDSjrcR for ; Mon, 7 Jun 2010 13:33:25 -0700 (PDT) Received: from smtp194.iad.emailsrvr.com (smtp194.iad.emailsrvr.com [207.97.245.194]) by core3.amsl.com (Postfix) with ESMTP id 3624C3A65A6 for ; Mon, 7 Jun 2010 13:33:25 -0700 (PDT) Received: from relay9.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id BEC971E31A7; Mon, 7 Jun 2010 16:33:25 -0400 (EDT) Received: by relay9.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 7806B1E6130; Mon, 7 Jun 2010 16:33:25 -0400 (EDT) Message-ID: <4C0D57BF.1030101@iwl.com> Date: Mon, 07 Jun 2010 13:34:07 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Martin Bjorklund References: <4C0BD3FA.3060209@iwl.com> <20100607.221757.12186315.mbj@tail-f.com> In-Reply-To: <20100607.221757.12186315.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] delete and remove operations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 20:33:26 -0000 On 06/07/2010 01:17 PM, Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: > >> Hi, >> >> The WG needs to decide what to do about the delete operation. >> It is too picky (or is it? -- see below) >> >> >> CURRENT TEXT: >> >> create: The configuration data identified by the element >> containing this attribute is added to the configuration if >> and only if the configuration data does not already exist in >> the configuration datastore. If the configuration data >> exists, an element is returned with an >> value of data-exists. >> >> delete: The configuration data identified by the element >> containing this attribute is deleted in the configuration >> datastore identified by the target parameter. >> >> >> Unlike the 'create' operation, there is no error specified for delete. >> I can't find any text about a data-missing error related to the >> delete operation. The data-missing error-tag does not specify which >> operations need to use this error-tag. >> > Actually, it says: > > Description: Request could not be completed because the relevant > data model content does not exist. For example, > a 'replace' or 'delete' operation was attempted on > data that does not exist. > > The 'replace' part is a bug. > > IMO, the 'For example' part makes it non-normative as well. The 'delete' text above needs to call out the error similar to the 'create' text. >> According to RFC 4741 (and 4741bis), there is no requirement whatsoever >> to reject a delete operation if the data is missing. This is simply >> folklore, based on the intent of the WG (at that time). >> > Hmm. Interesting. However, this is more strict in the YANG document: > > _ If the operation is "delete" the node is deleted if it exists. If > the node does not exist, a "data-missing" error is returned. > > I wish we found this out earlier :( > > oops! It should have error details like what happens when 'insert' is within the context of a delete? Is that an error or a NO-OP? >>>>> DECISION (applies to 4741bis servers only): >>>>> >> ** Option A: Clarify that the delete operation is required to >> return a data-missing error-tag if the delete target >> node does not exist. >> > I think this is what current servers do. > > yes >> ** Option B: Clarify that the delete operation is not required to >> return a data-missing error-tag if the delete target >> node does not exist. >> >> ** Option C: Option A + add a new 'remove' operation: >> > Yes! > +1 This is the most backward-compatible. > >> NEW: (7.2, operation attribute). >> >> remove: The configuration data identified by the element >> containing this attribute is removed from the configuration >> datastore identified by the target parameter, if it exists. >> >> > > /martin > > Andy From phil@juniper.net Mon Jun 7 20:19:57 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 200253A6918 for ; Mon, 7 Jun 2010 20:19:57 -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 jYOhGICvWYB9 for ; Mon, 7 Jun 2010 20:19:56 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 2AD023A67E9 for ; Mon, 7 Jun 2010 20:19:55 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTA222UEcPyFOxFwxeH5mNCiGfovf7pPb@postini.com; Mon, 07 Jun 2010 20:19:57 PDT Received: from p-emfe02-sac.jnpr.net (66.129.254.73) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Mon, 7 Jun 2010 20:18:07 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Jun 2010 20:18:06 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jun 2010 20:18:05 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Jun 2010 20:18:05 -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 o583I4D04119; Mon, 7 Jun 2010 20:18:04 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o5830OS8068690; Tue, 8 Jun 2010 03:00:24 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201006080300.o5830OS8068690@idle.juniper.net> To: In-Reply-To: <4C0D57BF.1030101@iwl.com> Date: Mon, 7 Jun 2010 23:00:24 -0400 From: Phil Shafer X-OriginalArrivalTime: 08 Jun 2010 03:18:05.0634 (UTC) FILETIME=[36165220:01CB06B9] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] delete and remove operations X-BeenThere: netconf@ietf.org X-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, 08 Jun 2010 03:19:57 -0000 Andy Bierman writes: >>> ** Option C: Option A + add a new 'remove' operation: >> Yes! >+1 >This is the most backward-compatible. This will be great in adverts: NETCONF 1.1: Now with two ways to delete stuff! Thanks, Phil From andyb@iwl.com Mon Jun 7 22:08:36 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40873A6969 for ; Mon, 7 Jun 2010 22:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynjgpVdU+1-R for ; Mon, 7 Jun 2010 22:08:31 -0700 (PDT) Received: from smtp174.dfw.emailsrvr.com (smtp174.dfw.emailsrvr.com [67.192.241.174]) by core3.amsl.com (Postfix) with ESMTP id 60FBD3A6924 for ; Mon, 7 Jun 2010 22:08:29 -0700 (PDT) Received: from relay7.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay7.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 42484CE4FCF; Tue, 8 Jun 2010 01:08:30 -0400 (EDT) Received: by relay7.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 0342ECE4D1F; Tue, 8 Jun 2010 01:08:29 -0400 (EDT) Message-ID: <4C0DD07C.1020603@iwl.com> Date: Mon, 07 Jun 2010 22:09:16 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Phil Shafer References: <201006080300.o5830OS8068690@idle.juniper.net> In-Reply-To: <201006080300.o5830OS8068690@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] delete and remove operations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 05:08:37 -0000 On 06/07/2010 08:00 PM, Phil Shafer wrote: > Andy Bierman writes: > >>>> ** Option C: Option A + add a new 'remove' operation: >>>> >>> Yes! >>> >> +1 >> This is the most backward-compatible. >> > This will be great in adverts: > > NETCONF 1.1: Now with two ways to delete stuff! > At least 2 ways to commit, discard changes, save changes to NV-store, and 3 ways to define a default. So what's your point? Create has a corresponding 'merge', but 'delete' has no corresponding operation that works even if defaults are ignored in the operation. > Thanks, > Phil > > Andy From bertietf@bwijnen.net Tue Jun 8 09:03:54 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13BCF3A68EA for ; Tue, 8 Jun 2010 09:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 it+9i6vbvJyL for ; Tue, 8 Jun 2010 09:03:53 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id EC6593A68C3 for ; Tue, 8 Jun 2010 09:03:52 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.1.103]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OM1HG-0005A5-7A for netconf@ietf.org; Tue, 08 Jun 2010 18:03:51 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OM1HG-0006Lw-1P for netconf@ietf.org; Tue, 08 Jun 2010 18:03:46 +0200 Message-ID: <4C0E69E1.9000501@bwijnen.net> Date: Tue, 08 Jun 2010 18:03:45 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd400465bed64c47c75ff5824a184cd023a X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd400465bed64c47c75ff5824a184cd023a Subject: [Netconf] End of WGLC for with-defaults X-BeenThere: netconf@ietf.org X-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, 08 Jun 2010 16:03:54 -0000 We consider WGLC for the document done. - I think I can see that another editorial revision might make sense. Andy has agreed to try to do so this week. - I think we are as close to (rough?) consensus as we can get. - So I propose - Andy does a new rev with the editorial changes and agreements we came to. - when that is out, I do another "quick last call" that people check if their suggested editorials have been addressed. - and I ask if anyone has a "strong objection" to hand it over to our AD for processing at IETF and IESG level. Bert and Mehmet From andyb@iwl.com Tue Jun 8 12:04:55 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDC2E3A6829 for ; Tue, 8 Jun 2010 12:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.315 X-Spam-Level: X-Spam-Status: No, score=-0.315 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, 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 lsOhjmBnXh5b for ; Tue, 8 Jun 2010 12:04:55 -0700 (PDT) Received: from smtp124.dfw.emailsrvr.com (smtp124.dfw.emailsrvr.com [67.192.241.124]) by core3.amsl.com (Postfix) with ESMTP id 1D8833A6930 for ; Tue, 8 Jun 2010 12:04:49 -0700 (PDT) Received: from relay12.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay12.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 22E06208068E for ; Tue, 8 Jun 2010 15:04:44 -0400 (EDT) Received: by relay12.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 038FF2080622 for ; Tue, 8 Jun 2010 15:04:43 -0400 (EDT) Message-ID: <4C0E9449.1080903@iwl.com> Date: Tue, 08 Jun 2010 12:04:41 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: netconf References: <4BFCCBCB.8020109@bwijnen.net> <20100607144529.GB2918@elstar.local> In-Reply-To: <20100607144529.GB2918@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 19:04:56 -0000 On 06/07/2010 07:45 AM, Juergen Schoenwaelder wrote: > On Wed, May 26, 2010 at 09:20:43AM +0200, Bert (IETF) Wijnen wrote: > > >> This is a(nother) formal WG Last Call for this this document. >> Please review and comment BEFORE June 6th 2010. >> > Here is my review of draft-ietf-netconf-with-defaults-08. Sorry for > being a day late but the weather last weekend was just too nice to sit > in front of my computer... > > I still believe the announcement of the basic-mode should be part of > RFC 4741bis so that _all_ RFC4741bis implementations announce their > basic default handling mode. > > I don't think the RFC number changes the conformance requirements. The IESG charters units-of-work, reviews/approves units-of-work, and the IETF community has to deal with the distributed information. > I regret that we do not solve the more general problem how we report > operational state data but instead solve via a new tagging mechanism > only for default value identification problem, which I consider a > special case of operational state data. > > I agree there is still a lot of work left to do wrt/ configuration and operational state. However, this unit-of-work is not designated to contain that functionality. I'm sure our A-Ds would not mind if some people wrote an I-D to start this work, indicating that there is sufficient interest and resources to work on the problem. Until there is a draft to discuss, there isn't much for the IETF to do. I prefer a new parameter to existing operations, like , instead of a new , or some other special operation(s). But we are not nearly ready to discuss solutions yet. (What about set-state?) > Here are all the other little comments I have on the -08 version. I > have tried to be constructive, proposing concrete rewordings for some > pieces of text. These text messages are meant to help the editor and > make my change request clear but other wordings might do equally well; > take my wording proposals just as a suggestion. > I am working on all your comments now... > /js > > Andy From j.schoenwaelder@jacobs-university.de Tue Jun 8 12:18:04 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B77A63A6806 for ; Tue, 8 Jun 2010 12:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, 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 lhmMq1oNoyzE for ; Tue, 8 Jun 2010 12:18:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 387513A67E3 for ; Tue, 8 Jun 2010 12:18:03 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 388BBC0004; Tue, 8 Jun 2010 21:18:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Z5mM85Hkf-jE; Tue, 8 Jun 2010 21:18:02 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 80FBFC0014; Tue, 8 Jun 2010 21:18:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5435212ED242; Tue, 8 Jun 2010 21:18:02 +0200 (CEST) Date: Tue, 8 Jun 2010 21:18:02 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100608191802.GA1206@elstar.local> Mail-Followup-To: Andy Bierman , netconf References: <4BFCCBCB.8020109@bwijnen.net> <20100607144529.GB2918@elstar.local> <4C0E9449.1080903@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C0E9449.1080903@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: netconf Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 19:18:04 -0000 On Tue, Jun 08, 2010 at 09:04:41PM +0200, Andy Bierman wrote: > On 06/07/2010 07:45 AM, Juergen Schoenwaelder wrote: > > On Wed, May 26, 2010 at 09:20:43AM +0200, Bert (IETF) Wijnen wrote: > > > > > >> This is a(nother) formal WG Last Call for this this document. > >> Please review and comment BEFORE June 6th 2010. > >> > > Here is my review of draft-ietf-netconf-with-defaults-08. Sorry for > > being a day late but the weather last weekend was just too nice to sit > > in front of my computer... > > > > I still believe the announcement of the basic-mode should be part of > > RFC 4741bis so that _all_ RFC4741bis implementations announce their > > basic default handling mode. > > I don't think the RFC number changes the conformance > requirements. With-defaults is not mandatory to be implemented and as a consequence a NETCONF server does not have to announce its default behaviour. At the same time, with the with-defaults document states: It can be important for a client to know exactly how a server implementation will handle default data. There are subtle differences in some protocol operations where the defaults handling behavior of the server will affect the outcome of the operation. The simplest and cleanest solution would be to fix this situation in 4741bis. Your statement about RFC numbers misses the point. And no, I do not want to discuss this here again. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andyb@iwl.com Tue Jun 8 12:41:07 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EA023A683E for ; Tue, 8 Jun 2010 12:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.654 X-Spam-Level: X-Spam-Status: No, score=-0.654 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_05=-1.11, 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 28ORR3JK3V1z for ; Tue, 8 Jun 2010 12:41:06 -0700 (PDT) Received: from smtp164.dfw.emailsrvr.com (smtp164.dfw.emailsrvr.com [67.192.241.164]) by core3.amsl.com (Postfix) with ESMTP id 4F52B3A6825 for ; Tue, 8 Jun 2010 12:41:06 -0700 (PDT) Received: from relay16.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay16.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 789C814D2F for ; Tue, 8 Jun 2010 15:41:07 -0400 (EDT) Received: by relay16.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 59FF014D03 for ; Tue, 8 Jun 2010 15:41:07 -0400 (EDT) Message-ID: <4C0E9CD1.9060705@iwl.com> Date: Tue, 08 Jun 2010 12:41:05 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: netconf References: <4BFCCBCB.8020109@bwijnen.net> <20100607144529.GB2918@elstar.local> <4C0E9449.1080903@iwl.com> <20100608191802.GA1206@elstar.local> In-Reply-To: <20100608191802.GA1206@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 19:41:07 -0000 On 06/08/2010 12:18 PM, Juergen Schoenwaelder wrote: > On Tue, Jun 08, 2010 at 09:04:41PM +0200, Andy Bierman wrote: > >> On 06/07/2010 07:45 AM, Juergen Schoenwaelder wrote: >> >>> On Wed, May 26, 2010 at 09:20:43AM +0200, Bert (IETF) Wijnen wrote: >>> >>> >>> >>>> This is a(nother) formal WG Last Call for this this document. >>>> Please review and comment BEFORE June 6th 2010. >>>> >>>> >>> Here is my review of draft-ietf-netconf-with-defaults-08. Sorry for >>> being a day late but the weather last weekend was just too nice to sit >>> in front of my computer... >>> >>> I still believe the announcement of the basic-mode should be part of >>> RFC 4741bis so that _all_ RFC4741bis implementations announce their >>> basic default handling mode. >>> >> I don't think the RFC number changes the conformance >> requirements. >> > With-defaults is not mandatory to be implemented and as a consequence > a NETCONF server does not have to announce its default behaviour. At > the same time, with the with-defaults document states: > > It can be important for a client to know exactly how a server > implementation will handle default data. There are subtle > differences in some protocol operations where the defaults handling > behavior of the server will affect the outcome of the operation. > > The simplest and cleanest solution would be to fix this situation in > 4741bis. Your statement about RFC numbers misses the point. And no, I > do not want to discuss this here again. > > Well, you brought it up again. If the WG agreed to MUST implement, it would not matter which RFC contained that text. The WG only agreed to SHOULD implement. I don't mind changing SHOULD to MUST, but that consensus call needs to be made by the co-chairs, not us. > /js > > Andy From j.schoenwaelder@jacobs-university.de Tue Jun 8 12:58:15 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65533A6804 for ; Tue, 8 Jun 2010 12:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_50=0.001, 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 eyB4WqdF+4f5 for ; Tue, 8 Jun 2010 12:58:14 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B75353A67C2 for ; Tue, 8 Jun 2010 12:58:14 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A4B97C0010; Tue, 8 Jun 2010 21:58:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KxlXycOqAFjX; Tue, 8 Jun 2010 21:58:14 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A273C0004; Tue, 8 Jun 2010 21:58:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EF60B12ED411; Tue, 8 Jun 2010 21:58:13 +0200 (CEST) Date: Tue, 8 Jun 2010 21:58:13 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100608195813.GA1333@elstar.local> Mail-Followup-To: Andy Bierman , netconf References: <4BFCCBCB.8020109@bwijnen.net> <20100607144529.GB2918@elstar.local> <4C0E9449.1080903@iwl.com> <20100608191802.GA1206@elstar.local> <4C0E9CD1.9060705@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C0E9CD1.9060705@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: netconf Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 19:58:15 -0000 On Tue, Jun 08, 2010 at 09:41:05PM +0200, Andy Bierman wrote: > Well, you brought it up again. I wanted to make it clear to the chairs where I stand. I do not want to discuss things again from scratch. > If the WG agreed to MUST implement, it would > not matter which RFC contained that text. My understanding is that the announcement of the basic mode is a no brainer implementation wise. Supporting additional parameters of 4741 operations can be more work. Hence I liked Lada's compromise proposal to move the basic mode announcement into 4741bis and leave the new with-defaults parameters as an extension to 4741bis. > The WG only agreed to SHOULD implement. > I don't mind changing SHOULD to MUST, > but that consensus call needs to be made by the co-chairs, not us. For the chairs to make concensus calls, they need to know opinions of the WG members. This is why I restated my opinion. I think we both understand the IETF process and I think we both understand the technical issue on the table. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andyb@iwl.com Tue Jun 8 13:29:53 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3363A6848 for ; Tue, 8 Jun 2010 13:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[AWL=0.836, 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 a8cC4vHGXKZz for ; Tue, 8 Jun 2010 13:29:53 -0700 (PDT) Received: from smtp134.dfw.emailsrvr.com (smtp134.dfw.emailsrvr.com [67.192.241.134]) by core3.amsl.com (Postfix) with ESMTP id EF5AC3A683F for ; Tue, 8 Jun 2010 13:29:52 -0700 (PDT) Received: from relay13.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay13.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 35BB93131237 for ; Tue, 8 Jun 2010 16:29:54 -0400 (EDT) Received: by relay13.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 11FE4313122B for ; Tue, 8 Jun 2010 16:29:54 -0400 (EDT) Message-ID: <4C0EA83E.6030100@iwl.com> Date: Tue, 08 Jun 2010 13:29:50 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: netconf References: <4BFCCBCB.8020109@bwijnen.net> <20100607144529.GB2918@elstar.local> <4C0E9449.1080903@iwl.com> <20100608191802.GA1206@elstar.local> <4C0E9CD1.9060705@iwl.com> <20100608195813.GA1333@elstar.local> In-Reply-To: <20100608195813.GA1333@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 20:29:53 -0000 On 06/08/2010 12:58 PM, Juergen Schoenwaelder wrote: > ... > For the chairs to make concensus calls, they need to know opinions of > the WG members. This is why I restated my opinion. I think we both > understand the IETF process and I think we both understand the > technical issue on the table. > > Phil and I disagree with you and Lada. A vendor chooses which RFCs it wants to support. I understand you want to force a server that supports base:1.1 to also advertise its basic-mode. I don't agree it is that important or the coupling is warranted. A server that implements the with-defaults spec MUST advertise its basic-mode. There is no reason a base:1.0 server could not advertise its basic mode as well as a base:1.1 server. If the functionality in the RFC is really needed, it will get implemented. > /js > > Andy From j.schoenwaelder@jacobs-university.de Tue Jun 8 22:00:06 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24A293A68C2 for ; Tue, 8 Jun 2010 22:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.426 X-Spam-Level: X-Spam-Status: No, score=0.426 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_50=0.001, 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 uJe32zTW4y+5 for ; Tue, 8 Jun 2010 22:00:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1E7693A68B0 for ; Tue, 8 Jun 2010 22:00:02 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA79CC0014; Wed, 9 Jun 2010 07:00:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7XzVfE1Znx2n; Wed, 9 Jun 2010 07:00:02 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6FD0FC0011; Wed, 9 Jun 2010 07:00:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E339012EDF80; Wed, 9 Jun 2010 07:00:01 +0200 (CEST) Date: Wed, 9 Jun 2010 07:00:01 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100609050001.GA2016@elstar.local> Mail-Followup-To: Andy Bierman , netconf References: <4BFCCBCB.8020109@bwijnen.net> <20100607144529.GB2918@elstar.local> <4C0E9449.1080903@iwl.com> <20100608191802.GA1206@elstar.local> <4C0E9CD1.9060705@iwl.com> <20100608195813.GA1333@elstar.local> <4C0EA83E.6030100@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C0EA83E.6030100@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: netconf Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 05:00:07 -0000 On Tue, Jun 08, 2010 at 10:29:50PM +0200, Andy Bierman wrote: > Phil and I disagree with you and Lada. > > A vendor chooses which RFCs it wants to support. > I understand you want to force a server that supports > base:1.1 to also advertise its basic-mode. This seems to be a fair summary. And I have not seen a technical reason so far why a 1.1 server should not be forced to announce its basic mode. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Tue Jun 8 22:49:42 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ED593A6885 for ; Tue, 8 Jun 2010 22:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.35 X-Spam-Level: * X-Spam-Status: No, score=1.35 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLtPimNAWgHA for ; Tue, 8 Jun 2010 22:49:36 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6EB893A68D7 for ; Tue, 8 Jun 2010 22:49:34 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 738B92CDE057; Wed, 9 Jun 2010 07:49:34 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20100609050001.GA2016@elstar.local> References: <4BFCCBCB.8020109@bwijnen.net> <20100607144529.GB2918@elstar.local> <4C0E9449.1080903@iwl.com> <20100608191802.GA1206@elstar.local> <4C0E9CD1.9060705@iwl.com> <20100608195813.GA1333@elstar.local> <4C0EA83E.6030100@iwl.com> <20100609050001.GA2016@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 09 Jun 2010 07:49:33 +0200 Message-ID: <1276062573.10433.5.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netconf Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.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, 09 Jun 2010 05:49:42 -0000 Juergen Schoenwaelder píše v St 09. 06. 2010 v 07:00 +0200: > On Tue, Jun 08, 2010 at 10:29:50PM +0200, Andy Bierman wrote: > > > Phil and I disagree with you and Lada. > > > > A vendor chooses which RFCs it wants to support. > > I understand you want to force a server that supports > > base:1.1 to also advertise its basic-mode. > > This seems to be a fair summary. And I have not seen a technical > reason so far why a 1.1 server should not be forced to announce its > basic mode. Yes, I too don't see why this relatively minor change cannot be done now and why it should cause any problems to implementors of 1.1. On the other hand, without the basic default mode advertisement the application of the concept of defaults in YANG would be tricky at best. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Jun 8 23:04:03 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58B2B3A67D3 for ; Tue, 8 Jun 2010 23:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[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 d5StBcgGQApN for ; Tue, 8 Jun 2010 23:04:02 -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 7EFEF3A677D for ; Tue, 8 Jun 2010 23:04:01 -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 11502616001; Wed, 9 Jun 2010 08:04:02 +0200 (CEST) Date: Wed, 09 Jun 2010 08:04:01 +0200 (CEST) Message-Id: <20100609.080401.98580589.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1276062573.10433.5.camel@missotis> References: <4C0EA83E.6030100@iwl.com> <20100609050001.GA2016@elstar.local> <1276062573.10433.5.camel@missotis> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.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, 09 Jun 2010 06:04:03 -0000 Hi, Ladislav Lhotka wrote: > On the other hand, without the basic default mode advertisement the > application of the concept of defaults in YANG would be tricky at best. I do not think so. There are a couple of common use cases. 1. create a new list instance (or p-container) with children with default in the YANG model - just create without the default value and all servers will do the right thing. 2. set a new value other than the default - just use the 'merge' (which is the default) operation and all servers will set the new value, regardless of previous state. 3. reset to default - use the new 'remove' operation and all servers will have the default value in use, regardless of previous state. Note that (3) requires the new proposed 'remove' operation, so it works only with 1.1 servers. There are corner cases where the server's behavior varies between the different basic modes, but these are easily avoided by client programs, as shown above. /martin From j.schoenwaelder@jacobs-university.de Tue Jun 8 23:12:44 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39A503A68DD for ; Tue, 8 Jun 2010 23:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.411 X-Spam-Level: X-Spam-Status: No, score=0.411 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_50=0.001, 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 LWyFhijB3F7E for ; Tue, 8 Jun 2010 23:12:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D182B3A68C5 for ; Tue, 8 Jun 2010 23:12:42 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E9C5C0004; Wed, 9 Jun 2010 08:12:44 +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 ieAb73G6fWEn; Wed, 9 Jun 2010 08:12:42 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9EA48C0010; Wed, 9 Jun 2010 08:12:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6C8DD12EE1FA; Wed, 9 Jun 2010 08:12:42 +0200 (CEST) Date: Wed, 9 Jun 2010 08:12:42 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100609061242.GA2134@elstar.local> Mail-Followup-To: Martin Bjorklund , "lhotka@cesnet.cz" , "netconf@ietf.org" References: <4C0EA83E.6030100@iwl.com> <20100609050001.GA2016@elstar.local> <1276062573.10433.5.camel@missotis> <20100609.080401.98580589.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100609.080401.98580589.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 06:12:44 -0000 On Wed, Jun 09, 2010 at 08:04:01AM +0200, Martin Bjorklund wrote: > Hi, > > Ladislav Lhotka wrote: > > On the other hand, without the basic default mode advertisement the > > application of the concept of defaults in YANG would be tricky at best. > > I do not think so. There are a couple of common use cases. So you are saying the text I quoted form the ID is wrong? It can be important for a client to know exactly how a server implementation will handle default data. There are subtle differences in some protocol operations where the defaults handling behavior of the server will affect the outcome of the operation. Different servers may return different configs when I configure something that includes defaults. I think it is fair to let clients know upfront what they can expect instead of letting clients discover the default handling behaviour by interpreting observed behaviour, especially if the implementation cost is close to zero on a server. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Tue Jun 8 23:27:11 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26A053A68DF for ; Tue, 8 Jun 2010 23:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.35 X-Spam-Level: * X-Spam-Status: No, score=1.35 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJ7YLZqpbTPk for ; Tue, 8 Jun 2010 23:27:10 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 470CA3A688A for ; Tue, 8 Jun 2010 23:27:09 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 816F92CDE058; Wed, 9 Jun 2010 08:27:06 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20100609.080401.98580589.mbj@tail-f.com> References: <4C0EA83E.6030100@iwl.com> <20100609050001.GA2016@elstar.local> <1276062573.10433.5.camel@missotis> <20100609.080401.98580589.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 09 Jun 2010 08:27:05 +0200 Message-ID: <1276064825.10433.17.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.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, 09 Jun 2010 06:27:11 -0000 Martin Bjorklund píše v St 09. 06. 2010 v 08:04 +0200: > Hi, > > Ladislav Lhotka wrote: > > On the other hand, without the basic default mode advertisement the > > application of the concept of defaults in YANG would be tricky at best. > > I do not think so. There are a couple of common use cases. > > 1. create a new list instance (or p-container) with children with > default in the YANG model - just create without the default value > and all servers will do the right thing. > > 2. set a new value other than the default - just use the 'merge' > (which is the default) operation and all servers will set the new > value, regardless of previous state. > > 3. reset to default - use the new 'remove' operation and all servers > will have the default value in use, regardless of previous state. > > Note that (3) requires the new proposed 'remove' operation, so it > works only with 1.1 servers. > > There are corner cases where the server's behavior varies between the > different basic modes, but these are easily avoided by client > programs, as shown above. The corner cases may cause major headaches, so if that little bit of information from the server can help to avoid them, I think it's worth it. If we accept the modal behaviour as a fact of life, it is IMO an absolute necessity that all parties be sure about which mode is used. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Jun 8 23:34:47 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01DDD3A68D7 for ; Tue, 8 Jun 2010 23:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[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 mwhJYBLuHfU2 for ; Tue, 8 Jun 2010 23:34:46 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 16AD23A67D3 for ; Tue, 8 Jun 2010 23:34:46 -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 33748616001; Wed, 9 Jun 2010 08:34:47 +0200 (CEST) Date: Wed, 09 Jun 2010 08:34:46 +0200 (CEST) Message-Id: <20100609.083446.134679304.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100609061242.GA2134@elstar.local> References: <1276062573.10433.5.camel@missotis> <20100609.080401.98580589.mbj@tail-f.com> <20100609061242.GA2134@elstar.local> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.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, 09 Jun 2010 06:34:47 -0000 Juergen Schoenwaelder wrote: > On Wed, Jun 09, 2010 at 08:04:01AM +0200, Martin Bjorklund wrote: > > Hi, > > > > Ladislav Lhotka wrote: > > > On the other hand, without the basic default mode advertisement the > > > application of the concept of defaults in YANG would be tricky at best. > > > > I do not think so. There are a couple of common use cases. > > So you are saying the text I quoted form the ID is wrong? > > It can be important for a client to know exactly how a server > implementation will handle default data. There are subtle > differences in some protocol operations where the defaults handling > behavior of the server will affect the outcome of the operation. No, this is correct. There _are_ subtle differences. But with the addition of the 'remove' operation, these differences are easily avoided in most common cases. (In fact, it is probably easier to write generic client code that works on all servers instead of having to switch on the basic mode.) Are there any use cases where the client cannot do the right thing without knowing the basic mode? > Different servers may return different configs when I configure > something that includes defaults. I think it is fair to let clients > know upfront what they can expect instead of letting clients discover > the default handling behaviour by interpreting observed behaviour, > especially if the implementation cost is close to zero on a server. Agreed. /martin From lhotka@cesnet.cz Wed Jun 9 00:07:27 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F583A67D3 for ; Wed, 9 Jun 2010 00:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.35 X-Spam-Level: * X-Spam-Status: No, score=1.35 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFf1WEJQKK1D for ; Wed, 9 Jun 2010 00:07:12 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 643E23A68F5 for ; Wed, 9 Jun 2010 00:07:06 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 5651B2CDE057; Wed, 9 Jun 2010 09:07:04 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20100609.083446.134679304.mbj@tail-f.com> References: <1276062573.10433.5.camel@missotis> <20100609.080401.98580589.mbj@tail-f.com> <20100609061242.GA2134@elstar.local> <20100609.083446.134679304.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 09 Jun 2010 09:07:03 +0200 Message-ID: <1276067223.10433.39.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.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, 09 Jun 2010 07:07:28 -0000 Martin Bjorklund píše v St 09. 06. 2010 v 08:34 +0200: > Juergen Schoenwaelder wrote: > > On Wed, Jun 09, 2010 at 08:04:01AM +0200, Martin Bjorklund wrote: > > > Hi, > > > > > > Ladislav Lhotka wrote: > > > > On the other hand, without the basic default mode advertisement the > > > > application of the concept of defaults in YANG would be tricky at best. > > > > > > I do not think so. There are a couple of common use cases. > > > > So you are saying the text I quoted form the ID is wrong? > > > > It can be important for a client to know exactly how a server > > implementation will handle default data. There are subtle > > differences in some protocol operations where the defaults handling > > behavior of the server will affect the outcome of the operation. > > No, this is correct. There _are_ subtle differences. But with the > addition of the 'remove' operation, these differences are easily > avoided in most common cases. (In fact, it is probably easier to > write generic client code that works on all servers instead of having > to switch on the basic mode.) You are assuming that everybody writes clever and bug-free programs. We now have the opportunity to decrease the entropy by an explicit protocol signalling, which decreases the expected level of cleverness on the client side. Moreover, the reason why something works for one server and fails for another will be evident from the protocol operation, which is IMO a very good thing. Lada > > Are there any use cases where the client cannot do the right thing > without knowing the basic mode? > > > > Different servers may return different configs when I configure > > something that includes defaults. I think it is fair to let clients > > know upfront what they can expect instead of letting clients discover > > the default handling behaviour by interpreting observed behaviour, > > especially if the implementation cost is close to zero on a server. > > Agreed. > > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Jun 9 00:34:28 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2ECA3A6915 for ; Wed, 9 Jun 2010 00:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[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 QtC5kPEgaoSd for ; Wed, 9 Jun 2010 00:34:28 -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 097F33A690A for ; Wed, 9 Jun 2010 00:34:28 -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 59A67616001; Wed, 9 Jun 2010 09:34:28 +0200 (CEST) Date: Wed, 09 Jun 2010 09:34:27 +0200 (CEST) Message-Id: <20100609.093427.39045518.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1276067223.10433.39.camel@missotis> References: <20100609061242.GA2134@elstar.local> <20100609.083446.134679304.mbj@tail-f.com> <1276067223.10433.39.camel@missotis> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.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, 09 Jun 2010 07:34:29 -0000 Ladislav Lhotka wrote: > Martin Bjorklund p=ED=A8e v St 09. 06. 2010 v 08:34 +0200: > > Juergen Schoenwaelder wrote:= > > > On Wed, Jun 09, 2010 at 08:04:01AM +0200, Martin Bjorklund wrote:= > > > > Hi, > > > > = > > > > Ladislav Lhotka wrote: > > > > > On the other hand, without the basic default mode advertiseme= nt the > > > > > application of the concept of defaults in YANG would be trick= y at best. > > > > = > > > > I do not think so. There are a couple of common use cases. > > > = > > > So you are saying the text I quoted form the ID is wrong? > > > = > > > It can be important for a client to know exactly how a server > > > implementation will handle default data. There are subtle > > > differences in some protocol operations where the defaults han= dling > > > behavior of the server will affect the outcome of the operatio= n. > > = > > No, this is correct. There _are_ subtle differences. But with the= > > addition of the 'remove' operation, these differences are easily > > avoided in most common cases. (In fact, it is probably easier to > > write generic client code that works on all servers instead of havi= ng > > to switch on the basic mode.) > = > You are assuming that everybody writes clever and bug-free programs. = We > now have the opportunity to decrease the entropy by an explicit proto= col > signalling, which decreases the expected level of cleverness on the > client side. If you write complex code that adjusts its behavior depending on the server, when you can write simple code that works for all servers, you probably increase the opportunity for bugs... But don't get me wrong. I think :with-defaults is useful. I'm just saying that your statement that handling defaults is "tricky at best" is not correct - provided we add the 'remove' operation. /martin From j.schoenwaelder@jacobs-university.de Wed Jun 9 00:45:25 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B35FC3A6915 for ; Wed, 9 Jun 2010 00:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_50=0.001, 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 LB4BjqG3gtel for ; Wed, 9 Jun 2010 00:45:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E1AAD3A6849 for ; Wed, 9 Jun 2010 00:45:23 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 259F6C0010; Wed, 9 Jun 2010 09:45:25 +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 WcFVE7ImfoIr; Wed, 9 Jun 2010 09:45:24 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D64EFC0004; Wed, 9 Jun 2010 09:45:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A335C12EE49D; Wed, 9 Jun 2010 09:45:23 +0200 (CEST) Date: Wed, 9 Jun 2010 09:45:23 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100609074523.GA2289@elstar.local> Mail-Followup-To: Martin Bjorklund , "lhotka@cesnet.cz" , "netconf@ietf.org" References: <20100609061242.GA2134@elstar.local> <20100609.083446.134679304.mbj@tail-f.com> <1276067223.10433.39.camel@missotis> <20100609.093427.39045518.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100609.093427.39045518.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 07:45:25 -0000 On Wed, Jun 09, 2010 at 09:34:27AM +0200, Martin Bjorklund wrote: > But don't get me wrong. I think :with-defaults is useful. I'm just > saying that your statement that handling defaults is "tricky at best" > is not correct - provided we add the 'remove' operation. This is kind of interesting - you argue that the difference in the default handling requires us to add the 'remove' operation while at the same time you seem to argue against announcing the basic default handling mode, which has zero costs implementation wise. So obviously, what happens if you use 'delete' depends on the basic mode. Hence, I think it is fair to announce what the basic mode is. Your argument seems to be one should not use protocol features where the basic-mode makes a difference. The logical consequence would then be for me to remove or deprecate those operations. If we leave these operations in, I think it is just fair if the server announces what these operations will do. /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 Wed Jun 9 00:54:51 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56A9F3A6849 for ; Wed, 9 Jun 2010 00:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 mYQu7bQyT3Cu for ; Wed, 9 Jun 2010 00:54:50 -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 79E543A6924 for ; Wed, 9 Jun 2010 00:54:50 -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 418E5616001; Wed, 9 Jun 2010 09:54:51 +0200 (CEST) Date: Wed, 09 Jun 2010 09:54:50 +0200 (CEST) Message-Id: <20100609.095450.197376501.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100609074523.GA2289@elstar.local> References: <1276067223.10433.39.camel@missotis> <20100609.093427.39045518.mbj@tail-f.com> <20100609074523.GA2289@elstar.local> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.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, 09 Jun 2010 07:54:51 -0000 Juergen Schoenwaelder wrote: > On Wed, Jun 09, 2010 at 09:34:27AM +0200, Martin Bjorklund wrote: > > > But don't get me wrong. I think :with-defaults is useful. I'm just > > saying that your statement that handling defaults is "tricky at best" > > is not correct - provided we add the 'remove' operation. > > This is kind of interesting - you argue that the difference in the > default handling requires us to add the 'remove' operation while at > the same time you seem to argue against announcing the basic default > handling mode No, I'm arguing that it is not tricky to handle the different behaviors in edit-config. > which has zero costs implementation wise. So obviously, > what happens if you use 'delete' depends on the basic mode. Hence, I > think it is fair to announce what the basic mode is. > > Your argument seems to be one should not use protocol features where > the basic-mode makes a difference. The logical consequence would then > be for me to remove or deprecate those operations. If we leave these > operations in, I think it is just fair if the server announces what > these operations will do. And I agree. I have never argued that we should not do :with-defaults. Since there are differences, the server should let the client know its basic mode. But in real code, I doubt it will have much impact. If you know a use case where it will, please prove me wrong! /martin From lhotka@cesnet.cz Wed Jun 9 01:00:56 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 828063A691B for ; Wed, 9 Jun 2010 01:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.35 X-Spam-Level: * X-Spam-Status: No, score=1.35 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id defrYeSX1MJQ for ; Wed, 9 Jun 2010 01:00:55 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B4E653A691E for ; Wed, 9 Jun 2010 01:00:55 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 28DAC2CDE058; Wed, 9 Jun 2010 10:00:56 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20100609.093427.39045518.mbj@tail-f.com> References: <20100609061242.GA2134@elstar.local> <20100609.083446.134679304.mbj@tail-f.com> <1276067223.10433.39.camel@missotis> <20100609.093427.39045518.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 09 Jun 2010 10:00:55 +0200 Message-ID: <1276070455.10433.47.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.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, 09 Jun 2010 08:00:56 -0000 Martin Bjorklund píše v St 09. 06. 2010 v 09:34 +0200: > But don't get me wrong. I think :with-defaults is useful. I'm just > saying that your statement that handling defaults is "tricky at best" > is not correct - provided we add the 'remove' operation. It definitely is tricky, as long as there are operations where the client cannot predict the outcome beforehand. Imagine that e.g. SQL worked this way. Lada > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Wed Jun 9 01:06:09 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E26C53A6919 for ; Wed, 9 Jun 2010 01:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.462 X-Spam-Level: X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_20=-0.74, 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 TKmaZgEJ7I7p for ; Wed, 9 Jun 2010 01:06:08 -0700 (PDT) Received: from smtp204.iad.emailsrvr.com (smtp204.iad.emailsrvr.com [207.97.245.204]) by core3.amsl.com (Postfix) with ESMTP id 7105B3A691B for ; Wed, 9 Jun 2010 01:06:08 -0700 (PDT) Received: from relay10.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay10.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 9B6C71EBDC9; Wed, 9 Jun 2010 04:06:09 -0400 (EDT) Received: by relay10.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 325851EBBE3; Wed, 9 Jun 2010 04:06:09 -0400 (EDT) Message-ID: <4C0F4B69.9080600@iwl.com> Date: Wed, 09 Jun 2010 01:06:01 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Martin Bjorklund References: <1276067223.10433.39.camel@missotis> <20100609.093427.39045518.mbj@tail-f.com> <20100609074523.GA2289@elstar.local> <20100609.095450.197376501.mbj@tail-f.com> In-Reply-To: <20100609.095450.197376501.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 08:06:10 -0000 On 06/09/2010 12:54 AM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > >> On Wed, Jun 09, 2010 at 09:34:27AM +0200, Martin Bjorklund wrote: >> >> >>> But don't get me wrong. I think :with-defaults is useful. I'm just >>> saying that your statement that handling defaults is "tricky at best" >>> is not correct - provided we add the 'remove' operation. >>> >> This is kind of interesting - you argue that the difference in the >> default handling requires us to add the 'remove' operation while at >> the same time you seem to argue against announcing the basic default >> handling mode >> > No, I'm arguing that it is not tricky to handle the different > behaviors in edit-config. > > I do not see the importance of special-case code on the client to deal with creating and deleting nodes that have a default value. The client has to check if the data node exists first for a node without a schema default. I don't know why an application would bother with lots of special-case (not tricky) code when 'merge' and 'remove' solve the problem in every usage scenario. Once you get that code working, why bother with the special-case code? >> which has zero costs implementation wise. So obviously, >> what happens if you use 'delete' depends on the basic mode. Hence, I >> think it is fair to announce what the basic mode is. >> >> Your argument seems to be one should not use protocol features where >> the basic-mode makes a difference. The logical consequence would then >> be for me to remove or deprecate those operations. If we leave these >> operations in, I think it is just fair if the server announces what >> these operations will do. >> > And I agree. I have never argued that we should not do > :with-defaults. Since there are differences, the server should let > the client know its basic mode. But in real code, I doubt it will > have much impact. If you know a use case where it will, please prove > me wrong! > I agree. I think the client has to go out of its way to turn with-defaults basic-mode advertisement into a critical piece of information. > > /martin > Andy From mbj@tail-f.com Wed Jun 9 01:24:29 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ACCA3A6933 for ; Wed, 9 Jun 2010 01:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.746 X-Spam-Level: X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[AWL=1.300, 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 UUdi8a4sYO6z for ; Wed, 9 Jun 2010 01:24:28 -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 1AD303A6934 for ; Wed, 9 Jun 2010 01:24:28 -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 2528D616001; Wed, 9 Jun 2010 10:24:29 +0200 (CEST) Date: Wed, 09 Jun 2010 10:24:28 +0200 (CEST) Message-Id: <20100609.102428.116023269.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4C0F4B69.9080600@iwl.com> References: <20100609074523.GA2289@elstar.local> <20100609.095450.197376501.mbj@tail-f.com> <4C0F4B69.9080600@iwl.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.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, 09 Jun 2010 08:24:29 -0000 Andy Bierman wrote: > On 06/09/2010 12:54 AM, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > >> On Wed, Jun 09, 2010 at 09:34:27AM +0200, Martin Bjorklund wrote: > >> > >> > >>> But don't get me wrong. I think :with-defaults is useful. I'm just > >>> saying that your statement that handling defaults is "tricky at best" > >>> is not correct - provided we add the 'remove' operation. > >>> > >> This is kind of interesting - you argue that the difference in the > >> default handling requires us to add the 'remove' operation while at > >> the same time you seem to argue against announcing the basic default > >> handling mode > >> > > No, I'm arguing that it is not tricky to handle the different > > behaviors in edit-config. I meant "it is not tricky to handle the different behaviors of servers in edit-config, without special code, since the simple, generic code will work for all servers". So we agree. /martin From j.schoenwaelder@jacobs-university.de Wed Jun 9 01:29:44 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26DC33A691E for ; Wed, 9 Jun 2010 01:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_50=0.001, 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 8yloxYtdillG for ; Wed, 9 Jun 2010 01:29:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 048BE3A63CA for ; Wed, 9 Jun 2010 01:29:43 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3DEFCC0011; Wed, 9 Jun 2010 10:29:44 +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 ikmZC67F9Bza; Wed, 9 Jun 2010 10:29:43 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12D18C0004; Wed, 9 Jun 2010 10:29:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A906512EE77A; Wed, 9 Jun 2010 10:29:42 +0200 (CEST) Date: Wed, 9 Jun 2010 10:29:42 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20100609082942.GA2451@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , "netconf@ietf.org" References: <20100609061242.GA2134@elstar.local> <20100609.083446.134679304.mbj@tail-f.com> <1276067223.10433.39.camel@missotis> <20100609.093427.39045518.mbj@tail-f.com> <1276070455.10433.47.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1276070455.10433.47.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 08:29:44 -0000 On Wed, Jun 09, 2010 at 10:00:55AM +0200, Ladislav Lhotka wrote: > Martin Bjorklund p????e v St 09. 06. 2010 v 09:34 +0200: > > But don't get me wrong. I think :with-defaults is useful. I'm just > > saying that your statement that handling defaults is "tricky at best" > > is not correct - provided we add the 'remove' operation. > > It definitely is tricky, as long as there are operations where the > client cannot predict the outcome beforehand. Imagine that e.g. SQL > worked this way. I agree with you but others say "as long as there is a way to work around it, we can save the announcement of the basic-mode in the hello exchange". I do not buy this argument since the result of a simple get-config depends on the basic-mode - its as simple as that. If I will have boxes from Juniper and Cisco, they will behave differently and I think it is just fair that these boxes tell operators what behaviour to expect. The bottom line is that NETCONF servers behave differently. Lada and I like to mandate that NETCONF 1.1 servers announce these differences during the hello exchange to make the behaviour one can expect obvious. Others like to hide the differences, leaving it to the introduction of additional operations and smart client design to take care of the differences (even though that does not change the fact that a plain get-config returns different results for the same config on different basic-mode servers). I do not know what the chairs will read out of this discussion. At least this split of opinions in the WG needs to be carefully and fairly explained in the protocol writeup for the IESG so that the IESG has a decent understanding of the situation in the WG. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Wed Jun 9 01:45:45 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF7928C0E9 for ; Wed, 9 Jun 2010 01:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.257 X-Spam-Level: * X-Spam-Status: No, score=1.257 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceJvbGCKSMJY for ; Wed, 9 Jun 2010 01:45:44 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id BBF8C3A693F for ; Wed, 9 Jun 2010 01:45:39 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 4840A2CDE058; Wed, 9 Jun 2010 10:45:40 +0200 (CEST) From: Ladislav Lhotka To: andyb@iwl.com In-Reply-To: <4C0F4B69.9080600@iwl.com> References: <1276067223.10433.39.camel@missotis> <20100609.093427.39045518.mbj@tail-f.com> <20100609074523.GA2289@elstar.local> <20100609.095450.197376501.mbj@tail-f.com> <4C0F4B69.9080600@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 09 Jun 2010 10:45:39 +0200 Message-ID: <1276073139.10433.68.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.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, 09 Jun 2010 08:45:45 -0000 Andy Bierman píše v St 09. 06. 2010 v 01:06 -0700: > I do not see the importance of special-case code on the client > to deal with creating and deleting nodes that have a default > value. The client has to check if the data node exists > first for a node without a schema default. > > I don't know why an application would bother with lots > of special-case (not tricky) code when 'merge' and 'remove' > solve the problem in every usage scenario. Once you get that > code working, why bother with the special-case code? Then remove the "create" and "delete" operations, or restrict them e.g. to "create-list-entry". How can a poor developer know just by reading RFC4741bis that "merge" is OK but "create" may not be? create: The configuration data identified by the element containing this attribute is added to the configuration if and only if the configuration data does not already exist in the configuration datastore. If the configuration data exists, an element is returned with an value of data-exists. The problem here is that the client cannot always determine from a retrieved configuration whether "configuration data exists" or not, as someone who hasn't followed the discussions in the ML might easily assume. Lada > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Jun 9 04:01:27 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 678353A6962 for ; Wed, 9 Jun 2010 04:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.006 X-Spam-Level: X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[AWL=1.040, 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 iExAV3epVyyZ for ; Wed, 9 Jun 2010 04:01:22 -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 5EAF73A6966 for ; Wed, 9 Jun 2010 04:01:20 -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 9CEBA616001; Wed, 9 Jun 2010 13:01:20 +0200 (CEST) Date: Wed, 09 Jun 2010 13:01:20 +0200 (CEST) Message-Id: <20100609.130120.191856352.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100609082942.GA2451@elstar.local> References: <20100609.093427.39045518.mbj@tail-f.com> <1276070455.10433.47.camel@missotis> <20100609082942.GA2451@elstar.local> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.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, 09 Jun 2010 11:01:27 -0000 Juergen Schoenwaelder wrote: > On Wed, Jun 09, 2010 at 10:00:55AM +0200, Ladislav Lhotka wrote: > > Martin Bjorklund p????e v St 09. 06. 2010 v 09:34 +0200: > > > But don't get me wrong. I think :with-defaults is useful. I'm just > > > saying that your statement that handling defaults is "tricky at best" > > > is not correct - provided we add the 'remove' operation. > > > > It definitely is tricky, as long as there are operations where the > > client cannot predict the outcome beforehand. Imagine that e.g. SQL > > worked this way. > > I agree with you but others say "as long as there is a way to work > around it, we can save the announcement of the basic-mode in the hello > exchange". I have never said that. I agree that with-defaults is useful, and I have no objections to moving the basic-mode advertisment into 4741bis. My only point is that writing client code without knowing the basic mode is not as tricky as you might think. /martin From lhotka@cesnet.cz Wed Jun 9 04:37:09 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D056728C100 for ; Wed, 9 Jun 2010 04:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.031 X-Spam-Level: X-Spam-Status: No, score=0.031 tagged_above=-999 required=5 tests=[AWL=1.281, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2bp-n1fx2CE for ; Wed, 9 Jun 2010 04:37:09 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 196B728C11B for ; Wed, 9 Jun 2010 04:32:40 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id B15B62CDE058; Wed, 9 Jun 2010 13:32:39 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20100609.130120.191856352.mbj@tail-f.com> References: <20100609.093427.39045518.mbj@tail-f.com> <1276070455.10433.47.camel@missotis> <20100609082942.GA2451@elstar.local> <20100609.130120.191856352.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 09 Jun 2010 13:32:38 +0200 Message-ID: <1276083158.10433.76.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.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, 09 Jun 2010 11:37:10 -0000 Martin Bjorklund píše v St 09. 06. 2010 v 13:01 +0200: > Juergen Schoenwaelder wrote: > > On Wed, Jun 09, 2010 at 10:00:55AM +0200, Ladislav Lhotka wrote: > > > Martin Bjorklund p????e v St 09. 06. 2010 v 09:34 +0200: > > > > But don't get me wrong. I think :with-defaults is useful. I'm just > > > > saying that your statement that handling defaults is "tricky at best" > > > > is not correct - provided we add the 'remove' operation. > > > > > > It definitely is tricky, as long as there are operations where the > > > client cannot predict the outcome beforehand. Imagine that e.g. SQL > > > worked this way. > > > > I agree with you but others say "as long as there is a way to work > > around it, we can save the announcement of the basic-mode in the hello > > exchange". > > I have never said that. I agree that with-defaults is useful, and I > have no objections to moving the basic-mode advertisment into > 4741bis. OK, so we've got (at least) three supporters of this change. Lada > > My only point is that writing client code without knowing the basic > mode is not as tricky as you might think. > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Wed Jun 9 05:41:19 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C272228C0F2 for ; Wed, 9 Jun 2010 05:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.596 X-Spam-Level: X-Spam-Status: No, score=-1.596 tagged_above=-999 required=5 tests=[AWL=0.669, 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 Gv6lADWtZQh9 for ; Wed, 9 Jun 2010 05:41:19 -0700 (PDT) Received: from smtp154.dfw.emailsrvr.com (smtp154.dfw.emailsrvr.com [67.192.241.154]) by core3.amsl.com (Postfix) with ESMTP id 062663A68A5 for ; Wed, 9 Jun 2010 05:41:19 -0700 (PDT) Received: from relay5.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay5.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 2A6A03EF27D; Wed, 9 Jun 2010 08:41:20 -0400 (EDT) Received: by relay5.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 8A9223F1BE0; Wed, 9 Jun 2010 08:41:19 -0400 (EDT) Message-ID: <4C0F8BE4.7080700@iwl.com> Date: Wed, 09 Jun 2010 05:41:08 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ladislav Lhotka References: <20100609.093427.39045518.mbj@tail-f.com> <1276070455.10433.47.camel@missotis> <20100609082942.GA2451@elstar.local> <20100609.130120.191856352.mbj@tail-f.com> <1276083158.10433.76.camel@missotis> In-Reply-To: <1276083158.10433.76.camel@missotis> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 12:41:19 -0000 On 06/09/2010 04:32 AM, Ladislav Lhotka wrote: > Martin Bjorklund píše v St 09. 06. 2010 v 13:01 +0200: > >> Juergen Schoenwaelder wrote: >> >>> On Wed, Jun 09, 2010 at 10:00:55AM +0200, Ladislav Lhotka wrote: >>> >>>> Martin Bjorklund p????e v St 09. 06. 2010 v 09:34 +0200: >>>> >>>>> But don't get me wrong. I think :with-defaults is useful. I'm just >>>>> saying that your statement that handling defaults is "tricky at best" >>>>> is not correct - provided we add the 'remove' operation. >>>>> >>>> It definitely is tricky, as long as there are operations where the >>>> client cannot predict the outcome beforehand. Imagine that e.g. SQL >>>> worked this way. >>>> >>> I agree with you but others say "as long as there is a way to work >>> around it, we can save the announcement of the basic-mode in the hello >>> exchange". >>> >> I have never said that. I agree that with-defaults is useful, and I >> have no objections to moving the basic-mode advertisment into >> 4741bis. >> > OK, so we've got (at least) three supporters of this change. > > I would really like to understand why you think rearranging the RFCs will change the conformance. Currently, the server SHOULD advertise the basic-mode. Moving the text to another RFC is not going to change that SHOULD. It can change from a SHOULD to a MUST, regardless of the RFC number -- but the WG has not agreed the server MUST advertise this capability. I do not agree with either of your proposals: 1) move the basic-mode advertisement to 4741bis 2) change conformance from SHOULD to MUST I fail to see the point of (1), with or without (2). Balazs, Phil, and I have stated we are against moving the RFCs around. Nobody seems to care if and when this work ever gets finished, not that being 150% late counts in the IETF. Why is it even relevant that conformance to 4741bis be considered here? Why can't a 1.0 server advertise the with-defaults capability, not just a 1.1 server? (Some implementations of 4741 already do this.) > Lada > Andy From j.schoenwaelder@jacobs-university.de Wed Jun 9 07:01:36 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60DA43A679F for ; Wed, 9 Jun 2010 07:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.388 X-Spam-Level: X-Spam-Status: No, score=0.388 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_50=0.001, 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 ZIuH1yvXGHsS for ; Wed, 9 Jun 2010 07:01:32 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 562963A6974 for ; Wed, 9 Jun 2010 07:01:32 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 09E2CC0010; Wed, 9 Jun 2010 16:01:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id sklX+Qsyococ; Wed, 9 Jun 2010 16:01:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B4E45C0004; Wed, 9 Jun 2010 16:01:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AFA3412F011F; Wed, 9 Jun 2010 16:01:30 +0200 (CEST) Date: Wed, 9 Jun 2010 16:01:29 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100609140128.GA9694@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , "netconf@ietf.org" References: <20100609.093427.39045518.mbj@tail-f.com> <1276070455.10433.47.camel@missotis> <20100609082942.GA2451@elstar.local> <20100609.130120.191856352.mbj@tail-f.com> <1276083158.10433.76.camel@missotis> <4C0F8BE4.7080700@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C0F8BE4.7080700@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 14:01:36 -0000 On Wed, Jun 09, 2010 at 02:41:08PM +0200, Andy Bierman wrote: > I would really like to understand why you think rearranging the > RFCs will change the conformance. Currently, the server SHOULD > advertise the basic-mode. Moving the text to another RFC is not > going to change that SHOULD. It can change from a SHOULD > to a MUST, regardless of the RFC number -- but the WG has not > agreed the server MUST advertise this capability. > > I do not agree with either of your proposals: > 1) move the basic-mode advertisement to 4741bis > 2) change conformance from SHOULD to MUST > > I fail to see the point of (1), with or without (2). > Balazs, Phil, and I have stated we are against moving the > RFCs around. If the basic-mode advertisement is part of 4741bis, then a 4741bis compliant server has to announce its basic mode. A MUST in WD will not establish a MUST for a 4741bis compliant server - unless we state a "MUST also implement WD" in 4741bis and we create a wired dependency between two documents. > Nobody seems to care if and when this work ever gets finished, not > that being 150% late counts in the IETF. The big delay is caused by all the discussions we had and still have around defaults, not the edits. Anyway, WD won't appear as an RFC before 4741bis appears as an RFC since WD normatively depends on 4741bis. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Wed Jun 9 08:53:25 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C7433A6814 for ; Wed, 9 Jun 2010 08:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.118 X-Spam-Level: * X-Spam-Status: No, score=1.118 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkni2GT1tZSY for ; Wed, 9 Jun 2010 08:53:24 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id F26C13A679F for ; Wed, 9 Jun 2010 08:53:23 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 5EAEE2CDE05B; Wed, 9 Jun 2010 17:53:24 +0200 (CEST) From: Ladislav Lhotka To: andyb@iwl.com In-Reply-To: <4C0F8BE4.7080700@iwl.com> References: <20100609.093427.39045518.mbj@tail-f.com> <1276070455.10433.47.camel@missotis> <20100609082942.GA2451@elstar.local> <20100609.130120.191856352.mbj@tail-f.com> <1276083158.10433.76.camel@missotis> <4C0F8BE4.7080700@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 09 Jun 2010 17:53:23 +0200 Message-ID: <1276098803.10433.107.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.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, 09 Jun 2010 15:53:25 -0000 Andy Bierman píše v St 09. 06. 2010 v 05:41 -0700: > I would really like to understand why you think rearranging the > RFCs will change the conformance. Currently, the server SHOULD > advertise the basic-mode. Moving the text to another RFC is not But SHOULD/MUST every implementor of RFC4741bis also take into account the with-defaults spec? If not, the "SHOULD advertize the basic-mode" is quite moot. > going to change that SHOULD. It can change from a SHOULD > to a MUST, regardless of the RFC number -- but the WG has not > agreed the server MUST advertise this capability. > > I do not agree with either of your proposals: > 1) move the basic-mode advertisement to 4741bis > 2) change conformance from SHOULD to MUST > > I fail to see the point of (1), with or without (2). Two points: 1. All important behaviour of a NETCONF server is stated in a single document. 2. RFC4741bis tries to avoid touching the defaults-related issues but then important statements like "configuration data exists" are quite vague. I think RFC4741bis should face that issue, explain the defaults-handling modes and what "data existence" really means in each of the modes, and also stipulate the basic-mode advertisement. > Balazs, Phil, and I have stated we are against moving the I haven't heard anything from Balazs since quite a long time. > RFCs around. Nobody seems to care if and when this work > ever gets finished, not that being 150% late counts in the IETF. Getting it right is important, too. > > Why is it even relevant that conformance to 4741bis be > considered here? Why can't a 1.0 server advertise > the with-defaults capability, not just a 1.1 server? > (Some implementations of 4741 already do this.) What if a server does NOT advertise with-defaults? Then the basic-mode cannot be signalled. On the other hand, if the server does advertise with-defaults, it also has to accept the parameter, right? This is something not everybody is ready to do whereas the basic mode advertisement is a no-brainer. Lada > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Wed Jun 9 09:16:30 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2943A6990 for ; Wed, 9 Jun 2010 09:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_50=0.001, 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 IyoPukU2QTqR for ; Wed, 9 Jun 2010 09:16:28 -0700 (PDT) Received: from smtp204.iad.emailsrvr.com (smtp204.iad.emailsrvr.com [207.97.245.204]) by core3.amsl.com (Postfix) with ESMTP id 2EAD73A6995 for ; Wed, 9 Jun 2010 09:16:23 -0700 (PDT) Received: from relay30.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay30.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 320211B40B7; Wed, 9 Jun 2010 12:16:25 -0400 (EDT) Received: by relay30.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id CC45E1B408B; Wed, 9 Jun 2010 12:16:24 -0400 (EDT) Message-ID: <4C0FBE4D.2030504@iwl.com> Date: Wed, 09 Jun 2010 09:16:13 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ladislav Lhotka References: <20100609.093427.39045518.mbj@tail-f.com> <1276070455.10433.47.camel@missotis> <20100609082942.GA2451@elstar.local> <20100609.130120.191856352.mbj@tail-f.com> <1276083158.10433.76.camel@missotis> <4C0F8BE4.7080700@iwl.com> <1276098803.10433.107.camel@missotis> In-Reply-To: <1276098803.10433.107.camel@missotis> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 16:16:31 -0000 On 06/09/2010 08:53 AM, Ladislav Lhotka wrote: > Andy Bierman píše v St 09. 06. 2010 v 05:41 -0700: > >> I would really like to understand why you think rearranging the >> RFCs will change the conformance. Currently, the server SHOULD >> advertise the basic-mode. Moving the text to another RFC is not >> > But SHOULD/MUST every implementor of RFC4741bis also take into account > the with-defaults spec? If not, the "SHOULD advertize the basic-mode" is > quite moot. > > Martin and I have pointed out why knowing the basic-mode is not critical, especially when we add the 'remove' operation that nobody has objected to adding. The assertion that "The client MUST know the basic-mode" is false. >> going to change that SHOULD. It can change from a SHOULD >> to a MUST, regardless of the RFC number -- but the WG has not >> agreed the server MUST advertise this capability. >> >> I do not agree with either of your proposals: >> 1) move the basic-mode advertisement to 4741bis >> 2) change conformance from SHOULD to MUST >> >> I fail to see the point of (1), with or without (2). >> > Two points: > > 1. All important behaviour of a NETCONF server is stated in a single > document. > This is a subjective assertion and cannot be proved. Not everybody agrees basic-mode advertisement is important. > 2. RFC4741bis tries to avoid touching the defaults-related issues but > then important statements like "configuration data exists" are quite > vague. I think RFC4741bis should face that issue, explain the > defaults-handling modes and what "data existence" really means in > each of the modes, and also stipulate the basic-mode advertisement. > > >> Balazs, Phil, and I have stated we are against moving the >> > I haven't heard anything from Balazs since quite a long time. > > >> RFCs around. Nobody seems to care if and when this work >> ever gets finished, not that being 150% late counts in the IETF. >> > Getting it right is important, too. > That's what the IESG keeps telling itself to justify the awful track record. > >> Why is it even relevant that conformance to 4741bis be >> considered here? Why can't a 1.0 server advertise >> the with-defaults capability, not just a 1.1 server? >> (Some implementations of 4741 already do this.) >> > What if a server does NOT advertise with-defaults? Then the basic-mode > cannot be signalled. On the other hand, if the server does advertise > with-defaults, it also has to accept the parameter, > right? This is something not everybody is ready to do whereas the basic > mode advertisement is a no-brainer. > As Phil pointed out many times -- without the basic-mode advertisement you can retrieve a node and know for sure if create/delete should work. This is what has to happen for nodes without schema-defaults, and for multi-app NM environments anyway, so the code is already there. > Lada > Andy From lhotka@cesnet.cz Wed Jun 9 09:33:36 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2BEA3A69A2 for ; Wed, 9 Jun 2010 09:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.595 X-Spam-Level: X-Spam-Status: No, score=0.595 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHYc22RKQNWs for ; Wed, 9 Jun 2010 09:33:35 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 21B4B3A6971 for ; Wed, 9 Jun 2010 09:33:35 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 0ACAF2CDE058; Wed, 9 Jun 2010 18:33:36 +0200 (CEST) From: Ladislav Lhotka To: andyb@iwl.com In-Reply-To: <4C0FBE4D.2030504@iwl.com> References: <20100609.093427.39045518.mbj@tail-f.com> <1276070455.10433.47.camel@missotis> <20100609082942.GA2451@elstar.local> <20100609.130120.191856352.mbj@tail-f.com> <1276083158.10433.76.camel@missotis> <4C0F8BE4.7080700@iwl.com> <1276098803.10433.107.camel@missotis> <4C0FBE4D.2030504@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 09 Jun 2010 18:33:34 +0200 Message-ID: <1276101214.10433.121.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.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, 09 Jun 2010 16:33:36 -0000 Andy Bierman píše v St 09. 06. 2010 v 09:16 -0700: > Martin and I have pointed out why knowing the basic-mode > is not critical, especially when we add the 'remove' operation > that nobody has objected to adding. Without knowing the basic mode the client has to be careful with some operations that seem perfectly legal, and RFC4741bis provides no guidelines on this, simply because it is not able to explain the problem. Lada > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Wed Jun 9 09:55:17 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92F6A3A6994 for ; Wed, 9 Jun 2010 09:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.524 X-Spam-Level: X-Spam-Status: No, score=-1.524 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_20=-0.74, 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 oYbXJLe34uaU for ; Wed, 9 Jun 2010 09:55:16 -0700 (PDT) Received: from smtp224.iad.emailsrvr.com (smtp224.iad.emailsrvr.com [207.97.245.224]) by core3.amsl.com (Postfix) with ESMTP id B377D3A6992 for ; Wed, 9 Jun 2010 09:55:16 -0700 (PDT) Received: from relay12.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay12.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 1751220D39C; Wed, 9 Jun 2010 12:55:18 -0400 (EDT) Received: by relay12.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 6909420A6D4; Wed, 9 Jun 2010 12:55:17 -0400 (EDT) Message-ID: <4C0FC76A.8090005@iwl.com> Date: Wed, 09 Jun 2010 09:55:06 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ladislav Lhotka References: <20100609.093427.39045518.mbj@tail-f.com> <1276070455.10433.47.camel@missotis> <20100609082942.GA2451@elstar.local> <20100609.130120.191856352.mbj@tail-f.com> <1276083158.10433.76.camel@missotis> <4C0F8BE4.7080700@iwl.com> <1276098803.10433.107.camel@missotis> <4C0FBE4D.2030504@iwl.com> <1276101214.10433.121.camel@missotis> In-Reply-To: <1276101214.10433.121.camel@missotis> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 16:55:17 -0000 On 06/09/2010 09:33 AM, Ladislav Lhotka wrote: > Andy Bierman píše v St 09. 06. 2010 v 09:16 -0700: > >> Martin and I have pointed out why knowing the basic-mode >> is not critical, especially when we add the 'remove' operation >> that nobody has objected to adding. >> > Without knowing the basic mode the client has to be careful with some > operations that seem perfectly legal, and RFC4741bis provides no > guidelines on this, simply because it is not able to explain the > problem. > Those operations require care - by design. When 4741 was written, the intent of create/delete was for these operations to be picky -- Sharon really insisted on this. Not many people really cared, or understood that years later implementations would use different database designs wrt/ defaults that would impact create and delete. Now we have implementation experience, and we know that merge/remove will fix the problem by providing the same basic functionality as create/delete, except it will work on every server the exact same way. > Lada > Andy From root@core3.amsl.com Wed Jun 9 11:15:02 2010 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AB6FD3A67EC; Wed, 9 Jun 2010 11:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100609181501.AB6FD3A67EC@core3.amsl.com> Date: Wed, 9 Jun 2010 11:15:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-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, 09 Jun 2010 18:15: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 : With-defaults capability for NETCONF Author(s) : A. Bierman, B. Lengyel Filename : draft-ietf-netconf-with-defaults-09.txt Pages : 31 Date : 2010-06-09 The NETCONF protocol defines ways to read and edit configuration data from a NETCONF server. In some cases, part of this data may not be set by the NETCONF client, but rather a default value known to the server is used instead. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to save it in a NETCONF datastore or send it to the client in a retrieval operation reply. In other situations the NETCONF client will need this data from the server. Not all server implementations treat this default data the same way. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how defaults are processed by the server, and also defines new mechanisms for client control of server processing of default data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-with-defaults-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-with-defaults-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-09110617.I-D@ietf.org> --NextPart-- From mrw@lilacglade.org Thu Jun 10 07:28:58 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B5F43A6879 for ; Thu, 10 Jun 2010 07:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 nKiotGdZvRRi for ; Thu, 10 Jun 2010 07:28:54 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id 1441B3A6837 for ; Thu, 10 Jun 2010 07:28:53 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by QMTA11.westchester.pa.mail.comcast.net with comcast id UAZu1e0091c6gX85BEUxlJ; Thu, 10 Jun 2010 14:28:57 +0000 Received: from [10.36.0.42] ([98.110.155.200]) by omta23.westchester.pa.mail.comcast.net with comcast id UEUi1e0034Khd5e3jEUmM3; Thu, 10 Jun 2010 14:28:54 +0000 Message-Id: <7E044AE9-6548-491D-9BD5-26472D6EB596@lilacglade.org> From: Margaret Wasserman To: Martin Bjorklund In-Reply-To: <20100602.152910.125098302.mbj@tail-f.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 10 Jun 2010 10:28:40 -0400 References: <20100602.101123.205647377.mbj@tail-f.com> <20100602.152910.125098302.mbj@tail-f.com> X-Mailer: Apple Mail (2.936) Cc: netconf@ietf.org Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-01.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, 10 Jun 2010 14:28:58 -0000 Hi Martin, Thanks for the feedback! With the exception of your first suggested change, all the suggestions you sent look like improvements to me. I've included them below. Does anyone have any objection to making those changes? I think there is a problem (perhaps a cut-and-paste error?) with your first suggestion, though: On Jun 2, 2010, at 9:29 AM, Martin Bjorklund wrote: > NEW: > > The NETCONF client sends NETCONF The SSH client initiates the SSH > connection and the SSH server accepts the connection. There is no > requirement that the NETCONF client reside on the SSH client or > that the NETCONF server reside on the SSH server. Clearly that isn't what you meant, but I'm not exactly sure what you did mean... Are you suggesting: NEW: The SSH client initiates the SSH connection and the SSH server accepts the connection. There is no requirement that the NETCONF client reside on the SSH client, or that the NETCONF server reside on the SSH server. If so, I wonder... Do you really think it is okay not to define the two ends of the NETCONF connection, but that it is necessary to define the two ends of an SSH connection? Maybe we would be better off removing this paragraph altogether? Or just saying: "There is no requirement that the NETCONF client reside on the SSH client or that the NETCONF server reside on the SSH server." ...if we think it is important to state that, rather than just not saying anything? Margaret Martin's other suggestions, which I propose we accept: > > OLD: 1 > > Although this document gives specific examples of how NETCONF > operations are sent over an SSH connection, use of this transport is > not restricted to the operations shown in the examples below. This > transport can be used for any NETCONF operation. > > NEW: > > Although this document gives specific examples of how NETCONF > messages are sent over an SSH connection, use of this transport is > not restricted to the messages shown in the examples below. This > transport can be used for any NETCONF message. > > > OLD: 3.1 > > The NETCONF server MUST indicate its capabilities by sending an XML > document containing a element as soon as the NETCONF session > is established. The NETCONF client can parse this operation to > determine which NETCONF capabilities are supported by the NETCONF > server. > > NEW: > > The NETCONF server MUST indicate its capabilities by sending an XML > document containing a element as soon as the NETCONF session > is established. The NETCONF client can parse this message to > determine which NETCONF capabilities are supported by the NETCONF > server. > > OLD: 3.1 > > The following example shows a capability exchange. Operations sent > by the NETCONF client are marked with "C:" and operations sent by > the > NETCONF server are marked with "S:". > > NEW: > > The following example shows a capability exchange. Data sent > by the NETCONF client are marked with "C:" and data sent by the > NETCONF server are marked with "S:". > > (The reason is that each line is marked with C: and S: -- this is not > an operation; it is just data) > > > OLD: 3.1 > > Although the example shows the NETCONF server sending a > operation followed by the NETCONF client's operation, both sides > will > send the operation as soon as the NETCONF subsystem is initialized, > perhaps simultaneously. > > NEW: > > Although the example shows the NETCONF server sending a > message followed by the NETCONF client's message, both > sides will send the message as soon as the NETCONF subsystem is > initialized, perhaps simultaneously. > > OLD: 5 > > Exiting NETCONF is accomplished using the operation. > A NETCONF server will process NETCONF operations from the NETCONF > client in the order in which the are received. When the NETCONF > server processes a operation, the NETCONF server > shall respond and close the SSH session channel. The NETCONF server > MUST NOT process any NETCONF operations received after the session> operation. > > NEW: > > Exiting NETCONF is accomplished using the operation. > A NETCONF server will process NETCONF messages from the NETCONF > client in the order in which the are received. When the NETCONF > server processes a operation, the NETCONF server > SHALL respond and close the SSH session channel. The NETCONF server > MUST NOT process any NETCONF messages received after the session> operation. > From mbj@tail-f.com Thu Jun 10 07:44:08 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2D523A6837 for ; Thu, 10 Jun 2010 07:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.793 X-Spam-Level: X-Spam-Status: No, score=-0.793 tagged_above=-999 required=5 tests=[AWL=1.253, 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 ZpYemxCxOBrI for ; Thu, 10 Jun 2010 07:44:07 -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 89DE13A6987 for ; Thu, 10 Jun 2010 07:44:07 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 9689D76C062; Thu, 10 Jun 2010 16:44:05 +0200 (CEST) Date: Thu, 10 Jun 2010 16:44:04 +0200 (CEST) Message-Id: <20100610.164404.103755057.mbj@tail-f.com> To: mrw@lilacglade.org From: Martin Bjorklund In-Reply-To: <7E044AE9-6548-491D-9BD5-26472D6EB596@lilacglade.org> References: <20100602.152910.125098302.mbj@tail-f.com> <7E044AE9-6548-491D-9BD5-26472D6EB596@lilacglade.org> X-Mailer: Mew version 7.0.50 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] I-D Action:draft-ietf-netconf-rfc4742bis-01.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, 10 Jun 2010 14:44:08 -0000 Hi, Margaret Wasserman wrote: > I think there is a problem (perhaps a cut-and-paste error?) with your first > suggestion, though: Whoops! > On Jun 2, 2010, at 9:29 AM, Martin Bjorklund wrote: > > NEW: > > > > The NETCONF client sends NETCONF The SSH client initiates the SSH > > connection and the SSH server accepts the connection. There is no > > requirement that the NETCONF client reside on the SSH client or > > that the NETCONF server reside on the SSH server. > > Clearly that isn't what you meant, but I'm not exactly sure what you did > mean... Are you suggesting: > > NEW: > > The SSH client initiates the SSH connection and the SSH server accepts the > connection. There is no requirement that the NETCONF client reside on the SSH > client, or that the NETCONF server reside on the SSH server. Yes, that's what I meant. > If so, I wonder... Do you really think it is okay not to define the two ends > of the NETCONF connection, but that it is necessary to define the two ends of > an SSH connection? Hmm... The problem with the original text was that it didn't handle the case that the server can send . Since 4741/4741bis + 5277 define what kind of messages the NETCONF peers can send, this document should not try to define that. > Maybe we would be better off removing this paragraph altogether? That would be fine with me. /martin From bertietf@bwijnen.net Thu Jun 10 08:55:36 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B0433A68FC for ; Thu, 10 Jun 2010 08:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijtgM+Hl5HTy for ; Thu, 10 Jun 2010 08:55:35 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id B2A2D28C0ED for ; Thu, 10 Jun 2010 08:55:34 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.1.103]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OMk6L-0001Q4-Ol for netconf@ietf.org; Thu, 10 Jun 2010 17:55:35 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OMk6L-0003k1-Kk for netconf@ietf.org; Thu, 10 Jun 2010 17:55:29 +0200 Message-ID: <4C110AF1.1060207@bwijnen.net> Date: Thu, 10 Jun 2010 17:55:29 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: netconf Content-Type: multipart/mixed; boundary="------------080309000102060401040108" X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd442ba6f377e794584a68f300cdae92649 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd442ba6f377e794584a68f300cdae92649 Subject: [Netconf] WG last call comments addressed in: I-D Action:draft-ietf-netconf-with-defaults-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: Thu, 10 Jun 2010 15:55:36 -0000 This is a multi-part message in MIME format. --------------080309000102060401040108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As a result of the WGLC on this document, Andy posted a new rev with these changes: Removed non-volatile server requirements. Moved some text from basic-mode section into the the retrieval modes section. Added description and reference statements to the YANG module. Many bugfixes and clarifications, based on WGLC review comments. Pls take a last look at it to make sure all was addressed properly. Please do so by June 15th. Bert and Mehmet -------- Original Message -------- Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-09.txt Date: Wed, 9 Jun 2010 11:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: netconf@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : With-defaults capability for NETCONF Author(s) : A. Bierman, B. Lengyel Filename : draft-ietf-netconf-with-defaults-09.txt Pages : 31 Date : 2010-06-09 The NETCONF protocol defines ways to read and edit configuration data from a NETCONF server. In some cases, part of this data may not be set by the NETCONF client, but rather a default value known to the server is used instead. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to save it in a NETCONF datastore or send it to the client in a retrieval operation reply. In other situations the NETCONF client will need this data from the server. Not all server implementations treat this default data the same way. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how defaults are processed by the server, and also defines new mechanisms for client control of server processing of default data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-with-defaults-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. --------------080309000102060401040108 Content-Type: Message/External-body; name="draft-ietf-netconf-with-defaults-09.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-netconf-with-defaults-09.txt" Content-Type: text/plain Content-ID: <2010-06-09110617.I-D@ietf.org> --------------080309000102060401040108 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message Part" _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --------------080309000102060401040108-- From ietfc@btconnect.com Thu Jun 10 09:45:12 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DC543A679F for ; Thu, 10 Jun 2010 09:45:12 -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.240, BAYES_20=-0.74, DATE_IN_PAST_24_48=1.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mipG15DN+Dur for ; Thu, 10 Jun 2010 09:45:11 -0700 (PDT) Received: from c2beaomr02.btconnect.com (c2beaomr02.btconnect.com [213.123.26.180]) by core3.amsl.com (Postfix) with ESMTP id 06C743A6993 for ; Thu, 10 Jun 2010 09:45:10 -0700 (PDT) Received: from pc6 (host86-172-78-59.range86-172.btcentralplus.com [86.172.78.59]) by c2beaomr02.btconnect.com with SMTP id DSI63406; Thu, 10 Jun 2010 17:44:56 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4C111688.02EB, actions=tag Message-ID: <000a01cb08b3$6afc9f20$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Ladislav Lhotka" References: <20100609.093427.39045518.mbj@tail-f.com><1276070455.10433.47.camel@missotis><20100609082942.GA2451@elstar.local><20100609.130120.191856352.mbj@tail-f.com> <1276083158.10433.76.camel@missotis> Date: Wed, 9 Jun 2010 18:32:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Status: score=10/50, host=c2beaomr02.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0203.4C111690.039F,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.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, 10 Jun 2010 16:45:12 -0000 Make that four supporters of the change. Tom Petch ----- Original Message ----- From: "Ladislav Lhotka" To: "Martin Bjorklund" Cc: Sent: Wednesday, June 09, 2010 1:32 PM Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt > Martin Bjorklund píše v St 09. 06. 2010 v 13:01 +0200: > > Juergen Schoenwaelder wrote: > > > On Wed, Jun 09, 2010 at 10:00:55AM +0200, Ladislav Lhotka wrote: > > > > Martin Bjorklund p????e v St 09. 06. 2010 v 09:34 +0200: > > > > > But don't get me wrong. I think :with-defaults is useful. I'm just > > > > > saying that your statement that handling defaults is "tricky at best" > > > > > is not correct - provided we add the 'remove' operation. > > > > > > > > It definitely is tricky, as long as there are operations where the > > > > client cannot predict the outcome beforehand. Imagine that e.g. SQL > > > > worked this way. > > > > > > I agree with you but others say "as long as there is a way to work > > > around it, we can save the announcement of the basic-mode in the hello > > > exchange". > > > > I have never said that. I agree that with-defaults is useful, and I > > have no objections to moving the basic-mode advertisment into > > 4741bis. > > OK, so we've got (at least) three supporters of this change. > > Lada > > > > > My only point is that writing client code without knowing the basic > > mode is not as tricky as you might think. > > > > > > /martin > > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From phil@juniper.net Thu Jun 10 15:22:03 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B3913A6813 for ; Thu, 10 Jun 2010 15:22:03 -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 RTu4ffgN-Lio for ; Thu, 10 Jun 2010 15:21:55 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 230A13A6807 for ; Thu, 10 Jun 2010 15:21:54 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTBFldYc1eYIoMMDP/F9ryK0cD77HW+aH@postini.com; Thu, 10 Jun 2010 15:21:56 PDT Received: from p-emfe03-sac.jnpr.net (66.129.254.75) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Thu, 10 Jun 2010 15:19:45 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe03-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Jun 2010 15:19:45 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jun 2010 15:19:44 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Jun 2010 15:19:44 -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 o5AMJhD02667; Thu, 10 Jun 2010 15:19:43 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o5AM20Po016733; Thu, 10 Jun 2010 22:02:00 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201006102202.o5AM20Po016733@idle.juniper.net> To: t.petch Date: Thu, 10 Jun 2010 18:02:00 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 Jun 2010 22:19:44.0441 (UTC) FILETIME=[07624A90:01CB08EB] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.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, 10 Jun 2010 22:22:03 -0000 "t.petch" writes: >Make that four supporters of the change. Put me in the "against" column. The purpose of 4741bis is to fix issues and make clarifications. This is clearly outside that scope. Thanks, Phil From andyb@iwl.com Thu Jun 10 16:58:31 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACF323A6822 for ; Thu, 10 Jun 2010 16:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=1.092, 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 6gQpdY9V5Ig0 for ; Thu, 10 Jun 2010 16:58:30 -0700 (PDT) Received: from smtp174.iad.emailsrvr.com (smtp174.iad.emailsrvr.com [207.97.245.174]) by core3.amsl.com (Postfix) with ESMTP id 844393A6825 for ; Thu, 10 Jun 2010 16:58:30 -0700 (PDT) Received: from relay17.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay17.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 701831B9712 for ; Thu, 10 Jun 2010 19:58:32 -0400 (EDT) Received: by relay17.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 3774F1B401B for ; Thu, 10 Jun 2010 19:58:32 -0400 (EDT) Message-ID: <4C117C11.6010500@iwl.com> Date: Thu, 10 Jun 2010 16:58:09 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: NETCONF Content-Type: multipart/mixed; boundary="------------030709000808050202040205" Subject: [Netconf] Fwd: I-D Action:draft-bierman-netconf-system-monitoring-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 23:58:31 -0000 This is a multi-part message in MIME format. --------------030709000808050202040205 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hi, I have submitted a YANG module for system monitoring. In order to really get started with domain-specific standard configuration modules, some very basic system information is needed. This draft proposes some notifications, including 1 called 'sys-capability-change', intended to address the current 'capability-changed' error debate wrt/ the 4741bis draft. IMO, a notification is sufficient and a complicated error-tag + client-hello-parameter + resynch-operation is over-kill, to solve this problem. Other data and notification events are included for people to throw darts at. My goal is to keep this module as small and simple as possible. thanks, Andy -------- Original Message -------- Subject: I-D Action:draft-bierman-netconf-system-monitoring-00.txt Date: Thu, 10 Jun 2010 16:45:09 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NETCONF System Monitoring Author(s) : A. Bierman Filename : draft-bierman-netconf-system-monitoring-00.txt Pages : 16 Date : 2010-06-10 The NETCONF protocol provides mechanisms to manipulate configuration datastores. However, client applications often need to examine system information to determine the appropriate configuration requirements. In addition, common system events such as a change in system capabilities may impact management applications. Standard mechanisms are needed to support the monitoring of the managed system supported by a NETCONF server. This document defines a YANG module for the monitoring of system information, which allows a NETCONF client to identify system properties and receive notifications for system events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bierman-netconf-system-monitoring-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------030709000808050202040205 Content-Type: message/external-body; name="draft-bierman-netconf-system-monitoring-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-bierman-netconf-system-monitoring-00.txt" Content-Type: text/plain Content-ID: <2010-06-10163544.I-D@ietf.org> --------------030709000808050202040205 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------030709000808050202040205-- From mrw@lilacglade.org Thu Jun 10 18:34:44 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09F43A6946 for ; Thu, 10 Jun 2010 18:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AWL=1.278, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DL64VQ3Bw8qC for ; Thu, 10 Jun 2010 18:34:43 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 31FCF3A68DD for ; Thu, 10 Jun 2010 18:34:32 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta05.westchester.pa.mail.comcast.net with comcast id UQMB1e0071ZXKqc55RaMFB; Fri, 11 Jun 2010 01:34:21 +0000 Received: from [10.36.0.42] ([98.110.155.200]) by omta21.westchester.pa.mail.comcast.net with comcast id URZu1e00E4Khd5e3hRa0JN; Fri, 11 Jun 2010 01:34:16 +0000 Message-Id: <26241D4E-D31F-48B2-B7FA-8C7623BFB24D@lilacglade.org> From: Margaret Wasserman To: Martin Bjorklund In-Reply-To: <20100610.164404.103755057.mbj@tail-f.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 10 Jun 2010 17:12:47 -0400 References: <20100602.152910.125098302.mbj@tail-f.com> <7E044AE9-6548-491D-9BD5-26472D6EB596@lilacglade.org> <20100610.164404.103755057.mbj@tail-f.com> X-Mailer: Apple Mail (2.936) Cc: netconf@ietf.org Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 01:34:44 -0000 Hi Martin, On Jun 10, 2010, at 10:44 AM, Martin Bjorklund wrote: >> Maybe we would be better off removing this paragraph altogether? > > That would be fine with me. Okay. Unless anyone objects, I will make this change and the other changes you suggested and resubmit some time next week. Thanks! Margaret From bwijnen@bwijnen.net Fri Jun 11 00:38:49 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F0C63A6A2A for ; Fri, 11 Jun 2010 00:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.416 X-Spam-Level: * X-Spam-Status: No, score=1.416 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9rlDhF1ByXU for ; Fri, 11 Jun 2010 00:38:47 -0700 (PDT) Received: from relay.versatel.net (relay60.tele2.vuurwerk.nl [62.250.3.60]) by core3.amsl.com (Postfix) with ESMTP id C0CDE3A69E1 for ; Fri, 11 Jun 2010 00:38:45 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1OMypB-0000LI-EE; Fri, 11 Jun 2010 09:38:45 +0200 Message-ID: <9A1936F3823F417EB245ED8D40A67F17@BertLaptop> From: "Bert Wijnen" To: "Margaret Wasserman" , "Martin Bjorklund" References: <20100602.152910.125098302.mbj@tail-f.com><7E044AE9-6548-491D-9BD5-26472D6EB596@lilacglade.org><20100610.164404.103755057.mbj@tail-f.com> <26241D4E-D31F-48B2-B7FA-8C7623BFB24D@lilacglade.org> In-Reply-To: <26241D4E-D31F-48B2-B7FA-8C7623BFB24D@lilacglade.org> Date: Fri, 11 Jun 2010 09:38:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18197 Cc: netconf@ietf.org Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 07:38:49 -0000 Speaking as co-chair This seems fine to me. If anyone disagrees. PLEASE DO SPEAK UP by 15 June at the latest Bert ----- Original Message ----- From: "Margaret Wasserman" To: "Martin Bjorklund" Cc: Sent: Thursday, June 10, 2010 11:12 PM Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-01.txt Hi Martin, On Jun 10, 2010, at 10:44 AM, Martin Bjorklund wrote: >> Maybe we would be better off removing this paragraph altogether? > > That would be fine with me. Okay. Unless anyone objects, I will make this change and the other changes you suggested and resubmit some time next week. Thanks! Margaret _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From lhotka@cesnet.cz Fri Jun 11 01:03:24 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11A53A69DC for ; Fri, 11 Jun 2010 01:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.013 X-Spam-Level: * X-Spam-Status: No, score=1.013 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_40=-0.185, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8JFlK6++Eij for ; Fri, 11 Jun 2010 01:03:23 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 938153A69D5 for ; Fri, 11 Jun 2010 01:03:23 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 710DD2CDE057; Fri, 11 Jun 2010 10:03:24 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <201006102202.o5AM20Po016733@idle.juniper.net> References: <201006102202.o5AM20Po016733@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 11 Jun 2010 10:03:23 +0200 Message-ID: <1276243403.19811.9.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 08:03:24 -0000 Phil Shafer píše v ÄŒt 10. 06. 2010 v 18:02 -0400: > "t.petch" writes: > >Make that four supporters of the change. > > Put me in the "against" column. The purpose of 4741bis is > to fix issues and make clarifications. This is clearly > outside that scope. How about the new "remove" operation? IMO this operation really changes the NETCONF vocabulary, so the namespace URI should be changed as well. In comparison, signalling the base defaults handling in hello is pretty benign. Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Fri Jun 11 04:59:59 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0833A69F1 for ; Fri, 11 Jun 2010 04:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_20=-0.74, 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 A1kohNV66qYz for ; Fri, 11 Jun 2010 04:59:58 -0700 (PDT) Received: from smtp124.iad.emailsrvr.com (smtp124.iad.emailsrvr.com [207.97.245.124]) by core3.amsl.com (Postfix) with ESMTP id 930AC3A67EB for ; Fri, 11 Jun 2010 04:59:58 -0700 (PDT) Received: from relay2.r2.iad.emailsrvr.com (localhost [127.0.0.1]) by relay2.r2.iad.emailsrvr.com (SMTP Server) with ESMTP id 7D99E44C0B0; Fri, 11 Jun 2010 08:00:00 -0400 (EDT) Received: by relay2.r2.iad.emailsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 2411B44C0B7; Fri, 11 Jun 2010 08:00:00 -0400 (EDT) Message-ID: <4C122525.7010708@iwl.com> Date: Fri, 11 Jun 2010 04:59:33 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ladislav Lhotka References: <201006102202.o5AM20Po016733@idle.juniper.net> <1276243403.19811.9.camel@missotis> In-Reply-To: <1276243403.19811.9.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 11:59:59 -0000 On 06/11/2010 01:03 AM, Ladislav Lhotka wrote: > Phil Shafer píše v ÄŒt 10. 06. 2010 v 18:02 -0400: > >> "t.petch" writes: >> >>> Make that four supporters of the change. >>> >> Put me in the "against" column. The purpose of 4741bis is >> to fix issues and make clarifications. This is clearly >> outside that scope. >> > How about the new "remove" operation? IMO this operation really changes > the NETCONF vocabulary, so the namespace URI should be changed as well. > In comparison, signalling the base defaults handling in hello is pretty > benign. > IMO, the basic-mode is marginally useful, and not at all critical information. The intent of the WG (way back when) was to have create/delete be picky and merge/replace not be picky wrt/ instances already existing. It turns out that using replace as a remove is a really lame idea and the WG got it wrong in 4741. IMO, that makes 'remove' a bugfix not a new feature. > Lada > > >> Thanks, >> Phil >> > Andy From lhotka@cesnet.cz Fri Jun 11 09:09:16 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E3E828C0F4 for ; Fri, 11 Jun 2010 09:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.123 X-Spam-Level: * X-Spam-Status: No, score=1.123 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeKmYjmDbBLV for ; Fri, 11 Jun 2010 09:09:15 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 27A6D28C0F2 for ; Fri, 11 Jun 2010 09:09:15 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id A4E3F2CDE057; Fri, 11 Jun 2010 18:09:16 +0200 (CEST) From: Ladislav Lhotka To: andyb@iwl.com In-Reply-To: <4C122525.7010708@iwl.com> References: <201006102202.o5AM20Po016733@idle.juniper.net> <1276243403.19811.9.camel@missotis> <4C122525.7010708@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 11 Jun 2010 18:09:15 +0200 Message-ID: <1276272555.19811.27.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 16:09:16 -0000 Andy Bierman píše v Pá 11. 06. 2010 v 04:59 -0700: > On 06/11/2010 01:03 AM, Ladislav Lhotka wrote: > > Phil Shafer píše v ÄŒt 10. 06. 2010 v 18:02 -0400: > > > >> "t.petch" writes: > >> > >>> Make that four supporters of the change. > >>> > >> Put me in the "against" column. The purpose of 4741bis is > >> to fix issues and make clarifications. This is clearly > >> outside that scope. > >> > > How about the new "remove" operation? IMO this operation really changes > > the NETCONF vocabulary, so the namespace URI should be changed as well. > > In comparison, signalling the base defaults handling in hello is pretty > > benign. > > > > IMO, the basic-mode is marginally useful, and not at all critical > information. > The intent of the WG (way back when) was to have create/delete > be picky and merge/replace not be picky wrt/ instances already > existing. > > It turns out that using replace as a remove is a really > lame idea and the WG got it wrong in 4741. IMO, > that makes 'remove' a bugfix not a new feature. Don't get me wrong, I think the "remove" operation in a great idea, but in fact a bigger change than the basic mode signalling. As long as "delete" and "create" operations stay in the portfolio, I consider the basic mode signalling a must and bugfix as well. And yes, I am suggesting a change of XML namespace URI if "remove" makes it to 4741bis. Lada > > > > > Lada > > > > > >> Thanks, > >> Phil > >> > > > > Andy > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Fri Jun 11 10:19:22 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B674B3A6A14 for ; Fri, 11 Jun 2010 10:19:22 -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 tN5+iEMHFOXF for ; Fri, 11 Jun 2010 10:19:14 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id E63173A695D for ; Fri, 11 Jun 2010 10:19:12 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTBJwDywkwJm/7PiTbBXg9G/2H6v4B7l6@postini.com; Fri, 11 Jun 2010 10:19:16 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.2.254.0; Fri, 11 Jun 2010 10:16:45 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Jun 2010 10:16:44 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jun 2010 10:16:43 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Jun 2010 10:16:43 -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 o5BHGgD10583; Fri, 11 Jun 2010 10:16:42 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o5BGwvnC024185; Fri, 11 Jun 2010 16:58:58 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201006111658.o5BGwvnC024185@idle.juniper.net> To: In-Reply-To: <4C122525.7010708@iwl.com> Date: Fri, 11 Jun 2010 12:58:57 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Jun 2010 17:16:43.0564 (UTC) FILETIME=[DD265EC0:01CB0989] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 17:19:22 -0000 Andy Bierman writes: >It turns out that using replace as a remove is a really >lame idea and the WG got it wrong in 4741. IMO, >that makes 'remove' a bugfix not a new feature. Clearly a new operation is a new feature. I can't see a believable claim otherwise. I think we need to be honest with ourselves and admit that this 4741bis work is really about producing "NETCONF 1.1" and stop the "bugfix" charade. Thanks, Phil From andyb@iwl.com Fri Jun 11 10:22:45 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E35B53A6A1D for ; Fri, 11 Jun 2010 10:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.708 X-Spam-Level: X-Spam-Status: No, score=-1.708 tagged_above=-999 required=5 tests=[AWL=0.557, 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 uwFhSnEkBoKT for ; Fri, 11 Jun 2010 10:22:42 -0700 (PDT) Received: from smtp144.dfw.emailsrvr.com (smtp144.dfw.emailsrvr.com [67.192.241.144]) by core3.amsl.com (Postfix) with ESMTP id E46E23A6A2C for ; Fri, 11 Jun 2010 10:22:32 -0700 (PDT) Received: from relay4.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay4.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id A3E3210CBEAD; Fri, 11 Jun 2010 13:22:34 -0400 (EDT) Received: by relay4.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 6087810CBE24; Fri, 11 Jun 2010 13:22:34 -0400 (EDT) Message-ID: <4C1270BD.80408@iwl.com> Date: Fri, 11 Jun 2010 10:22:05 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ladislav Lhotka References: <201006102202.o5AM20Po016733@idle.juniper.net> <1276243403.19811.9.camel@missotis> <4C122525.7010708@iwl.com> <1276272555.19811.27.camel@missotis> In-Reply-To: <1276272555.19811.27.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 17:22:45 -0000 On 06/11/2010 09:09 AM, Ladislav Lhotka wrote: > Andy Bierman píše v Pá 11. 06. 2010 v 04:59 -0700: > >> On 06/11/2010 01:03 AM, Ladislav Lhotka wrote: >> >>> Phil Shafer píše v ÄŒt 10. 06. 2010 v 18:02 -0400: >>> >>> >>>> "t.petch" writes: >>>> >>>> >>>>> Make that four supporters of the change. >>>>> >>>>> >>>> Put me in the "against" column. The purpose of 4741bis is >>>> to fix issues and make clarifications. This is clearly >>>> outside that scope. >>>> >>>> >>> How about the new "remove" operation? IMO this operation really changes >>> the NETCONF vocabulary, so the namespace URI should be changed as well. >>> In comparison, signalling the base defaults handling in hello is pretty >>> benign. >>> >>> >> IMO, the basic-mode is marginally useful, and not at all critical >> information. >> The intent of the WG (way back when) was to have create/delete >> be picky and merge/replace not be picky wrt/ instances already >> existing. >> >> It turns out that using replace as a remove is a really >> lame idea and the WG got it wrong in 4741. IMO, >> that makes 'remove' a bugfix not a new feature. >> > Don't get me wrong, I think the "remove" operation in a great idea, but > in fact a bigger change than the basic mode signalling. As long as > "delete" and "create" operations stay in the portfolio, I consider the > basic mode signalling a must and bugfix as well. > > If the WG agrees that conformance for the basic-mode advertisement is a MUST and not a SHOULD (current), then the WG has to reverse the decisions made on the mailing list and at the last IETF. I don't see that consensus. One of the disconnects here is that moving the basic-mode advertisement to a new document changes the conformance we already agreed on. Another disconnect is the concept of NETCONF conformance. It seems to me the requirements are derived from a composite of all current standards-track NETCONF RFCs. If we agreed that a server MUST do X or Y, then any RFC will do. Coupling the conformance of basic-mode advertisement to base:1.1 advertisement is not needed for conformance or URI definition purposes. > And yes, I am suggesting a change of XML namespace URI if "remove" makes > it to 4741bis. > Yes. But maybe too late to avoid that anyway... We could create a new namespace just for the 1.1 operation attribute, but that may be more confusing, not less. Technically, we are no longer using the XSD that was registered with IANA for the 1.0 XML namespace. Technically, we are removing and altering some contents of the 1.0 XML namespace, and the IESG may not like that. > Lada > Andy From andyb@iwl.com Fri Jun 11 10:36:40 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CD573A6A10 for ; Fri, 11 Jun 2010 10:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.858 X-Spam-Level: X-Spam-Status: No, score=-0.858 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_20=-0.74, 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 b7HdRt-3L+GO for ; Fri, 11 Jun 2010 10:36:39 -0700 (PDT) Received: from smtp144.dfw.emailsrvr.com (smtp144.dfw.emailsrvr.com [67.192.241.144]) by core3.amsl.com (Postfix) with ESMTP id 218C43A69FD for ; Fri, 11 Jun 2010 10:36:39 -0700 (PDT) Received: from relay4.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay4.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id AE6E410CBFB8; Fri, 11 Jun 2010 13:36:41 -0400 (EDT) Received: by relay4.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 6DFE210CBDAC; Fri, 11 Jun 2010 13:36:41 -0400 (EDT) Message-ID: <4C12740C.9040403@iwl.com> Date: Fri, 11 Jun 2010 10:36:12 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Phil Shafer References: <201006111658.o5BGwvnC024185@idle.juniper.net> In-Reply-To: <201006111658.o5BGwvnC024185@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 17:36:40 -0000 On 06/11/2010 09:58 AM, Phil Shafer wrote: > Andy Bierman writes: > >> It turns out that using replace as a remove is a really >> lame idea and the WG got it wrong in 4741. IMO, >> that makes 'remove' a bugfix not a new feature. >> > Clearly a new operation is a new feature. I can't see a believable > claim otherwise. > > I think we need to be honest with ourselves and admit that this > 4741bis work is really about producing "NETCONF 1.1" and stop the > "bugfix" charade. > > I don't agree it is a charade. Even a bugfix release needs a new version number. I want to wrap up 4741bis because we are way past the point of diminishing returns. We are not reaching consensus on the open complex issues, so it's time to just drop them and publish what we have already. We have waited almost a year (2+ IETFs) trying to summarize the 4741bis issues and see if we can reach consensus on the list. The co-authors have tried to get decisions made, but no issues ever seem to get fully resolved. At some point, the WG process demands an outcome. That is up to the co-chairs though. BTW, what about the new confirmed-commit stuff? That is a new feature, just as much as a bugfix. Every new feature is based on operational dissatisfaction with the current release. In that sense, our 1.1 release is no different from any other software product ever made. > Thanks, > Phil > > Andy From mbj@tail-f.com Fri Jun 11 12:41:57 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263D03A67DA for ; Fri, 11 Jun 2010 12:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.165 X-Spam-Level: X-Spam-Status: No, score=-0.165 tagged_above=-999 required=5 tests=[AWL=0.022, 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 AYo0IO56yAT8 for ; Fri, 11 Jun 2010 12:41:53 -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 803703A635F for ; Fri, 11 Jun 2010 12:41:53 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 55CAD616005; Fri, 11 Jun 2010 21:41:54 +0200 (CEST) Date: Fri, 11 Jun 2010 21:41:53 +0200 (CEST) Message-Id: <20100611.214153.130839086.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1276272555.19811.27.camel@missotis> References: <1276243403.19811.9.camel@missotis> <4C122525.7010708@iwl.com> <1276272555.19811.27.camel@missotis> X-Mailer: Mew version 7.0.50 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] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 19:41:57 -0000 Ladislav Lhotka wrote: > And yes, I am suggesting a change of XML namespace URI if "remove" makes > it to 4741bis. There is no technical requirement for changing the namespace URI. The validity of this new value is tied to the base:1.1 capability. All old "instance documents" are still valid. /martin From andyb@iwl.com Fri Jun 11 12:47:58 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C472A28C141 for ; Fri, 11 Jun 2010 12:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.431 X-Spam-Level: X-Spam-Status: No, score=-1.431 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOVX8jp6+PjX for ; Fri, 11 Jun 2010 12:47:57 -0700 (PDT) Received: from smtp114.dfw.emailsrvr.com (smtp114.dfw.emailsrvr.com [67.192.241.114]) by core3.amsl.com (Postfix) with ESMTP id EF6E128C13C for ; Fri, 11 Jun 2010 12:47:56 -0700 (PDT) Received: from relay21.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay21.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 80A872E40A1A; Fri, 11 Jun 2010 15:47:59 -0400 (EDT) Received: by relay21.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 439742E40AA1; Fri, 11 Jun 2010 15:47:59 -0400 (EDT) Message-ID: <4C1292D1.3080805@iwl.com> Date: Fri, 11 Jun 2010 12:47:29 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Martin Bjorklund References: <1276243403.19811.9.camel@missotis> <4C122525.7010708@iwl.com> <1276272555.19811.27.camel@missotis> <20100611.214153.130839086.mbj@tail-f.com> In-Reply-To: <20100611.214153.130839086.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 19:47:58 -0000 On 06/11/2010 12:41 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > >> And yes, I am suggesting a change of XML namespace URI if "remove" makes >> it to 4741bis. >> > There is no technical requirement for changing the namespace URI. The > validity of this new value is tied to the base:1.1 capability. All > old "instance documents" are still valid. > > Really? What about the XSD we need to define the XML syntax that YANG does not cover, including the nc:operation attribute? Can it have the same targetNamespace as the RFC 4741 XSD? I don't think it can. > /martin > > > > > Andy From mbj@tail-f.com Fri Jun 11 13:03:33 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E4D028C0F8 for ; Fri, 11 Jun 2010 13:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.054 X-Spam-Level: X-Spam-Status: No, score=-0.054 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWb98TbXvTgR for ; Fri, 11 Jun 2010 13:03:32 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 54C253A67DA for ; Fri, 11 Jun 2010 13:03:32 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 95329616004; Fri, 11 Jun 2010 22:03:34 +0200 (CEST) Date: Fri, 11 Jun 2010 22:03:33 +0200 (CEST) Message-Id: <20100611.220333.226252607.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4C1292D1.3080805@iwl.com> References: <1276272555.19811.27.camel@missotis> <20100611.214153.130839086.mbj@tail-f.com> <4C1292D1.3080805@iwl.com> X-Mailer: Mew version 7.0.50 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] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 20:03:33 -0000 Andy Bierman wrote: > On 06/11/2010 12:41 PM, Martin Bjorklund wrote: > > Ladislav Lhotka wrote: > > > >> And yes, I am suggesting a change of XML namespace URI if "remove" makes > >> it to 4741bis. > >> > > There is no technical requirement for changing the namespace URI. The > > validity of this new value is tied to the base:1.1 capability. All > > old "instance documents" are still valid. > > > > > > Really? > What about the XSD we need to define the XML syntax > that YANG does not cover, including the nc:operation > attribute? Can it have the same targetNamespace as > the RFC 4741 XSD? I don't think it can. Why not? As I wrote, all old instance documents are still valid. XSD does not have any "upgrade rules" like SMIv2 or YANG. XSD does have a "version" attribute, which we could use in 4741bis, in order to make it clear that this is a new version. But this attribute has no semantic meaning in XSD. /martin From andyb@iwl.com Fri Jun 11 13:17:49 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE9293A6A51 for ; Fri, 11 Jun 2010 13:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVg9u18b0ud1 for ; Fri, 11 Jun 2010 13:17:49 -0700 (PDT) Received: from smtp114.dfw.emailsrvr.com (smtp114.dfw.emailsrvr.com [67.192.241.114]) by core3.amsl.com (Postfix) with ESMTP id F2E6E3A6A59 for ; Fri, 11 Jun 2010 13:17:48 -0700 (PDT) Received: from relay11.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay11.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 995A317FEF0; Fri, 11 Jun 2010 16:17:51 -0400 (EDT) Received: by relay11.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 586F517FD16; Fri, 11 Jun 2010 16:17:51 -0400 (EDT) Message-ID: <4C1299D1.5080403@iwl.com> Date: Fri, 11 Jun 2010 13:17:21 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Martin Bjorklund References: <1276272555.19811.27.camel@missotis> <20100611.214153.130839086.mbj@tail-f.com> <4C1292D1.3080805@iwl.com> <20100611.220333.226252607.mbj@tail-f.com> In-Reply-To: <20100611.220333.226252607.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 20:17:49 -0000 On 06/11/2010 01:03 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > >> On 06/11/2010 12:41 PM, Martin Bjorklund wrote: >> >>> Ladislav Lhotka wrote: >>> >>> >>>> And yes, I am suggesting a change of XML namespace URI if "remove" makes >>>> it to 4741bis. >>>> >>>> >>> There is no technical requirement for changing the namespace URI. The >>> validity of this new value is tied to the base:1.1 capability. All >>> old "instance documents" are still valid. >>> >>> >>> >> Really? >> What about the XSD we need to define the XML syntax >> that YANG does not cover, including the nc:operation >> attribute? Can it have the same targetNamespace as >> the RFC 4741 XSD? I don't think it can. >> > Why not? As I wrote, all old instance documents are still valid. > XSD does not have any "upgrade rules" like SMIv2 or YANG. > > XSD does have a "version" attribute, which we could use in 4741bis, in > order to make it clear that this is a new version. But this attribute > has no semantic meaning in XSD. > > OK -- I was thinking maybe the 'version' attribute is good enough. The new XSD is not backward-compatible. Lots of stuff was removed. > /martin > > Andy From lhotka@cesnet.cz Fri Jun 11 13:18:36 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1513A6A64 for ; Fri, 11 Jun 2010 13:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.154 X-Spam-Level: X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[AWL=1.096, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rkqkCYmoNEZ for ; Fri, 11 Jun 2010 13:18:36 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id EB55C3A6A5E for ; Fri, 11 Jun 2010 13:18:34 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id C038D2CDE058; Fri, 11 Jun 2010 22:18:35 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20100611.214153.130839086.mbj@tail-f.com> References: <1276243403.19811.9.camel@missotis> <4C122525.7010708@iwl.com> <1276272555.19811.27.camel@missotis> <20100611.214153.130839086.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 11 Jun 2010 22:18:34 +0200 Message-ID: <1276287514.22234.7.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 20:18:36 -0000 Martin Bjorklund píše v Pá 11. 06. 2010 v 21:41 +0200: > Ladislav Lhotka wrote: > > And yes, I am suggesting a change of XML namespace URI if "remove" makes > > it to 4741bis. > > There is no technical requirement for changing the namespace URI. The > validity of this new value is tied to the base:1.1 capability. All > old "instance documents" are still valid. So when do you want to change the 1.0 in the XML namespace URI? There is no other indication of the vocabulary version except in the session hello messages, which creates problems for tools that process NETCONF stuff offline. Having the version number in the namespace URI has been considered a bug by some, so let's make it into a feature. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Fri Jun 11 13:34:31 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11E5F3A672E for ; Fri, 11 Jun 2010 13:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.125 X-Spam-Level: X-Spam-Status: No, score=0.125 tagged_above=-999 required=5 tests=[AWL=-0.243, 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 05e+UCWe-nyw for ; Fri, 11 Jun 2010 13:34: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 54DB23A6767 for ; Fri, 11 Jun 2010 13:34:05 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 73A2F616004; Fri, 11 Jun 2010 22:33:56 +0200 (CEST) Date: Fri, 11 Jun 2010 22:33:55 +0200 (CEST) Message-Id: <20100611.223355.04418236.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1276287514.22234.7.camel@missotis> References: <1276272555.19811.27.camel@missotis> <20100611.214153.130839086.mbj@tail-f.com> <1276287514.22234.7.camel@missotis> X-Mailer: Mew version 7.0.50 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 20:34:31 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiBQw6EgMTEuIDA2LiAyMDEwIHYgMjE6NDEgKzAyMDA6DQo+ID4gTGFkaXNs YXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gPiA+IEFuZCB5ZXMsIEkgYW0g c3VnZ2VzdGluZyBhIGNoYW5nZSBvZiBYTUwgbmFtZXNwYWNlIFVSSSBpZiAicmVtb3ZlIiBtYWtl cw0KPiA+ID4gaXQgdG8gNDc0MWJpcy4NCj4gPiANCj4gPiBUaGVyZSBpcyBubyB0ZWNobmljYWwg cmVxdWlyZW1lbnQgZm9yIGNoYW5naW5nIHRoZSBuYW1lc3BhY2UgVVJJLiAgVGhlDQo+ID4gdmFs aWRpdHkgb2YgdGhpcyBuZXcgdmFsdWUgaXMgdGllZCB0byB0aGUgYmFzZToxLjEgY2FwYWJpbGl0 eS4gIEFsbA0KPiA+IG9sZCAiaW5zdGFuY2UgZG9jdW1lbnRzIiBhcmUgc3RpbGwgdmFsaWQuDQo+ IA0KPiBTbyB3aGVuIGRvIHlvdSB3YW50IHRvIGNoYW5nZSB0aGUgMS4wIGluIHRoZSBYTUwgbmFt ZXNwYWNlIFVSST8NCg0KSSBkb24ndCA6KQ0KDQpOb3RlIHRoYXQgaWYgd2UgY2hhbmdlIHRoZSBu YW1lc3BhY2UgVVJJIGZvciA8aGVsbG8+LCBpdCB3aWxsIG5vdCBiZQ0KcG9zc2libGUgdG8gbWFr ZSBhIHNlcnZlciB0aGF0IHN1cHBvcnRzIDEuMCBhbmQgMS4xIGF0IHRoZSBzYW1lIHRpbWUuDQoN Cj4gVGhlcmUgaXMgbm8gb3RoZXIgaW5kaWNhdGlvbiBvZiB0aGUgdm9jYWJ1bGFyeSB2ZXJzaW9u IGV4Y2VwdCBpbiB0aGUNCj4gc2Vzc2lvbiBoZWxsbyBtZXNzYWdlcywgd2hpY2ggY3JlYXRlcyBw cm9ibGVtcyBmb3IgdG9vbHMgdGhhdCBwcm9jZXNzDQo+IE5FVENPTkYgc3R1ZmYgb2ZmbGluZS4N Cg0KSSBkb24ndCBrbm93IHdoYXQgdGhpcyB3b3VsZCBiZSAtIGEgdG9vbCB0aGF0IHByb2Nlc3Nl cyBORVRDT05GDQoqbWVzc2FnZXMqIGJ1dCBub3QgcGFydCBvZiBhIE5FVENPTkYgc2Vzc2lvbj8g IFRoaXMgaXMgb3V0IG9mIHNjb3BlLg0KDQo+IEhhdmluZyB0aGUgdmVyc2lvbiBudW1iZXIgaW4g dGhlIG5hbWVzcGFjZSBVUkkgaGFzIGJlZW4gY29uc2lkZXJlZCBhIGJ1Zw0KPiBieSBzb21lLCBz byBsZXQncyBtYWtlIGl0IGludG8gYSBmZWF0dXJlLg0KDQpUaGUgcHJvYmxlbXMgd2l0aCBlbWJl ZGRpbmcgdGhlIHZlcnNpb24gbnVtYmVyIGluIHRoZSBYTUwgbmFtZXNwYWNlDQpVUkkgaXMgYnkg bm8gbWVhbnMgdW5pcXVlIGZvciBORVRDT05GLiAgQW5kIHllcywgSSBkbyBiZWxpZXZlIGl0IGlz IGENCmJ1Zy4NCg0KDQovbWFydGluDQo= From j.schoenwaelder@jacobs-university.de Fri Jun 11 13:52:07 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F026528C115 for ; Fri, 11 Jun 2010 13:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.285 X-Spam-Level: X-Spam-Status: No, score=0.285 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_40=-0.185, 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 HyyppY3iY45G for ; Fri, 11 Jun 2010 13:52:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DFD1228C103 for ; Fri, 11 Jun 2010 13:52:06 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 183CEC0006; Fri, 11 Jun 2010 22:52:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id g708oEb32i5A; Fri, 11 Jun 2010 22:52:08 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C837CC0016; Fri, 11 Jun 2010 22:52:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6228512FE0C9; Fri, 11 Jun 2010 22:52:05 +0200 (CEST) Date: Fri, 11 Jun 2010 22:52:05 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100611205205.GA55416@elstar.local> Mail-Followup-To: Martin Bjorklund , "lhotka@cesnet.cz" , "netconf@ietf.org" References: <1276272555.19811.27.camel@missotis> <20100611.214153.130839086.mbj@tail-f.com> <1276287514.22234.7.camel@missotis> <20100611.223355.04418236.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100611.223355.04418236.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt 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, 11 Jun 2010 20:52:08 -0000 On Fri, Jun 11, 2010 at 10:33:55PM +0200, Martin Bjorklund wrote: > > Having the version number in the namespace URI has been considered a bug > > by some, so let's make it into a feature. > > The problems with embedding the version number in the XML namespace > URI is by no means unique for NETCONF. And yes, I do believe it is a > bug. +1 /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Sun Jun 13 06:44:26 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C69A3A6928 for ; Sun, 13 Jun 2010 06:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.305 X-Spam-Level: X-Spam-Status: No, score=-0.305 tagged_above=-999 required=5 tests=[AWL=-0.120, 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 faC+NMZeYQCA for ; Sun, 13 Jun 2010 06:44:25 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 3D3493A690A for ; Sun, 13 Jun 2010 06:44:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,410,1272859200"; d="scan'208";a="20381179" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 13 Jun 2010 09:44:27 -0400 X-IronPort-AV: E=Sophos;i="4.53,410,1272859200"; d="scan'208";a="472025352" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Jun 2010 09:43:52 -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: Sun, 13 Jun 2010 15:43:31 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-netconf-monitoring Thread-Index: AcsJPDm7J0T/WgkZRiK5BECk8I3z6wBwixgw From: "Romascanu, Dan (Dan)" To: Subject: [Netconf] FW: secdir review of draft-ietf-netconf-monitoring X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2010 13:44:26 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Alan DeKok Sent: Friday, June 11, 2010 11:01 AM To: secdir@ietf.org; IESG IESG; draft-ietf-netconf-monitoring@tools.ietf.org Subject: secdir review of draft-ietf-netconf-monitoring I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document defines a data model for netconf monitoring. The security considerations section says in part: Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g. via get, get-config or notification) to these data nodes. What is unclear from the document is whether or not the data is secure *after* access is gained. i.e. is there a secure transport layer? Should one be used? If not, why? A statement about privacy and security, with a reference to an existing netconf document would be good. From andyb@iwl.com Sun Jun 13 10:31:07 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAE043A690C for ; Sun, 13 Jun 2010 10:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.416 X-Spam-Level: X-Spam-Status: No, score=-1.416 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_50=0.001, 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 Pd23KwclBPlP for ; Sun, 13 Jun 2010 10:31:07 -0700 (PDT) Received: from smtp204.iad.emailsrvr.com (smtp204.iad.emailsrvr.com [207.97.245.204]) by core3.amsl.com (Postfix) with ESMTP id EA4373A6879 for ; Sun, 13 Jun 2010 10:31:06 -0700 (PDT) Received: from relay30.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay30.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 135261B4017 for ; Sun, 13 Jun 2010 13:31:10 -0400 (EDT) Received: by relay30.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id D90311B4011 for ; Sun, 13 Jun 2010 13:31:09 -0400 (EDT) Message-ID: <4C1515AE.2040303@iwl.com> Date: Sun, 13 Jun 2010 10:30:22 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] capability-change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2010 17:31:07 -0000 Hi, This is 1 of the few remaining open 4741bis issues. The proposal (although distributed in many emails) is let the client ask for the server to treat a capability-change as a error, with new error-tag 'capabilities-changed'. Then the client can call a new operation to clear the error and re-get the message. This sounds sort of reasonable in theory. However, IMO, this is not an operational error. It is simply a system event. Before discussion solutions, the WG needs to agree that this is a problem that 4741bis needs to solve. Are there any real NETCONF implementations that are having this problem now? If so, please describe the use-case. Are there even any implementations that can alter or remove NETCONF capabilities on-the-fly, without dropping sessions or rebooting? Are there any vendor capability URIs defined, which are legitimate NETCONF protocol-related extensions? (E.g., a hardware 'identifier' as a NETCONF capability URI is a gross misuse of the protocol). SNMP and CLI have no concept of freezing out the operator because the system changed in some way. This is quite fragile, and maybe naive, to think operators want to be interrupted when the system changes. I completely agree that a session MUST be dropped if the server needs to remove or alter any of the NETCONF (4741,partial-lock, with-defaults) capabilities from the session. Beyond that, there is nothing for the standard to define. A common use-case is going to be the dynamic loading/reloading/upgrading of YANG modules, on-the-fly. This is a feature, not an error. IMO, there is no consensus to change anything in 4741bis wrt/ capability errors. If so, we are done, and the next draft can be the last one. The lack of progress on this issue means nobody cares, are we can just drop it and move on. Andy From lhotka@cesnet.cz Sun Jun 13 22:22:28 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 102903A6851 for ; Sun, 13 Jun 2010 22:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.046 X-Spam-Level: * X-Spam-Status: No, score=1.046 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxDn6liFQzqG for ; Sun, 13 Jun 2010 22:22:27 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 214E13A67E3 for ; Sun, 13 Jun 2010 22:22:27 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id EB8212CDE057; Mon, 14 Jun 2010 07:22:29 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20100611.223355.04418236.mbj@tail-f.com> References: <1276272555.19811.27.camel@missotis> <20100611.214153.130839086.mbj@tail-f.com> <1276287514.22234.7.camel@missotis> <20100611.223355.04418236.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 14 Jun 2010 07:22:28 +0200 Message-ID: <1276492948.4210.22.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.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, 14 Jun 2010 05:22:28 -0000 Martin Bjorklund píše v Pá 11. 06. 2010 v 22:33 +0200: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v Pá 11. 06. 2010 v 21:41 +0200: > > > Ladislav Lhotka wrote: > > > > And yes, I am suggesting a change of XML namespace URI if "remove" makes > > > > it to 4741bis. > > > > > > There is no technical requirement for changing the namespace URI. The > > > validity of this new value is tied to the base:1.1 capability. All > > > old "instance documents" are still valid. > > > > So when do you want to change the 1.0 in the XML namespace URI? > > I don't :) Major changes should lead to changing the NS URI. Of course, adding a single new operation may not be classified as a major change. Perhaps some policy in this regard should be stated in 4741bis. > > Note that if we change the namespace URI for , it will not be > possible to make a server that supports 1.0 and 1.1 at the same time. Yes, we discussed this in March, would have to keep the old version number. IMO should have been assigned a NS URI other than the one used for NETCONF messages, and have it's own versioning. > > > There is no other indication of the vocabulary version except in the > > session hello messages, which creates problems for tools that process > > NETCONF stuff offline. > > I don't know what this would be - a tool that processes NETCONF > *messages* but not part of a NETCONF session? This is out of scope. > > > Having the version number in the namespace URI has been considered a bug > > by some, so let's make it into a feature. > > The problems with embedding the version number in the XML namespace > URI is by no means unique for NETCONF. And yes, I do believe it is a > bug. Both approaches have their pros and cons. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mehmet.ersue@nsn.com Mon Jun 14 01:33:50 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78AAF3A67ED; Mon, 14 Jun 2010 01:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 3knscs1rLS0w; Mon, 14 Jun 2010 01:33:45 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 304533A6403; Mon, 14 Jun 2010 01:33:44 -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 o5E8Xcxr016371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Jun 2010 10:33:38 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5E8XcW6001119; Mon, 14 Jun 2010 10:33:38 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jun 2010 10:33:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB0B9C.48D1DB2B" Date: Mon, 14 Jun 2010 10:33:36 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64984329@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: secdir review of draft-ietf-netconf-monitoring Thread-Index: AcsJPDm7J0T/WgkZRiK5BECk8I3z6wBwixgwAAClTwA= References: From: "Ersue, Mehmet (NSN - DE/Munich)" To: , , X-OriginalArrivalTime: 14 Jun 2010 08:33:38.0106 (UTC) FILETIME=[4932C9A0:01CB0B9C] Cc: draft-ietf-netconf-monitoring@tools.ietf.org, netconf@ietf.org Subject: Re: [Netconf] FW: secdir review of draft-ietf-netconf-monitoring X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 08:33:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB0B9C.48D1DB2B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Alan, I agree that the security consideration section should inform on the use of secure transport with NETCONF. We addressed this issue in the new version of the security considerations template (see attached mail). As defined in RFC 4741 NETCONF protocol has to be used on top of a secure transport and a NETCONF implementation MUST support SSH as secure transport. I hope this addresses your request. 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: Sunday, June 13, 2010 3:44 PM > To: netconf@ietf.org > Subject: [Netconf] FW: secdir review of draft-ietf-netconf-monitoring >=20 >=20 > =20 >=20 > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > Behalf Of > Alan DeKok > Sent: Friday, June 11, 2010 11:01 AM > To: secdir@ietf.org; IESG IESG; > draft-ietf-netconf-monitoring@tools.ietf.org > Subject: secdir review of draft-ietf-netconf-monitoring >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed=20 > by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. >=20 > The document defines a data model for netconf monitoring. =20 > The security > considerations section says in part: >=20 > Some of the readable data nodes in this YANG module may be > considered sensitive or vulnerable in some network environments. > It is thus important to control read access (e.g. via get, > get-config or notification) to these data nodes. >=20 > What is unclear from the document is whether or not the=20 > data is secure > *after* access is gained. i.e. is there a secure transport layer? > Should one be used? If not, why? >=20 > A statement about privacy and security, with a reference to an > existing netconf document would be good. > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 ------_=_NextPart_001_01CB0B9C.48D1DB2B Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from demuexc022.nsn-intra.net ([10.150.128.35]) by DEMUEXC006.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jun 2010 10:22:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jun 2010 10:22:25 +0200 Received: from demumfd002.nsn-inter.net (DEMUMFD002 [93.183.12.31]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5E8MPSj025288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Jun 2010 10:22:25 +0200 Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o5E8MNUH017501 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL); Mon, 14 Jun 2010 10:22:24 +0200 Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Jun 2010 04:22:22 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Jun 2010 04:22:21 -0400 Content-class: urn:content-classes:message Subject: FW: [netmod] [Fwd: 5th draft for yang module security considerations] Date: Mon, 14 Jun 2010 10:22:16 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] [Fwd: 5th draft for yang module security considerations] Thread-Index: AcsLmehxLiGRZkV0SL6tOyvWiuoa8QAALJIw From: "ext Romascanu, Dan (Dan)" To: "Sean Turner" , Cc: , "Ersue, Mehmet (NSN - DE/Munich)" , "David Partain" , "Kessens, David (NSN - US/Mountain View)" =20 -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Bert (IETF) Wijnen Sent: Monday, June 14, 2010 11:16 AM To: netmod Working Group Subject: [netmod] [Fwd: 5th draft for yang module security considerations] Since the 4th draft, we have been informed of one typo that is fixed in this revision. Further, the security ADs wanted something added about secure transport of the data, and the secdir review of the netconf-monitoring draft also had questions about that. As a result, Juergen Schoenwaelder has suggested to add some text about that. The resulting text is now as below. Bert --- draft 5 for tang module security considerations: Each specification that defines one or more YANG modules MUST contain a section that discusses security considerations relevant to those modules. This section MUST be patterned after the latest approved template (available at [ed: URL TBD]). In particular, writable data nodes that could be especially disruptive if abused MUST be explicitly listed by name and the associated security risks MUST be spelled out. Similarly, readable data nodes that contain especially sensitive information or that raise significant privacy concerns MUST be explicitly listed by name and the reasons for the sensitivity/privacy concerns MUST be explained. Further, if new RPC operations have been defined, then the security considerations of each new RPC operation MUST be explained. X. Security Considerations The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC4741]. The lowest NETCONF layer is the secure transport layer and the mandatory to implement secure transport is SSH [RFC4742]. -- if you have any writeable data nodes (those are all the -- "config true" nodes, and remember, that is the default) -- describe their specific sensitivity or vulnerability. There are a number of data nodes defined in this YANG module which are writable/creatable/deletable (i.e. config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g. edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: -- for all YANG modules you must evaluate whether any readable data -- nodes (those are all the "config false" nodes, but also all other -- nodes, because they can also be read via operations like get or -- get-config) are sensitive or vulnerable (for instance, if they -- might reveal customer information or violate personal privacy -- laws such as those of the European Union if exposed to -- unauthorized parties) Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g. via get, get-config or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: -- if your YANG module has defined any rpc operations -- describe their specific sensitivity or vulnerability. Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability: _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------_=_NextPart_001_01CB0B9C.48D1DB2B-- From aland@freeradius.org Tue Jun 15 06:47:33 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14DC23A67D6; Tue, 15 Jun 2010 06:47:33 -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 XiQ7d-jWvO0E; Tue, 15 Jun 2010 06:47:31 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id E91883A6801; Tue, 15 Jun 2010 06:47:30 -0700 (PDT) Message-ID: <4C178474.4010005@freeradius.org> Date: Tue, 15 Jun 2010 15:47:32 +0200 From: Alan T DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <80A0822C5E9A4440A5117C2F4CD36A64984329@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64984329@DEMUEXC006.nsn-intra.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 15 Jun 2010 07:03:46 -0700 Cc: draft-ietf-netconf-monitoring@tools.ietf.org, iesg@ietf.org, netconf@ietf.org Subject: Re: [Netconf] [secdir] FW: secdir review of draft-ietf-netconf-monitoring X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: aland@freeradius.org List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 13:47:33 -0000 Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear Alan, > > I agree that the security consideration section should inform on the use > of secure transport with NETCONF. > We addressed this issue in the new version of the security > considerations template (see attached mail). > > As defined in RFC 4741 NETCONF protocol has to be used on top of a > secure transport and a NETCONF implementation MUST support SSH as secure > transport. > > I hope this addresses your request. Yes, thanks. From dromasca@avaya.com Tue Jun 15 07:04:57 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4B283A6A2F; Tue, 15 Jun 2010 07:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.192 X-Spam-Level: X-Spam-Status: No, score=-0.192 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_50=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 Ya6gIzHi9H43; Tue, 15 Jun 2010 07:04:56 -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 E4D753A690F; Tue, 15 Jun 2010 07:04:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,420,1272859200"; d="scan'208";a="193542289" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Jun 2010 10:04:58 -0400 X-IronPort-AV: E=Sophos;i="4.53,420,1272859200"; d="scan'208";a="472625263" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 15 Jun 2010 10:04:57 -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, 15 Jun 2010 16:04:50 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: [netmod] [Fwd: 5th draft for yang module security considerations] Thread-Index: AcsMkzHeLgW5wNcqTr+c/glb3tQlmAAAGCNQ From: "Romascanu, Dan (Dan)" To: , Subject: [Netconf] FW: FW: [netmod] [Fwd: 5th draft for yang module security considerations] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 14:04:57 -0000 The Security AD's approved the text for the security considerations as per the 5th draft.=20 Dan -----Original Message----- From: Sean Turner [mailto:turners@ieca.com]=20 Sent: Tuesday, June 15, 2010 5:01 PM To: Romascanu, Dan (Dan) Cc: tim.polk@nist.gov; bertietf@bwijnen.net; mehmet.ersue@nsn.com; David Partain; David Kessens Subject: Re: FW: [netmod] [Fwd: 5th draft for yang module security considerations] Dan, Tim and I talked about this this morning and we're happy with the text. spt Romascanu, Dan (Dan) wrote: > =20 >=20 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On=20 > Behalf Of Bert (IETF) Wijnen > Sent: Monday, June 14, 2010 11:16 AM > To: netmod Working Group > Subject: [netmod] [Fwd: 5th draft for yang module security=20 > considerations] >=20 > Since the 4th draft, we have been informed of one typo that is fixed=20 > in this revision. >=20 > Further, the security ADs wanted something added about secure=20 > transport of the data, and the secdir review of the netconf-monitoring > draft also had questions about that. As a result, Juergen=20 > Schoenwaelder has suggested to add some text about that. >=20 > The resulting text is now as below. >=20 > Bert >=20 > --- draft 5 for tang module security considerations: >=20 > Each specification that defines one or more YANG > modules MUST contain a section that discusses > security considerations relevant to those modules. > This section MUST be patterned after the latest > approved template (available at [ed: URL TBD]). >=20 > In particular, writable data nodes that could > be especially disruptive if abused MUST be > explicitly listed by name and the associated > security risks MUST be spelled out. >=20 > Similarly, readable data nodes that contain > especially sensitive information or that raise > significant privacy concerns MUST be explicitly > listed by name and the reasons for the > sensitivity/privacy concerns MUST be explained. >=20 > Further, if new RPC operations have been defined, > then the security considerations of each new > RPC operation MUST be explained. >=20 > X. Security Considerations >=20 > The YANG module defined in this memo is designed to be accessed via=20 > the NETCONF protocol [RFC4741]. The lowest NETCONF layer is the secure > transport layer and the mandatory to implement secure transport is SSH > [RFC4742]. >=20 > -- if you have any writeable data nodes (those are all the > -- "config true" nodes, and remember, that is the default) > -- describe their specific sensitivity or vulnerability. >=20 > There are a number of data nodes defined in this YANG module which are > writable/creatable/deletable (i.e. config true, which is the default). > These data nodes may be considered sensitive or vulnerable in some=20 > network environments. Write operations (e.g. edit-config) to these=20 > data nodes without proper protection can have a negative effect on=20 > network operations. These are the subtrees and data nodes and their > sensitivity/vulnerability: >=20 > >=20 > -- for all YANG modules you must evaluate whether any readable data > -- nodes (those are all the "config false" nodes, but also all other > -- nodes, because they can also be read via operations like get or > -- get-config) are sensitive or vulnerable (for instance, if they > -- might reveal customer information or violate personal privacy > -- laws such as those of the European Union if exposed to > -- unauthorized parties) >=20 > Some of the readable data nodes in this YANG module may be considered=20 > sensitive or vulnerable in some network environments. > It is thus important to control read access (e.g. via get, get-config=20 > or > notification) to these data nodes. These are the subtrees and data=20 > nodes and their sensitivity/vulnerability: >=20 > >=20 > -- if your YANG module has defined any rpc operations > -- describe their specific sensitivity or vulnerability. >=20 > Some of the RPC operations in this YANG module may be considered=20 > sensitive or vulnerable in some network environments. It is thus=20 > important to control access to these operations. These are the=20 > operations and their sensitivity/vulnerability: >=20 > >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From dromasca@avaya.com Tue Jun 15 09:21:55 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EBC43A691E for ; Tue, 15 Jun 2010 09:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[AWL=1.067, 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 Dgbmcne5UZHD for ; Tue, 15 Jun 2010 09:21:54 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 162313A68F3 for ; Tue, 15 Jun 2010 09:21:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,421,1272859200"; d="scan'208";a="223168086" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Jun 2010 12:21:58 -0400 X-IronPort-AV: E=Sophos;i="4.53,421,1272859200"; d="scan'208";a="472683570" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 15 Jun 2010 12:21:57 -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, 15 Jun 2010 18:21:48 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS: draft-ietf-netconf-monitoring Thread-Index: AcsMprRE4s9YX0K+RmCktDgE70mQhAAACKJg From: "Romascanu, Dan (Dan)" To: Subject: [Netconf] FW: DISCUSS: draft-ietf-netconf-monitoring X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 16:21:55 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Tim Polk Sent: Tuesday, June 15, 2010 7:21 PM To: iesg@ietf.org Cc: draft-ietf-netconf-monitoring@tools.ietf.org; netconf-chairs@tools.ietf.org Subject: DISCUSS: draft-ietf-netconf-monitoring=20 Discuss: This discuss is a placeholder for already agreed updates to the security considerations section. I will clear when the new draft appears or for an RFC Editor note inserting the following at the beginning of the security considerations: The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC4741]. The lowest NETCONF layer is the secure transport layer and the mandatory to implement secure transport is SSH [RFC4742]. From mehmet.ersue@nsn.com Wed Jun 16 05:52:54 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471903A6A38 for ; Wed, 16 Jun 2010 05:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.867, 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 mln-KYphqabU for ; Wed, 16 Jun 2010 05:52:53 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 1832B3A68C7 for ; Wed, 16 Jun 2010 05:52:52 -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 o5GCqq95014491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Jun 2010 14:52:53 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5GCqp8O031254; Wed, 16 Jun 2010 14:52:51 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Jun 2010 14:52:50 +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, 16 Jun 2010 14:52:50 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64984DA7@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Monitoring draft RFC Editors notes Thread-Index: AcsNUtPSut1CE+KTT0C6gkBNNFxL2A== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 16 Jun 2010 12:52:50.0904 (UTC) FILETIME=[D436ED80:01CB0D52] Cc: draft-ietf-netconf-monitoring@tools.ietf.org Subject: [Netconf] Monitoring draft RFC Editors notes X-BeenThere: netconf@ietf.org X-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, 16 Jun 2010 12:52:54 -0000 Hi All, based on the DISCUSSes and comments of the IESG on the Monitoring draft we are going to fix the draft text as added to the RFC editors notes: https://datatracker.ietf.org/doc/draft-ietf-netconf-monitoring/#writeup Please check it and let us know if you find any typo or another immediate issue. The draft will hopefully go through the IESG chat tomorrow. So please indicate only serious issues. Mehmet From hartmans@mit.edu Wed Jun 16 17:26:44 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 963013A67FA; Wed, 16 Jun 2010 17:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_50=0.001, 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 JvNB2-7QsO4J; Wed, 16 Jun 2010 17:26:43 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id C5E193A67B5; Wed, 16 Jun 2010 17:26:40 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 243EF20394; Wed, 16 Jun 2010 20:26:45 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DCEEC40D4; Wed, 16 Jun 2010 20:26:33 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <4C11ED2B.1070707@deployingradius.com> <20100611080956.GA5257@elstar.local> Date: Wed, 16 Jun 2010 20:26:33 -0400 In-Reply-To: <20100611080956.GA5257@elstar.local> (Juergen Schoenwaelder's message of "Fri, 11 Jun 2010 10:09:56 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 17 Jun 2010 00:12:41 -0700 Cc: netconf@ietf.org, "draft-ietf-netconf-monitoring@tools.ietf.org" , IESG IESG , "secdir@ietf.org" Subject: Re: [Netconf] [secdir] secdir review of draft-ietf-netconf-monitoring X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 00:26:44 -0000 >>>>> "Juergen" == Juergen Schoenwaelder writes: >> The document defines a data model for netconf monitoring. The >> security considerations section says in part: >> >> Some of the readable data nodes in this YANG module may be >> considered sensitive or vulnerable in some network environments. >> It is thus important to control read access (e.g. via get, >> get-config or notification) to these data nodes. >> >> What is unclear from the document is whether or not the data is >> secure *after* access is gained. i.e. is there a secure >> transport layer? Should one be used? If not, why? Juergen> NETCONF runs over SSH or TLS or TLS/BEEP or SOAP/HTTPS. In Juergen> other words, all existing NETCONF transports are Juergen> "secure". The revision of the NETCONF specification being Juergen> worked on is going to make this hopefully clearer by Juergen> calling the transport layer "secure transports". I'll admit that if I read the netconf document and it described something as "secure transport," it would raise a concern in my mind. "secure" as an adjective is generally meaningless. Typically it's applied to make people feel that security objectives are met without actually stating those objectives. Presumably by secure, you mean something like: * Transport authenticates identity of server to client and client to server * Transport provides integrity protection and confidentiality for data transported * Transport provides replay protection on a per-session level as well as within a session I'd be far more interested in the core document making these security services explicit than in having it replace all instances of transport with "secure transport." From j.schoenwaelder@jacobs-university.de Thu Jun 17 00:23:57 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B6813A6A27; Thu, 17 Jun 2010 00:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.22 X-Spam-Level: X-Spam-Status: No, score=0.22 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_50=0.001, 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 eDao+QSH3uVG; Thu, 17 Jun 2010 00:23:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B08363A6A14; Thu, 17 Jun 2010 00:23:55 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8323FC0006; Thu, 17 Jun 2010 09:24:00 +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 763au0Pxr9ZS; Thu, 17 Jun 2010 09:23:59 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11F49C0004; Thu, 17 Jun 2010 09:23:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8A5AC1341B6B; Thu, 17 Jun 2010 09:23:50 +0200 (CEST) Date: Thu, 17 Jun 2010 09:23:50 +0200 From: Juergen Schoenwaelder To: Sam Hartman Message-ID: <20100617072350.GA13466@elstar.local> Mail-Followup-To: Sam Hartman , Alan DeKok , "netconf@ietf.org" , "draft-ietf-netconf-monitoring@tools.ietf.org" , IESG IESG , "secdir@ietf.org" References: <4C11ED2B.1070707@deployingradius.com> <20100611080956.GA5257@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: IESG IESG , "draft-ietf-netconf-monitoring@tools.ietf.org" , "secdir@ietf.org" , "netconf@ietf.org" , Alan DeKok Subject: Re: [Netconf] [secdir] secdir review of draft-ietf-netconf-monitoring 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, 17 Jun 2010 07:23:57 -0000 On Thu, Jun 17, 2010 at 02:26:33AM +0200, Sam Hartman wrote: > >>>>> "Juergen" == Juergen Schoenwaelder writes: > > >> The document defines a data model for netconf monitoring. The > >> security considerations section says in part: > >> > >> Some of the readable data nodes in this YANG module may be > >> considered sensitive or vulnerable in some network environments. > >> It is thus important to control read access (e.g. via get, > >> get-config or notification) to these data nodes. > >> > >> What is unclear from the document is whether or not the data is > >> secure *after* access is gained. i.e. is there a secure > >> transport layer? Should one be used? If not, why? > > Juergen> NETCONF runs over SSH or TLS or TLS/BEEP or SOAP/HTTPS. In > Juergen> other words, all existing NETCONF transports are > Juergen> "secure". The revision of the NETCONF specification being > Juergen> worked on is going to make this hopefully clearer by > Juergen> calling the transport layer "secure transports". > > I'll admit that if I read the netconf document and it described > something as "secure transport," it would raise a concern in my mind. > "secure" as an adjective is generally meaningless. Typically it's > applied to make people feel that security objectives are met without > actually stating those objectives. > > Presumably by secure, you mean something like: > > * Transport authenticates identity of server to client and client to > server > * Transport provides integrity protection and confidentiality for data > transported > * Transport provides replay protection on a per-session level as well as > within a session > > I'd be far more interested in the core document making these security > services explicit than in having it replace all instances of transport > with "secure transport." Yes, I agree. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Thu Jun 17 01:50:51 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF35028C0EB for ; Thu, 17 Jun 2010 01:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.265 X-Spam-Level: X-Spam-Status: No, score=-0.265 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_50=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 5ZDQwPOGY1tt for ; Thu, 17 Jun 2010 01:50:48 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 0301228C0E6 for ; Thu, 17 Jun 2010 01:50:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,430,1272859200"; d="scan'208";a="21026665" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 17 Jun 2010 04:50:52 -0400 X-IronPort-AV: E=Sophos;i="4.53,430,1272859200"; d="scan'208";a="484136609" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Jun 2010 04:50:51 -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: Thu, 17 Jun 2010 10:50:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS and COMMENT: draft-ietf-netconf-monitoring Thread-Index: AcsNsER59jX7RIZ8S9mo2DRKEErORQAScwSA From: "Romascanu, Dan (Dan)" To: Subject: [Netconf] FW: DISCUSS and COMMENT: draft-ietf-netconf-monitoring X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 08:50:51 -0000 I-D Editors, Please address the issues raised by David Harrington.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of David Harrington Sent: Thursday, June 17, 2010 3:02 AM To: iesg@ietf.org Cc: draft-ietf-netconf-monitoring@tools.ietf.org; netconf-chairs@tools.ietf.org Subject: DISCUSS and COMMENT: draft-ietf-netconf-monitoring=20 Discuss: Good job. I ma glad to see this work and the YANG work progressing. I have a few thinsg i think should be addressed before this is approved as a standard. 1) username - in ISMS we had a lot of trouble determining when and if the user-name from SSH was actually available, and the SSH username can be blank (IIRC). In other transport authentication schemes, a username may not be available. But this information might be critical for use in access control decisions, which currently are implementation-specific. Security considerations does not discuss this potential problem. In ISMS, SSHTM permitted transformations from the "username" used by the transport to a management-system specific identifier. In USM, this is also done via a user table assignment. You should be careful about locking yourself in. 2) existing security infrastructures, such as SSH, may offer features that would make doing a direct mapping between user-name and the nsm username. Because naming policies might differ between administrative domains, many SSH client software packages support a user@hostname:port addressing syntax that operators can use to align non-equivalent account names. The SnmpSSHAddress Textual Convention echos this common SSH notation. Again, you might want to avoid a direct mapping requirement. I recommend removing the statement about how username is set from SSH, and simply state that the identity is established by the Netconf transport protocol. Let the Netconf-ssh decide how to establish a username. 3) the algorithm to derive the username is implementation-specific. The security considerations should discuss that different implementations might derive the same username for different users, so the value might not be comparable across implementatons. In ISMS, we addressed the issue that an SSH transport model might come up wth a name, and then a TLS transport model come up with the same name, even within the same management system. Given that the username might be used to identify who made an undesirable change, and to discipline that person, this is a pretty big "well, maybe this means this user, and maybe it means that user."=20 4) Your use of "RFC XXXX" is ambiguous. "identity YANG" and "identity yin" call for a reference to RFC XXXX (the YANG RFC), as does the "module" and "revision" statements (the monitoring RFC). These are different XXXX's. 5) container sessions has an exclusion statement that can be interpreted different ways: "Any session not managed by the NETCONF server ... MUST be excluded" versus "(Any session ... with session identifier 0) MUST be excluded" versus "(Any session not managed ... with session identifier 0) MUST be excluded" (which would exclude all non-zero sessions) Can you tighten this? 6) To avoid unused reference warnings from idnits, in MIB modules we specify outside the module itself what normative references exist in the module and provide citations. Comment: 1) section provides an overview of data "which MUST be present". "MUST" is usually used to specify normative behavior. I suggest you specifically say that section 2 is a "non-normative overview", so that if there are errata that lead to conflicts between 2 and 5, there is no question that section 2 is non-normative, and section 5 is normative. 2) login-time. since clocks on the server and client can differ, this should say the "Time at the server at which the session was established." 3) source-host: this is the netconf client? (which could be different than, say, the SSH client or the TLS client, etc.)=20 4) leaf source-host s/is likely to be implementation-specific /is implementation-specific From mehmet.ersue@nsn.com Thu Jun 17 03:20:18 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91F353A67F6 for ; Thu, 17 Jun 2010 03:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.275 X-Spam-Level: X-Spam-Status: No, score=-1.275 tagged_above=-999 required=5 tests=[AWL=-0.164, 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 q7-Cv1q0np9W for ; Thu, 17 Jun 2010 03:20:17 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 903453A6920 for ; Thu, 17 Jun 2010 03:20:16 -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 o5HAK4Jj028750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Jun 2010 12:20:04 +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 o5HAK3Cd013890; Thu, 17 Jun 2010 12:20:04 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Jun 2010 12:20:03 +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, 17 Jun 2010 12:20:02 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A649BBEB0@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS and COMMENT: draft-ietf-netconf-monitoring Thread-Index: AcsN/udSaqrbUz/fRuiEkYoqWXAfEAABqAcQ From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 17 Jun 2010 10:20:03.0530 (UTC) FILETIME=[A6726AA0:01CB0E06] Subject: [Netconf] FW: DISCUSS and COMMENT: draft-ietf-netconf-monitoring X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 10:20:18 -0000 =20 Dear NETCONF WG, below is the response Martin sent to one of the last DISCUSSes. Mehmet -----Original Message----- From: ext Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Thursday, June 17, 2010 11:24 AM To: ietfdbh@comcast.net Cc: iesg@ietf.org; netconf-chairs@tools.ietf.org; draft-ietf-netconf-monitoring@tools.ietf.org Subject: Re: DISCUSS and COMMENT: draft-ietf-netconf-monitoring=20 Hi David, David Harrington wrote: > Discuss: > Good job. I ma glad to see this work and the YANG work progressing. > I have a few thinsg i think should be addressed before this is approved as a > standard. >=20 > 1) username - in ISMS we had a lot of trouble determining when and if the > user-name from SSH was actually available, and the SSH username can be blank > (IIRC). In other transport authentication schemes, a username may not be > available. But this information might be critical for use in access control > decisions, which currently are implementation-specific. Security considerations > does not discuss this potential problem. I agree that this info is critical for access control, but in this document the user name is simply reported for monitoring purposes, so I do not see how the security considerations in this document should discuss this. > In ISMS, SSHTM permitted transformations from the "username" used by the > transport to a management-system specific identifier. In USM, this is also done > via a user table assignment. You should be careful about locking yourself in. >=20 > 2) existing security infrastructures, such as SSH, may offer features that > would make doing a direct mapping between user-name and the nsm username. > Because naming policies might differ between administrative domains, > many SSH client software packages support a user@hostname:port > addressing syntax that operators can use to align non-equivalent > account names. The SnmpSSHAddress Textual Convention echos this > common SSH notation. > Again, you might want to avoid a direct mapping requirement. >=20 > I recommend removing the statement about how username is set from SSH, and > simply state that the identity is established by the Netconf transport > protocol. Let the Netconf-ssh decide how to establish a username. I agree. This makes sense. Following your recommendation, I propose this change (in two places; the text and YANG module): OLD: The username is the client identity that was authenticated by the NETCONF transport protocol. The algorithm used to derive the username is NETCONF transport protocol specific and in addition specific to the authentication mechanism used by the NETCONF transport protocol. =20 For NETCONF over SSH (RFC4742), the username is the 'user name' in the SSH_MSG_USERAUTH_REQUEST (RFC4252, Section 5). =20 For other transport protocols, the algorithm to derive the username is implementation specific. =20 NEW: The username is the client identity that was authenticated by the NETCONF transport protocol. The algorithm used to derive the username is NETCONF transport protocol specific and in addition specific to the authentication mechanism used by the NETCONF transport protocol. > 3) the algorithm to derive the username is implementation-specific. The > security considerations should discuss that different implementations might > derive the same username for different users, so the value might not be > comparable across implementatons. In ISMS, we addressed the issue that an SSH > transport model might come up wth a name, and then a TLS transport model come > up with the same name, even within the same management system. Given that the > username might be used to identify who made an undesirable change, and to > discipline that person, this is a pretty big "well, maybe this means this user, > and maybe it means that user." With the text proposed above we now simply say that the mechanism to derive the username is transport specific. In the session list defined in this document, we list the username and the transport used for the session, so I think this addresses your concern that different transports may derive the same user name. > 4) Your use of "RFC XXXX" is ambiguous. "identity YANG" and "identity yin" call > for a reference to RFC XXXX (the YANG RFC), as does the "module" and "revision" > statements (the monitoring RFC). These are different XXXX's. Each such "XXXX" has a comment to the RFC editor to replace with the proper RFC number. But if this ambigous to the RFC editor we can of course use YYYY etc. as necessary. > 5) container sessions has an exclusion statement that can be interpreted > different ways: > "Any session not managed by the NETCONF server ... MUST be excluded" versus > "(Any session ... with session identifier 0) MUST be excluded" > versus > "(Any session not managed ... with session identifier 0) MUST be excluded" > (which would exclude all non-zero sessions) > Can you tighten this? We simply want to say that all netconf sessions are listed, and I think the last part is not needed anymore, so I suggest: OLD: "All NETCONF sessions managed by the NETCONF server MUST be reported in this list. =20 Any sessions not managed by the NETCONF server with session identifier 0 MUST be excluded."; NEW: "All NETCONF sessions managed by the NETCONF server MUST be reported in this list."; =20 > 6) To avoid unused reference warnings from idnits, in MIB modules we specify > outside the module itself what normative references exist in the module and > provide citations. Ok. I suggest we add to section 5, before : This YANG module imports typedefs from [YANG-TYPES] and references [RFC4741], [RFC4742], [RFC4743], [RFC4744], [RFC5539], [xmlschema-2], [YANG], [ISO/IEC 19757-2:2008], and [RFC5717]. > Comment: > 1) section provides an overview of data "which MUST be present". "MUST" is > usually used to specify normative behavior. I suggest you specifically say that > section 2 is a "non-normative overview", so that if there are errata that lead > to conflicts between 2 and 5, there is no question that section 2 is > non-normative, and section 5 is normative. As a result of another comment, this text was changed to: This section presents an overview of the monitoring data model. For detailed descriptions refer to the normative YANG module provided in this document (see Section 5). > 2) login-time. since clocks on the server and client can differ, this should > say the "Time at the server at which the session was established." Ok. > 3) source-host: this is the netconf client? (which could be different than, > say, the SSH client or the TLS client, etc.) Yes, I will change to "NETCONF client". > 4) leaf source-host=20 > s/is likely to be implementation-specific > /is implementation-specific Ok. /martin From mbj@tail-f.com Thu Jun 17 03:41:53 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34FAD3A6856 for ; Thu, 17 Jun 2010 03:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.183 X-Spam-Level: X-Spam-Status: No, score=0.183 tagged_above=-999 required=5 tests=[AWL=-0.185, 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 Fc04uJHo004F for ; Thu, 17 Jun 2010 03:41:52 -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 CB8F63A6959 for ; Thu, 17 Jun 2010 03:41:51 -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 CE8F8616001; Thu, 17 Jun 2010 12:41:55 +0200 (CEST) Date: Thu, 17 Jun 2010 12:41:55 +0200 (CEST) Message-Id: <20100617.124155.227023668.mbj@tail-f.com> To: mehmet.ersue@nsn.com From: Martin Bjorklund In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A649BBEB0@DEMUEXC006.nsn-intra.net> References: <80A0822C5E9A4440A5117C2F4CD36A649BBEB0@DEMUEXC006.nsn-intra.net> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] DISCUSS and COMMENT: draft-ietf-netconf-monitoring X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 10:41:53 -0000 Hi, "Ersue, Mehmet (NSN - DE/Munich)" wrote: > > 2) existing security infrastructures, such as SSH, may offer features > that > > would make doing a direct mapping between user-name and the nsm > username. > > Because naming policies might differ between administrative > domains, > > many SSH client software packages support a user@hostname:port > > addressing syntax that operators can use to align non-equivalent > > account names. The SnmpSSHAddress Textual Convention echos this > > common SSH notation. > > Again, you might want to avoid a direct mapping requirement. > > > > I recommend removing the statement about how username is set from SSH, > and > > simply state that the identity is established by the Netconf transport > > protocol. Let the Netconf-ssh decide how to establish a username. > > I agree. This makes sense. Following your recommendation, I propose > this change (in two places; the text and YANG module): > > OLD: > > The username is the client identity that was authenticated by the > NETCONF transport protocol. The algorithm used to derive the > username is NETCONF transport protocol specific and in addition > specific to the authentication mechanism used by the NETCONF > transport protocol. > > For NETCONF over SSH (RFC4742), the username is the 'user name' > in the SSH_MSG_USERAUTH_REQUEST (RFC4252, Section 5). > > For other transport protocols, the algorithm to derive the username > is implementation specific. > > NEW: > > The username is the client identity that was authenticated by the > NETCONF transport protocol. The algorithm used to derive the > username is NETCONF transport protocol specific and in addition > specific to the authentication mechanism used by the NETCONF > transport protocol. It turns out that the 'user name' field can be empty, and the real user name derived from other authentication messages, see section 3.1 and 3.2 of RFC 4462. Instead of going into these details in this document, I think it is better to just say that we report the user name that the transport gives us. We can always discuss if 4742bis should talk about this or not. For reference, RFC 5592 says in 4.1.1: How the SSH user name is extracted from the SSH layer is implementation-dependent. /martin From j.schoenwaelder@jacobs-university.de Thu Jun 17 03:55:53 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF0303A67E3 for ; Thu, 17 Jun 2010 03:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.135 X-Spam-Level: X-Spam-Status: No, score=0.135 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_40=-0.185, 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 vHjKZzcwWiIK for ; Thu, 17 Jun 2010 03:55:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BC0633A699C for ; Thu, 17 Jun 2010 03:55:52 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A46EDC0016; Thu, 17 Jun 2010 12:55:57 +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 6V-uVPsKhb-9; Thu, 17 Jun 2010 12:55:56 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E912DC000A; Thu, 17 Jun 2010 12:55:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C322A13424AF; Thu, 17 Jun 2010 12:55:50 +0200 (CEST) Date: Thu, 17 Jun 2010 12:55:50 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100617105550.GD14063@elstar.local> Mail-Followup-To: Martin Bjorklund , "mehmet.ersue@nsn.com" , "netconf@ietf.org" References: <80A0822C5E9A4440A5117C2F4CD36A649BBEB0@DEMUEXC006.nsn-intra.net> <20100617.124155.227023668.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100617.124155.227023668.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] DISCUSS and COMMENT: draft-ietf-netconf-monitoring 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, 17 Jun 2010 10:55:53 -0000 On Thu, Jun 17, 2010 at 12:41:55PM +0200, Martin Bjorklund wrote: > It turns out that the 'user name' field can be empty, and the real > user name derived from other authentication messages, see section 3.1 > and 3.2 of RFC 4462. Instead of going into these details in this > document, I think it is better to just say that we report the user > name that the transport gives us. > > We can always discuss if 4742bis should talk about this or not. I agree that 4742bis is the right place to discuss this. As mentioned in a separate thread, 4741bis should state which security services the secure transports must provide and 4741bis should IMHO establish a requirement that specifications of secure transports must provide a section explaining how an authenticated user name can be provided. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Jun 17 04:20:24 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 831FF3A699C; Thu, 17 Jun 2010 04:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_40=-0.185, 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 GtYShkVDmjdO; Thu, 17 Jun 2010 04:19:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 753F53A6991; Thu, 17 Jun 2010 04:19:59 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C4A66C001E; Thu, 17 Jun 2010 13:20:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2lCBb1Levami; Thu, 17 Jun 2010 13:20:02 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 546A0C001A; Thu, 17 Jun 2010 13:20:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C63E01342766; Thu, 17 Jun 2010 13:19:55 +0200 (CEST) Date: Thu, 17 Jun 2010 13:19:55 +0200 From: Juergen Schoenwaelder To: Sam Hartman Message-ID: <20100617111955.GA13803@elstar.local> Mail-Followup-To: Sam Hartman , Alan DeKok , "netconf@ietf.org" , "draft-ietf-netconf-monitoring@tools.ietf.org" , IESG IESG , "secdir@ietf.org" References: <4C11ED2B.1070707@deployingradius.com> <20100611080956.GA5257@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: IESG IESG , "draft-ietf-netconf-monitoring@tools.ietf.org" , "secdir@ietf.org" , "netconf@ietf.org" , Alan DeKok Subject: Re: [Netconf] [secdir] secdir review of draft-ietf-netconf-monitoring 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, 17 Jun 2010 11:20:25 -0000 On Thu, Jun 17, 2010 at 02:26:33AM +0200, Sam Hartman wrote: > I'll admit that if I read the netconf document and it described > something as "secure transport," it would raise a concern in my mind. > "secure" as an adjective is generally meaningless. Typically it's > applied to make people feel that security objectives are met without > actually stating those objectives. > > Presumably by secure, you mean something like: > > * Transport authenticates identity of server to client and client to > server > * Transport provides integrity protection and confidentiality for data > transported > * Transport provides replay protection on a per-session level as well as > within a session > > I'd be far more interested in the core document making these security > services explicit than in having it replace all instances of transport > with "secure transport." There is text in section 2 of draft-ietf-netconf-4741bis-02 talking about security requirements of the transports - and this text is pretty much the same as the text that can be found in section 2 of RFC 4741. I will go over the text to see whether it can be further tightened or detailed (e.g. I see replay protection is not explicitely mentioned). But it definitely not the case that "secure transport" is a meaningless adjective in the NETCONF world even today. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Thu Jun 17 04:53:57 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31FF03A681D for ; Thu, 17 Jun 2010 04:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.594 X-Spam-Level: X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[AWL=1.005, 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 fyhMILSQhD+E for ; Thu, 17 Jun 2010 04:53:53 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id DFAB03A699C for ; Thu, 17 Jun 2010 04:53:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,431,1272859200"; d="scan'208";a="21049038" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 17 Jun 2010 07:53:57 -0400 X-IronPort-AV: E=Sophos;i="4.53,431,1272859200"; d="scan'208";a="473348694" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 17 Jun 2010 07:53:26 -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: Thu, 17 Jun 2010 13:53:21 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS and COMMENT: draft-ietf-netconf-monitoring Thread-Index: AcsOEUgqvP5pdvo1S4aSh6Z0graHRwAAlMhA From: "Romascanu, Dan (Dan)" To: Subject: [Netconf] FW: DISCUSS and COMMENT: draft-ietf-netconf-monitoring X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 11:53:57 -0000 A new DISCUSS - please address the issues raised by Adrian.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Thursday, June 17, 2010 2:36 PM To: iesg@ietf.org Cc: draft-ietf-netconf-monitoring@tools.ietf.org; netconf-chairs@tools.ietf.org Subject: DISCUSS and COMMENT: draft-ietf-netconf-monitoring=20 Discuss: I think [4741bis] is used normatively. Please makeit a normative reference. --- Aren't the RFCs cited from Reference clauses really normative references? (As Dave says, to avoid citation issues, you should include some text such as... "This module makes use of references to [1], [2], ..." ) Comment: Section 3.1 Are there no other negative responses to get-schema? What about policy failures? --- Please think about whether the Reference clauses that cite RFC4741 should actually point to 4741bis. From hartmans@mit.edu Thu Jun 17 06:01:46 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFDB63A6901; Thu, 17 Jun 2010 06:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=0.211, 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 dptNKHHZOnP1; Thu, 17 Jun 2010 06:01:45 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id BFA9A3A68B3; Thu, 17 Jun 2010 06:01:44 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 3D1B220036; Thu, 17 Jun 2010 09:01:45 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D615240D4; Thu, 17 Jun 2010 09:01:32 -0400 (EDT) From: Sam Hartman To: Sam Hartman References: <4C11ED2B.1070707@deployingradius.com> <20100611080956.GA5257@elstar.local> <20100617111955.GA13803@elstar.local> Date: Thu, 17 Jun 2010 09:01:32 -0400 In-Reply-To: <20100617111955.GA13803@elstar.local> (Juergen Schoenwaelder's message of "Thu, 17 Jun 2010 13:19:55 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: IESG IESG , "draft-ietf-netconf-monitoring@tools.ietf.org" , "secdir@ietf.org" , "netconf@ietf.org" , Alan DeKok Subject: Re: [Netconf] [secdir] secdir review of draft-ietf-netconf-monitoring X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 13:01:47 -0000 OK. I did review the netconf core spec when it came before the IESG and was happy with it at the time. From dromasca@avaya.com Thu Jun 17 09:03:45 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F423D3A69AE for ; Thu, 17 Jun 2010 09:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.658 X-Spam-Level: X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[AWL=0.941, 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 POkjlAqZdr54 for ; Thu, 17 Jun 2010 09:03:44 -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 B02B23A6914 for ; Thu, 17 Jun 2010 09:03:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,432,1272859200"; d="scan'208";a="193952681" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 17 Jun 2010 12:03:46 -0400 X-IronPort-AV: E=Sophos;i="4.53,432,1272859200"; d="scan'208";a="484273516" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Jun 2010 12:03:46 -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: Thu, 17 Jun 2010 18:03:42 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-netconf-monitoring - Revised ID needed Thread-Index: AcsONqiZx+RoESWzT8WFrffDHwp2Pw== From: "Romascanu, Dan (Dan)" To: Subject: [Netconf] draft-ietf-netconf-monitoring - Revised ID needed X-BeenThere: netconf@ietf.org X-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, 17 Jun 2010 16:03:45 -0000 The IESG discussed draft-ietf-netconf-monitoring in the IESG telechat today. There are two pending DISCUSSes on their way to being resolved, but still needing the final edits, and a number of changes in the RFC Editor notes from previous DISCUSSes, COMMENTs from the AD's and other comments. The IESG decided to ask the editors to issue a revised I-D including all the changes. Please go ahead with closing the open issues and issue the revised I-D, then we can ask David and Adrian to clear.=20 Thanks and Regards, Dan From ietfc@btconnect.com Fri Jun 18 07:37:42 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29DF3A68CF for ; Fri, 18 Jun 2010 07:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.367 X-Spam-Level: X-Spam-Status: No, score=-0.367 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_50=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 VolKzDNcCSOq for ; Fri, 18 Jun 2010 07:37:35 -0700 (PDT) Received: from c2beaomr04.btconnect.com (c2beaomr04.btconnect.com [213.123.26.182]) by core3.amsl.com (Postfix) with ESMTP id 5B8933A683E for ; Fri, 18 Jun 2010 07:37:35 -0700 (PDT) Received: from pc6 (host81-153-11-165.range81-153.btcentralplus.com [81.153.11.165]) by c2beaomr04.btconnect.com with SMTP id CFA78251; Fri, 18 Jun 2010 15:37:08 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A020302.4C1B8493.0365, actions=tag Message-ID: <006b01cb0eea$ea6ded80$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Ersue, Mehmet \(NSN - DE/Munich\)" , References: <80A0822C5E9A4440A5117C2F4CD36A64984DA7@DEMUEXC006.nsn-intra.net> Date: Fri, 18 Jun 2010 15:33:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Junkmail-Status: score=10/50, host=c2beaomr04.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A020203.4C1B84B3.00D1,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: draft-ietf-netconf-monitoring@tools.ietf.org Subject: Re: [Netconf] Monitoring draft RFC Editors notes X-BeenThere: netconf@ietf.org X-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, 18 Jun 2010 14:37:42 -0000 ----- Original Message ----- From: "Ersue, Mehmet (NSN - DE/Munich)" To: Cc: Sent: Wednesday, June 16, 2010 2:52 PM > > based on the DISCUSSes and comments of the IESG on the Monitoring draft > we are going to fix the draft text as added to the RFC editors notes: > https://datatracker.ietf.org/doc/draft-ietf-netconf-monitoring/#writeup > > Please check it and let us know if you find any typo or another > immediate issue. only that every time I click on the URI, I get a long, long wait, CRL downloaded and a long long wait and (oh the anticipation) a blank screen No matter, I am sure that by now someone else will have thought of everything I would have thought of. Tom Petch > > The draft will hopefully go through the IESG chat tomorrow. > So please indicate only serious issues. > > Mehmet > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From andyb@iwl.com Fri Jun 18 07:46:31 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1407C3A6A0A for ; Fri, 18 Jun 2010 07:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 S8trSr+mw88q for ; Fri, 18 Jun 2010 07:46:26 -0700 (PDT) Received: from smtp224.iad.emailsrvr.com (smtp224.iad.emailsrvr.com [207.97.245.224]) by core3.amsl.com (Postfix) with ESMTP id 93A103A6A89 for ; Fri, 18 Jun 2010 07:46:25 -0700 (PDT) Received: from relay12.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay12.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 7CA8B20D8CB; Fri, 18 Jun 2010 10:46:30 -0400 (EDT) Received: by relay12.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 05D4C20DC13; Fri, 18 Jun 2010 10:46:29 -0400 (EDT) Message-ID: <4C1B8669.2020909@iwl.com> Date: Fri, 18 Jun 2010 07:44:57 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: "t.petch" References: <80A0822C5E9A4440A5117C2F4CD36A64984DA7@DEMUEXC006.nsn-intra.net> <006b01cb0eea$ea6ded80$4001a8c0@gateway.2wire.net> In-Reply-To: <006b01cb0eea$ea6ded80$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-netconf-monitoring@tools.ietf.org, netconf@ietf.org Subject: Re: [Netconf] Monitoring draft RFC Editors notes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2010 14:46:31 -0000 On 06/18/2010 06:33 AM, t.petch wrote: > ----- Original Message ----- > From: "Ersue, Mehmet (NSN - DE/Munich)" > To: > Cc: > Sent: Wednesday, June 16, 2010 2:52 PM > >> based on the DISCUSSes and comments of the IESG on the Monitoring draft >> we are going to fix the draft text as added to the RFC editors notes: >> https://datatracker.ietf.org/doc/draft-ietf-netconf-monitoring/#writeup >> >> Please check it and let us know if you find any typo or another >> immediate issue. >> > only that every time I click on the URI, I get a long, long wait, CRL downloaded > and a long long wait and > (oh the anticipation) > > a blank screen > > loads fine for me (firefox 3.5 on ubuntu 10.04) draft edits look good; no issues; > No matter, I am sure that by now someone else will have thought of everything I > would have thought of. > > Tom Petch > > > Andy From andyb@iwl.com Sat Jun 19 09:37:26 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14FE3A6801 for ; Sat, 19 Jun 2010 09:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_50=0.001, 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 eH6qrqhs5tES for ; Sat, 19 Jun 2010 09:37:24 -0700 (PDT) Received: from smtp144.dfw.emailsrvr.com (smtp144.dfw.emailsrvr.com [67.192.241.144]) by core3.amsl.com (Postfix) with ESMTP id F12C53A67DA for ; Sat, 19 Jun 2010 09:37:23 -0700 (PDT) Received: from relay24.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay24.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id C85EC34E831F for ; Sat, 19 Jun 2010 12:37:29 -0400 (EDT) Received: by relay24.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id AADFF34E8250 for ; Sat, 19 Jun 2010 12:37:29 -0400 (EDT) Message-ID: <4C1CF1E5.4020802@iwl.com> Date: Sat, 19 Jun 2010 09:35:49 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] warnings: retake X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2010 16:37:26 -0000 Hi, I am thought a bit more about NETCONF warnings. We had it all wrong before. Circa 4741, we were so clueless we didn't even realize warnings were not even possible. (Sounds like a bug to me.) The notion of returning warnings *with* is also somewhat clueless. It's too late by then to act on the warnings. Those annoying warning dialogs that applications pop up are done before an action, not after. They are a lot of work to hard-wire in the client, and it should would be nice if NETCONF servers helped out. What is really needed is a bit in the to indicate if the error can be ignored, even though there may be operational consequences, and another bit in the to indicate that ignorable errors should be ignored or not. The use-case I have now is a operation. A client can set defaults just for that session. But setting the default 'with-defaults' to something other than the basic-mode can be dangerous if editing is done based on data retrieved in another mode. It is much more scalable to have the server describe its own set of warnings than hard-wire them into an application. Right now, there is no way to even return a warning, so that a client will know to try again. It will get some error and cancel the operation in progress. Andy From andyb@iwl.com Mon Jun 21 09:29:49 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E37023A6A85 for ; Mon, 21 Jun 2010 09:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.292 X-Spam-Level: X-Spam-Status: No, score=-0.292 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_50=0.001, 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 1x-3qoO4wNa8 for ; Mon, 21 Jun 2010 09:29:46 -0700 (PDT) Received: from smtp154.dfw.emailsrvr.com (smtp154.dfw.emailsrvr.com [67.192.241.154]) by core3.amsl.com (Postfix) with ESMTP id 7028D3A69ED for ; Mon, 21 Jun 2010 09:29:45 -0700 (PDT) Received: from relay15.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay15.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 533A330B13FF for ; Mon, 21 Jun 2010 12:29:52 -0400 (EDT) Received: by relay15.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 311D230B1381 for ; Mon, 21 Jun 2010 12:29:52 -0400 (EDT) Message-ID: <4C1F9382.3000900@iwl.com> Date: Mon, 21 Jun 2010 09:29:54 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: NETCONF References: <4C1CF1E5.4020802@iwl.com> In-Reply-To: <4C1CF1E5.4020802@iwl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] warnings: retake X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 16:29:49 -0000 On 06/19/2010 09:35 AM, Andy Bierman wrote: I guess the WG does not want to consider RPC warnings further. (too bad... ;-) I left out an acceptable solution, which is what Kent is already doing. We can just add text to 4741bis that says a server MAY choose to set the error-severity to 'warning' instead of 'error'. The error templates just describe the default severity, but the server can decide if it is a recoverable error or not. Unless there are any strong objections, I am going to make this edit to 4741bis. There is nothing in the 4741 protocol definition that says a client does not have to be able to handle error-severity='warning' if the server sends it. It is just our rigid interpretation of the error appendix text that is the source of that CLR. IMO, Kent is not violating 4741 by sending operation-failed as a warning. I was wrong before -- a 4741 client MUST be able to accept error-severity='warning', so this should be a safe server clarification to make in 4741bis. Andy > Hi, > > I am thought a bit more about NETCONF warnings. > We had it all wrong before. Circa 4741, we were so > clueless we didn't even realize warnings were not > even possible. (Sounds like a bug to me.) > > The notion of returning warnings *with* > is also somewhat clueless. It's too late by then > to act on the warnings. > > Those annoying warning dialogs that applications > pop up are done before an action, not after. > They are a lot of work to hard-wire in the client, > and it should would be nice if NETCONF servers > helped out. > > What is really needed is a bit in the > to indicate if the error can be ignored, even > though there may be operational consequences, > and another bit in the to indicate that > ignorable errors should be ignored or not. > > The use-case I have now is a operation. > A client can set defaults just for that session. > But setting the default 'with-defaults' to something other > than the basic-mode can be dangerous if editing is done > based on data retrieved in another mode. > > It is much more scalable to have the server describe its > own set of warnings than hard-wire them into an application. > Right now, there is no way to even return a warning, > so that a client will know to try again. It will get some > error and cancel the operation in progress. > > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From andyb@iwl.com Mon Jun 21 11:05:43 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346BA3A68CE for ; Mon, 21 Jun 2010 11:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.244 X-Spam-Level: X-Spam-Status: No, score=-0.244 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_50=0.001, 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 4sY8SBkXi7UP for ; Mon, 21 Jun 2010 11:05:42 -0700 (PDT) Received: from smtp144.dfw.emailsrvr.com (smtp144.dfw.emailsrvr.com [67.192.241.144]) by core3.amsl.com (Postfix) with ESMTP id 67BF03A67D1 for ; Mon, 21 Jun 2010 11:05:42 -0700 (PDT) Received: from relay14.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay14.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 721839084BE for ; Mon, 21 Jun 2010 14:05:49 -0400 (EDT) Received: by relay14.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 53DCB90851C for ; Mon, 21 Jun 2010 14:05:49 -0400 (EDT) Message-ID: <4C1FAA01.1090306@iwl.com> Date: Mon, 21 Jun 2010 11:05:53 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] partial-lock, sec. 2.4.1.1 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 18:05:43 -0000 Hi, Now that I am re-reading RFC 5717 in the context of a specific access control model, instead of in the abstract, this paragraph seems wrong: If access control denies the partial lock, the is 'access-denied'. Access control SHOULD be checked before checking for conflicting locks to avoid giving out information about other sessions to an unauthorized client. XPath becomes somewhat useless, due to inadvertent matching of nodes for which the user does not have access, if access-denied is returned instead of skipping the unauthorized node. E.g., the request select="//interface[starts-with(name, 'eth')]" might match an ethernet interface that this user is unaware of, because it is never visible in replies for that user. The server understands that, and interprets the request as "select all the interfaces that I have proper access rights, which also match this filter". The list of locked nodes will never include one that is unauthorized for that user. The locked node set may end up being empty due to access control, but the entire request will not be rejected because the server removes some of the nodes that would have matched, if the user had proper access rights. The reply always states exactly what was locked. Andy From mbj@tail-f.com Mon Jun 21 13:38:15 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E31328C11F for ; Mon, 21 Jun 2010 13:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.343 X-Spam-Level: X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[AWL=-0.211, 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 BGv038fYJbvN for ; Mon, 21 Jun 2010 13:38:14 -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 66F0028C126 for ; Mon, 21 Jun 2010 13:38:12 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 2B9F776C099; Mon, 21 Jun 2010 22:38:18 +0200 (CEST) Date: Mon, 21 Jun 2010 22:38:17 +0200 (CEST) Message-Id: <20100621.223817.123897571.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4C1F9382.3000900@iwl.com> References: <4C1CF1E5.4020802@iwl.com> <4C1F9382.3000900@iwl.com> X-Mailer: Mew version 7.0.50 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] warnings: retake X-BeenThere: netconf@ietf.org X-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, 21 Jun 2010 20:38:15 -0000 Hi, Andy Bierman wrote: > On 06/19/2010 09:35 AM, Andy Bierman wrote: > > I guess the WG does not want to consider RPC warnings > further. (too bad... ;-) > > I left out an acceptable solution, which is what Kent is already > doing. We can just add text to 4741bis that says a server MAY > choose to set the error-severity to 'warning' instead of 'error'. > The error templates just describe the default severity, but the server > can decide if it is a recoverable error or not. > > Unless there are any strong objections, I am going to make this edit > to 4741bis. I object. What exactly does error-tag 'in-use' with severity 'warning' mean? Or, for that matter, 'operation-failed'? I think the severity in the appendix is not just picked at random, but thought through. If we need a separate warning tag, we should add that, but this has been discussed before in the WG, and we saw no consensus on a solution. I think you recently said that we need to finish 4741bis, and not keep debating issues that do not have consensus. For the record, I would have liked to see a mechanism with warnings that worked, but as we have seen before in the discussions about warnings, it is not that easy. /martin From andyb@iwl.com Mon Jun 21 15:01:51 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E5523A6872 for ; Mon, 21 Jun 2010 15:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.203 X-Spam-Level: X-Spam-Status: No, score=-0.203 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_50=0.001, 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 kcPsvTjc+dTb for ; Mon, 21 Jun 2010 15:01:50 -0700 (PDT) Received: from smtp174.dfw.emailsrvr.com (smtp174.dfw.emailsrvr.com [67.192.241.174]) by core3.amsl.com (Postfix) with ESMTP id 1EC7C3A67B8 for ; Mon, 21 Jun 2010 15:01:50 -0700 (PDT) Received: from relay17.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay17.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 162172C7260B; Mon, 21 Jun 2010 18:01:57 -0400 (EDT) Received: by relay17.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id DB70A2C72633; Mon, 21 Jun 2010 18:01:56 -0400 (EDT) Message-ID: <4C1FE159.9060805@iwl.com> Date: Mon, 21 Jun 2010 15:02:01 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Martin Bjorklund References: <4C1CF1E5.4020802@iwl.com> <4C1F9382.3000900@iwl.com> <20100621.223817.123897571.mbj@tail-f.com> In-Reply-To: <20100621.223817.123897571.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] warnings: retake X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 22:01:51 -0000 On 06/21/2010 01:38 PM, Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: > >> On 06/19/2010 09:35 AM, Andy Bierman wrote: >> >> I guess the WG does not want to consider RPC warnings >> further. (too bad... ;-) >> >> I left out an acceptable solution, which is what Kent is already >> doing. We can just add text to 4741bis that says a server MAY >> choose to set the error-severity to 'warning' instead of 'error'. >> The error templates just describe the default severity, but the server >> can decide if it is a recoverable error or not. >> >> Unless there are any strong objections, I am going to make this edit >> to 4741bis. >> > I object. What exactly does error-tag 'in-use' with severity > 'warning' mean? Or, for that matter, 'operation-failed'? I think the > severity in the appendix is not just picked at random, but > thought through. > > If we need a separate warning tag, we should add that, but this has > been discussed before in the WG, and we saw no consensus on a > solution. I think you recently said that we need to finish 4741bis, > and not keep debating issues that do not have consensus. > > For the record, I would have liked to see a mechanism with warnings > that worked, but as we have seen before in the discussions about > warnings, it is not that easy. > > What if it was limited to a new error-tag only in 1.1? Then it is still up to vendors to use this error-tag. It will not break any clients because only a 1.1 client can get a 1.1 session, and only 1.1 servers would ever send error-severity=warning. Two people who actually write NETCONF applications say this is needed. Vendors will make up their own solutions, as we have seen, so this standards stuff is just a formality anyway. > /martin > > Andy From root@core3.amsl.com Mon Jun 21 23:30:15 2010 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 808AF3A686B; Mon, 21 Jun 2010 23: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: <20100622063009.808AF3A686B@core3.amsl.com> Date: Mon, 21 Jun 2010 23:30:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-15.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, 22 Jun 2010 06:30:15 -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 : YANG Module for NETCONF Monitoring Author(s) : M. Scott, M. Bjorklund Filename : draft-ietf-netconf-monitoring-15.txt Pages : 39 Date : 2010-06-21 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-15.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-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-21232656.I-D@ietf.org> --NextPart-- From bertietf@bwijnen.net Tue Jun 22 01:18:35 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0E7B28C132 for ; Tue, 22 Jun 2010 01:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[AWL=0.966, 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 k1Yl2CPGQRxz for ; Tue, 22 Jun 2010 01:18:33 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 84D0B28C0EF for ; Tue, 22 Jun 2010 01:18:32 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.1.103]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OQygi-0007Ac-Iy for netconf@ietf.org; Tue, 22 Jun 2010 10:18:38 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-67.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OQygi-0000vh-EA for netconf@ietf.org; Tue, 22 Jun 2010 10:18:32 +0200 Message-ID: <4C2071D8.4030200@bwijnen.net> Date: Tue, 22 Jun 2010 10:18:32 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4e5dfaef544a3eacd1719c060019e393a X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4e5dfaef544a3eacd1719c060019e393a Subject: [Netconf] FW: Nomcom 2010-2011: Second Call for Volunteers X-BeenThere: netconf@ietf.org X-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, 22 Jun 2010 08:18:35 -0000 WG participants, pls consider to volunteer if you qualify. We (as IETF community) need a much bigger pool than 29 volunteers! Bert and Mehmet -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of NomCom Chair Sent: Tuesday, June 22, 2010 12:49 AM To: IETF Announcement list Subject: Nomcom 2010-2011: Second Call for Volunteers Hi all, This is the Second call for Volunteers for the 2010-11 nomcom. We are just about halfway through the volunteer period so if you are considering volunteering please do so very soon. I am pleased to report that we have 29 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. If you volunteered before 08:00 PDT (15:00 UTC) on June 21 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! However, we need many more volunteers. You have until 17:00 PDT (24:00 UTC) on July 8, 2010 to volunteer for nomcom but it is much better if you volunteer as early as possible. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF pouplation. As a reminder, volunteers must have attended 3 of the past 5 IETF meetings - per RFC 3777, which means 3 of the following meetings: IETF-73, IETF-74, IETF-75, IETF-76 and IETF-77. If you qualify, and are willing to forgo appointment to any of the positions for which the nominating committee is responsible, please volunteer. The 10 nominating committee members are selected randomly from a pool of volunteers. The details of the operation of nomcom may be found in RFC 3777. The process on how to volunteer for nomcom is in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ The lists of open positions and people whose terms end in March 2011 and thus the positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ The 29 volunteers who have thus far been qualified by the secretariat are: Fred Baker, Cisco Systems Stephan Wenger, Vidyo, Inc. Marc Blanchet, Viagenie Lixia Zhang, UCLA John Drake, Juniper Networks Ole Troan, Cisco Jiankang Yao, CNNIC Wassim Haddad, Ericsson Yi Zhao, Huawei USA Teemu Savolainen, Nokia Jouni Korhonen, Nokia Siemens Networks Mehmet Ersue, Nokia Siemens Networks Christian Schmidt, Nokia Siemens Networks Stephen Hanna, Juniper Networks Suresh Krishnan, Ericsson Eric Gray, Ericsson David Sinicrope, Ericsson Jan Melen, Ericsson Richard Barnes, BBN Technologies Hugo Salgado Hernandez, NIC Chile Ning Zong, Huawei Technologies Qin Wu, Huawei Technologies Karen Seo, BBN Technologies Haibin Song, Huawei Technologies Susan Hares, Huawei Technologies Tony Hansen. AT&T Labs Fuqing Huang, Huawei Technologies Co., Ltd. Huub van Helvoort, Huawei Technologies Miya Kohno, Juniper Networks The primary activity for this nomcom will begin just prior to IETF-78 in Maastricht and should be completed in early January 2011. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be weekly conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. While, there is no requirement in RFC 3777 that a participant attend IETF meetings while serving on nomcom, please consider that during the IETF meetings, people that do not attend would be expected to remotely participate during the day in the time zones of the meeting locations - Maastricht at the end of July and Beijing in November. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. Please volunteer by sending an email before: 17:00 PDT (24:00 UTC) July 8, 2010 as follows: To: nomcom-chair@ietf.org Subject: Nomcom 2010-11 Volunteer Please include the following information in the body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 3 days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "Duplicate:" added to the subject line. Thank you and I hope to hear from you, Thomas Walsh Chair, Nomcom 2010-11 Email: nomcom-chair@ietf.org _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From mehmet.ersue@nsn.com Tue Jun 22 11:34:43 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 653463A67D1 for ; Tue, 22 Jun 2010 11:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.405, 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 FWIQvkDci-45 for ; Tue, 22 Jun 2010 11:34:42 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 5FD6D3A67F8 for ; Tue, 22 Jun 2010 11:34: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 o5MIYk2F022185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 22 Jun 2010 20:34:46 +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 o5MIYkFO031986 for ; Tue, 22 Jun 2010 20:34:46 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jun 2010 20:34:09 +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, 22 Jun 2010 20:34:08 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A649EFB2F@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification - draft-ietf-netconf-monitoring-15.txt Thread-Index: AcsR1HbhxEWGn/B+QBa4XTGuLNgnogAZHLNwAAAjbkA= From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 22 Jun 2010 18:34:09.0222 (UTC) FILETIME=[80B8C660:01CB1239] Subject: [Netconf] FW: New Version Notification - draft-ietf-netconf-monitoring-15.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, 22 Jun 2010 18:34:43 -0000 Hi All, this is the new version of the Monitoring draft, which hopefully addresses all DISCUSSes and comments=20 from IESG. Please check the diff file below for the changes=20 between v14 and v15. Cheers, Mehmet -----Original Message----- From: ext Internet-Draft@ietf.org [mailto:Internet-Draft@ietf.org]=20 Sent: Tuesday, June 22, 2010 8:30 AM To: netconf-chairs@tools.ietf.org; draft-ietf-netconf-monitoring@tools.ietf.org; dromasca@avaya.com; adrian.farrel@huawei.com; ietfdbh@comcast.net Subject: New Version Notification - draft-ietf-netconf-monitoring-15.txt New version (-15) has been submitted for draft-ietf-netconf-monitoring-15.txt. http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-15.txt Sub state has been changed to AD Follow up from New Id Needed Diff from previous version: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-monitoring-15 IETF Secretariat. From bertietf@bwijnen.net Wed Jun 23 07:05:16 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71F813A69DB for ; Wed, 23 Jun 2010 07:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.094 X-Spam-Level: ** X-Spam-Status: No, score=2.094 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWiD1vRovlyp for ; Wed, 23 Jun 2010 07:05:15 -0700 (PDT) Received: from relay.versatel.net (relay61.tele2.vuurwerk.nl [62.250.3.61]) by core3.amsl.com (Postfix) with ESMTP id 5966928C107 for ; Wed, 23 Jun 2010 07:05:15 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1ORQZt-0007OH-OC; Wed, 23 Jun 2010 16:05:21 +0200 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Wed, 23 Jun 2010 16:03:39 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18197 Subject: [Netconf] Fw: opinion on moving with-defaults into 4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 14:05:16 -0000 FYI, Balazs expressed an opinion (private) ----- Original Message ----- From: "Balazs Lengyel" To: ; "ext Bert (IETF) Wijnen" ; "Ersue, Mehmet (NSN - DE/Munich)" Cc: "Phil Shafer" ; "David Partain" Sent: Friday, June 11, 2010 10:52 AM Subject: Re: opinion on moving with-defaults into 4741bis Hello, The issue of defaults an the possibility to store them as part of the datastore as normal values is very important for Ericsson. I am in favor of keeping the with-defaults draft separate, as I still hope it will become an RFC faster this way. I will even try to put in some hours, (I will honestly try). regards Balazs > Hi, > > The WG co-chairs are about to decide whether to move > part of the with-defaults draft into 4741bis. > You guys have posted objections in the past. > Not sure if you want to chime in now or not. > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From andyb@iwl.com Wed Jun 23 09:59:52 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54D7B28C147 for ; Wed, 23 Jun 2010 09:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[AWL=-0.730, BAYES_50=0.001, 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 Pca1Px0XSRVr for ; Wed, 23 Jun 2010 09:59:51 -0700 (PDT) Received: from smtp134.dfw.emailsrvr.com (smtp134.dfw.emailsrvr.com [67.192.241.134]) by core3.amsl.com (Postfix) with ESMTP id 92F6228C143 for ; Wed, 23 Jun 2010 09:59:51 -0700 (PDT) Received: from relay23.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay23.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 4E2A21568AA5 for ; Wed, 23 Jun 2010 12:59:59 -0400 (EDT) Received: by relay23.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 2B8761568AAD for ; Wed, 23 Jun 2010 12:59:59 -0400 (EDT) Message-ID: <4C223D9B.2070400@iwl.com> Date: Wed, 23 Jun 2010 10:00:11 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] when is merge really an operation? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 16:59:52 -0000 Hi, An implementor issue has come up that affects NACM and partial-lock. It has to do with the definition of a merge operation wrt/ the unaffected nodes contained within the operation. 1) initial state -- partial-lock(select='/p-container') by session A 2) session A adds an unlocked leaf: /p-container/leaf='42' 42 3) session B changes the new leaf: /p-container/leaf='17' how this is done is important: a) default-operation='merge' b) default-operation='none' ...//other parms 17 Clearly, for case (b), the only operation requested is a merge on the unlocked leaf. The part that is not clear is whether case (a) constitutes a merge operation request on the /p-container node. If so, then it seems the partial-lock 'in-use' error, or a possible NACM 'access-denied' error is possible. If not, then the merge operation on 'leaf' will succeed. Our server implements (b), not (a). The client can still use default-operation='merge' (or even 'replace', or even copy-config!) and only 'real' operation requests are examined. The server has to 'diff' the request node with the target node, and figure out if a real change is pending or not. Unaffected nodes are not disturbed. >From my reading of RFC 5717, it seems like (a) is supposed to cause an error, not be allowed, but it is not clear. Does anybody know? Does NACM need to work the same way as partial-lock or not? thanks, Andy From mbj@tail-f.com Wed Jun 23 10:38:50 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50F573A6ADC for ; Wed, 23 Jun 2010 10:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.039 X-Spam-Level: X-Spam-Status: No, score=-0.039 tagged_above=-999 required=5 tests=[AWL=0.148, 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 C86FFCBI5sC1 for ; Wed, 23 Jun 2010 10:38:49 -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 89DD53A6AC8 for ; Wed, 23 Jun 2010 10:38:49 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id D2779616001; Wed, 23 Jun 2010 19:38:55 +0200 (CEST) Date: Wed, 23 Jun 2010 19:38:54 +0200 (CEST) Message-Id: <20100623.193854.199507741.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4C223D9B.2070400@iwl.com> References: <4C223D9B.2070400@iwl.com> X-Mailer: Mew version 7.0.50 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] when is merge really an operation? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 17:38:50 -0000 Hi, Andy Bierman wrote: > Hi, > > An implementor issue has come up that affects NACM and partial-lock. > It has to do with the definition of a merge operation wrt/ the > unaffected nodes contained within the operation. > > 1) initial state -- partial-lock(select='/p-container') by session A > > > > > > 2) session A adds an unlocked leaf: /p-container/leaf='42' > > > > 42 > > > > 3) session B changes the new leaf: /p-container/leaf='17' This cannot be done. All nodes under /p-container are part of the "protected area" covered by the partial lock, and thus this request will fail with tag 'in-use'. /martin From andyb@iwl.com Wed Jun 23 11:06:33 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F95F28C13C for ; Wed, 23 Jun 2010 11:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_50=0.001, 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 gq+cBLm8lriY for ; Wed, 23 Jun 2010 11:06:32 -0700 (PDT) Received: from smtp194.dfw.emailsrvr.com (smtp194.dfw.emailsrvr.com [67.192.241.194]) by core3.amsl.com (Postfix) with ESMTP id 6F93928C131 for ; Wed, 23 Jun 2010 11:06:32 -0700 (PDT) Received: from relay19.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay19.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 5AD812748562; Wed, 23 Jun 2010 14:06:40 -0400 (EDT) Received: by relay19.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 15D1A2748135; Wed, 23 Jun 2010 14:06:40 -0400 (EDT) Message-ID: <4C224D3C.1000904@iwl.com> Date: Wed, 23 Jun 2010 11:06:52 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Martin Bjorklund References: <4C223D9B.2070400@iwl.com> <20100623.193854.199507741.mbj@tail-f.com> In-Reply-To: <20100623.193854.199507741.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] when is merge really an operation? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 18:06:33 -0000 On 06/23/2010 10:38 AM, Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: > >> Hi, >> >> An implementor issue has come up that affects NACM and partial-lock. >> It has to do with the definition of a merge operation wrt/ the >> unaffected nodes contained within the operation. >> >> 1) initial state -- partial-lock(select='/p-container') by session A >> >> >> >> >> >> 2) session A adds an unlocked leaf: /p-container/leaf='42' >> >> >> >> 42 >> >> >> >> 3) session B changes the new leaf: /p-container/leaf='17' >> > This cannot be done. All nodes under /p-container are part of the > "protected area" covered by the partial lock, and thus this request > will fail with tag 'in-use'. > > >From 5717, sec. 2.4.1 When a NETCONF session holds a lock on a node, no other session or non-NETCONF mechanism of the system can change that node or any node in the hierarchy of nodes beneath it. OK, but... It is not clear that this includes descendant nodes of a locked node that do not exist yet because of para 3. But I prefer your interpretation. I remember from WG discussions that new nodes were not part of the lock, and this was supposed to be a feature. Perhaps I wasn't paying enough attention. The XPath expressions are evaluated only once: at lock time. Thereafter, the scope of the lock is maintained as a set of nodes, i.e., the returned nodeset, and not by the XPath expression. If the configuration data is later altered in a way that would make the original XPath expressions evaluate to a different set of nodes, this does not affect the scope of the partial lock. Again, it is not clear that creation of a descendant node of a node affected by the partial-lock is part of the existing lock or not. Let's say the agent's data model includes a list of interface nodes. If the XPath expression in the partial-lock operation covers all interface nodes at locking, the scope of the lock will be maintained as the list of interface nodes at the time when the lock was granted. If someone later creates a new interface, this new interface will not be included in the locked-nodes list created previously so the new interface will not be locked. This is ambiguous because there is no specific mention of the actual NETCONF operations, or whether sibling nodes are involved, etc. IMO, this key paragraph suggests that new nodes created after the lock expression was evaluated are not part of the lock. IMO, this would make it more clear: Para 3: Add operation: 124 /interfaces/interface[name='eth0'] /interfaces/interface[name='eth1'] Add explanation that new siblings which would have matched the expression. e.g., /interfaces/interface[name='eth2'], are not locked. It is also not clear, even if /p-container is locked in my example, that RFC 5717 handles the case where default-operation='none' for some ancestor nodes of a node containing an operation attribute. It is also not clear whether the server is allowed to normalize the locked-node nodeset in the reply. A server implementation may optimize out the 2nd select since it has no affect. The locked nodes with still be the highest (closest to root) ancestor that is locked. > > /martin > > Andy From mbj@tail-f.com Wed Jun 23 13:03:34 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7013A69C8 for ; Wed, 23 Jun 2010 13:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.32 X-Spam-Level: X-Spam-Status: No, score=0.32 tagged_above=-999 required=5 tests=[AWL=-0.234, 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 lXXL9HSXI77j for ; Wed, 23 Jun 2010 13:03:33 -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 15F403A683F for ; Wed, 23 Jun 2010 13:03:33 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 634FA616001; Wed, 23 Jun 2010 22:03:39 +0200 (CEST) Date: Wed, 23 Jun 2010 22:03:38 +0200 (CEST) Message-Id: <20100623.220338.59804366.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4C224D3C.1000904@iwl.com> References: <4C223D9B.2070400@iwl.com> <20100623.193854.199507741.mbj@tail-f.com> <4C224D3C.1000904@iwl.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] when is merge really an operation? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 20:03:34 -0000 Andy Bierman wrote: > On 06/23/2010 10:38 AM, Martin Bjorklund wrote: > > Hi, > > > > Andy Bierman wrote: > > > >> Hi, > >> > >> An implementor issue has come up that affects NACM and partial-lock. > >> It has to do with the definition of a merge operation wrt/ the > >> unaffected nodes contained within the operation. > >> > >> 1) initial state -- partial-lock(select='/p-container') by session A > >> > >> > >> > >> > >> > >> 2) session A adds an unlocked leaf: /p-container/leaf='42' > >> > >> > >> > >> 42 > >> > >> > >> > >> 3) session B changes the new leaf: /p-container/leaf='17' > >> > > This cannot be done. All nodes under /p-container are part of the > > "protected area" covered by the partial lock, and thus this request > > will fail with tag 'in-use'. > > > > > > From 5717, sec. 2.4.1 > > When a NETCONF session holds a lock on a node, no other session or > non-NETCONF mechanism of the system can change that node or any node > in the hierarchy of nodes beneath it. > > > OK, but... > It is not clear that this includes descendant nodes of a locked > node that do not exist yet because of para 3. But I prefer > your interpretation. I remember from WG discussions > that new nodes were not part of the lock, and this was > supposed to be a feature. Perhaps I wasn't paying enough attention. 5717 differentiates between "the scope" of the lock, and "the protected area". The scope of the lock are the nodes that are selected at lock time. These do not change; that's a feature :) The protected area is all the subtrees rooted at all nodes in the scope of the lock. The nodes in the protected area changes if nodes are created / deleted in these subtrees. Maybe this could be made more clear, but I don't think there is any text that suggests that newly created nodes in the protected area would not still be protected. An implementation can keep track of the nodes in the scope of the lock only; if any request tries to modify a node underneath one of those nodes, the request is rejected. > It is also not clear, even if /p-container is locked in my example, > that RFC 5717 handles the case where default-operation='none' > for some ancestor nodes of a node containing an operation attribute. Can you elaborate? > It is also not clear whether the server is allowed to normalize the > locked-node nodeset in the reply. > > > > > > > > > A server implementation may optimize out the 2nd select > since it has no affect. The locked nodes with still be > the highest (closest to root) ancestor that is locked. A server is of course allowed to make any optimizations -- as long as they are opimizations that don't affect the end result. I don't think this has to be spelled out... /martin From j.schoenwaelder@jacobs-university.de Wed Jun 23 23:53:31 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B7F13A6A42 for ; Wed, 23 Jun 2010 23:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_50=0.001, 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 akMcqARCHScD for ; Wed, 23 Jun 2010 23:53:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 01A003A6846 for ; Wed, 23 Jun 2010 23:53:30 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D965C001A; Thu, 24 Jun 2010 08:53:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eErHgTgA9SMz; Thu, 24 Jun 2010 08:53:36 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8122BC001E; Thu, 24 Jun 2010 08:53:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4BCCD1358FA7; Thu, 24 Jun 2010 08:53:36 +0200 (CEST) Date: Thu, 24 Jun 2010 08:53:36 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20100624065336.GA50350@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , Netconf References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Netconf Subject: Re: [Netconf] Fw: opinion on moving with-defaults into 4741bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 06:53:31 -0000 On Wed, Jun 23, 2010 at 04:03:39PM +0200, Bert Wijnen (IETF) wrote: > I am in favor of keeping the with-defaults draft separate, as I still > hope it will become an RFC faster this way. Since the YANG module depends on 4741bis this is wishful thinking. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andyb@iwl.com Thu Jun 24 22:20:14 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8846F3A659B for ; Thu, 24 Jun 2010 22:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.331 X-Spam-Level: X-Spam-Status: No, score=-0.331 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_50=0.001, 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 KbIHLgX+VMlr for ; Thu, 24 Jun 2010 22:20:06 -0700 (PDT) Received: from smtp154.dfw.emailsrvr.com (smtp154.dfw.emailsrvr.com [67.192.241.154]) by core3.amsl.com (Postfix) with ESMTP id 59C943A6804 for ; Thu, 24 Jun 2010 22:20:02 -0700 (PDT) Received: from relay5.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay5.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id BF0A83F1B40; Fri, 25 Jun 2010 01:20:09 -0400 (EDT) Received: by relay5.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 8FF273F0C29; Fri, 25 Jun 2010 01:20:09 -0400 (EDT) Message-ID: <4C243C9B.4070107@iwl.com> Date: Thu, 24 Jun 2010 22:20:27 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Martin Bjorklund Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: [Netconf] ietf-netconf-partial-lock.yang X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 05:20:14 -0000 Hi, I am puzzled by some of the YANG usage in this module. For the 'lock-id', why on Earth is returning it in the rpc-reply not mandatory, and in the partial-unlock, the rpc partial-lock { description "A NETCONF operation that locks parts of the running datastore."; input { leaf-list select { type string; *** ^^^^^^ *** I needed to change this to yang:xpath1.0 to get the XML prefixes *** automatically in the stack. Should we make an errata request *** to change string to xpath1.0? min-elements 1; description "XPath expression that specifies the scope of the lock. An Instance Identifier expression MUST be used unless the :xpath capability is supported, in which case any XPath 1.0 expression is allowed."; } } output { leaf lock-id { type lock-id-type; description "Identifies the lock, if granted. The lock-id SHOULD be used in the partial-unlock rpc."; *** I cannot find any text that suggests returning the lock-id is optional *** I do not understand SHOULD instead of MUST } leaf-list locked-node { type instance-identifier; min-elements 1; description "List of locked nodes in the running datastore"; } } } rpc partial-unlock { description "A NETCONF operation that releases a previously acquired partial-lock."; input { leaf lock-id { type lock-id-type; description "Identifies the lock to be released. MUST be the value received in the response to a partial-lock operation."; *** why isn't mandatory=true here? *** what lock is released if no parameter is provided? } } } } Andy From andyb@iwl.com Fri Jun 25 12:28:17 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1DE13A6857 for ; Fri, 25 Jun 2010 12:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[AWL=0.687, 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 7g5x9Q+WUADk for ; Fri, 25 Jun 2010 12:28:16 -0700 (PDT) Received: from smtp194.dfw.emailsrvr.com (smtp194.dfw.emailsrvr.com [67.192.241.194]) by core3.amsl.com (Postfix) with ESMTP id EE2573A6861 for ; Fri, 25 Jun 2010 12:28:15 -0700 (PDT) Received: from relay19.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay19.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id A14AC274868E for ; Fri, 25 Jun 2010 15:28:24 -0400 (EDT) Received: by relay19.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 83D8E2748322 for ; Fri, 25 Jun 2010 15:28:24 -0400 (EDT) Message-ID: <4C250371.50302@iwl.com> Date: Fri, 25 Jun 2010 12:28:49 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] bug in ietf-netconf-monitoring.yang X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 19:28:17 -0000 Hi, Please use the correct data type from ietf-yang-types, since that module is already imported anyway: /netconf-state/datastores/datastore/locks/lock-type/partial-locks/partial-locks/select leaf-list select { type string; ^^^^^^ min-elements 1; description "The xpath expression which was used to request the lock. The select expression indicates the original intended scope of the lock."; } s/string/yang:xpath1.0/ Tools need to be aware of QNames in the content. Andy From bertietf@bwijnen.net Sat Jun 26 02:46:26 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086F03A68A4 for ; Sat, 26 Jun 2010 02:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.854 X-Spam-Level: *** X-Spam-Status: No, score=3.854 tagged_above=-999 required=5 tests=[AWL=-1.802, BAYES_99=3.5, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2E1FCCIIBw-8 for ; Sat, 26 Jun 2010 02:46:24 -0700 (PDT) Received: from relay.versatel.net (relay61.tele2.vuurwerk.nl [62.250.3.61]) by core3.amsl.com (Postfix) with ESMTP id 96DBC3A680E for ; Sat, 26 Jun 2010 02:46:21 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1OSRxz-0005WT-VB for netconf@ietf.org; Sat, 26 Jun 2010 11:46:28 +0200 Message-ID: <9B9C58ADF3B141F4902099EB8606AFC6@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Sat, 26 Jun 2010 11:46:04 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18197 Subject: [Netconf] Consensus call on goAhead on with-defaults X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 09:46:26 -0000 Action please before July 1st if at all possible. WG participants, it seems that we (chairs) cannot conclude to have (even rough) consensus on merging some pieces of the with-defaults into 4741bis. Our tally (difficult to determine through the mailstorms and repetition of arguments) is: To move ahead with current with-defaults draft revision 09 and move nothing to 4741bis (specifically the announcement of basic-mode is something that some people want to move to 4741bis). A: 3 strong opinions in favor of keeping with-defaults as is: Andy, Phil, Balazs B: 3 strong opinions to move basic-mode announcement to 4741bis: Juergen, Lada, Tom C: 1 neutral (is OK to leave with-defaults, but does not object to move it to 4741bis): Martin Please express your opinion (A, B, or C) before the end of this week, so we (wg chairs) can try to read WG consensus. Please do NOT repeat all your arguments as to why you choose which option. We have already seen those arguments. Bert and Mehmet From randy_presuhn@mindspring.com Sat Jun 26 10:30:30 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A3133A695B for ; Sat, 26 Jun 2010 10:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.13 X-Spam-Level: X-Spam-Status: No, score=0.13 tagged_above=-999 required=5 tests=[AWL=0.870, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iF6s-EUnQCBA for ; Sat, 26 Jun 2010 10:30:29 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 60E913A695A for ; Sat, 26 Jun 2010 10:30:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=dTTBnkbCK9/xv5IrzpXwU4EmRKm14aajeVG8163DjCgQd6/xH5bt6OFBXS+T2GKT; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.49.203] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OSZCn-0007oV-G7 for netconf@ietf.org; Sat, 26 Jun 2010 13:30:13 -0400 Message-ID: <001501cb1555$7cab5dc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Netconf" References: <9B9C58ADF3B141F4902099EB8606AFC6@BertLaptop> Date: Sat, 26 Jun 2010 10:32:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc720532780355d09e09faf2b67e1a98aebe330c059c6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.49.203 Subject: Re: [Netconf] Consensus call on goAhead on with-defaults X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 17:30:31 -0000 Hi - > From: "Bert Wijnen (IETF)" > To: "Netconf" > Sent: Saturday, June 26, 2010 2:46 AM > Subject: [Netconf] Consensus call on goAhead on with-defaults ... > Please express your opinion (A, B, or C) before the end of this week, > so we (wg chairs) can try to read WG consensus. B. Randy From dromasca@avaya.com Sun Jun 27 03:12:27 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1883A68BB for ; Sun, 27 Jun 2010 03:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.712, 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 dPYFgqLBcxvv for ; Sun, 27 Jun 2010 03:12:25 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 8DD773A68A0 for ; Sun, 27 Jun 2010 03:12:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,491,1272859200"; d="scan'208";a="225122135" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 Jun 2010 06:12:34 -0400 X-IronPort-AV: E=Sophos;i="4.53,491,1272859200"; d="scan'208";a="476333367" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 27 Jun 2010 06:12:34 -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: Sun, 27 Jun 2010 12:12:12 +0200 Message-ID: In-Reply-To: <4C250371.50302@iwl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] bug in ietf-netconf-monitoring.yang Thread-Index: AcsUnJfZOir0xaiHSZievtZThZ54yQBRGNcQ References: <4C250371.50302@iwl.com> From: "Romascanu, Dan (Dan)" To: , "NETCONF" Subject: Re: [Netconf] bug in ietf-netconf-monitoring.yang X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 10:12:27 -0000 Should this edit be included in the RFC Editor notes?=20 Were all the other current RFC Editor notes made redundant by the new version and can they be deleted?=20 (Questions for the editors and document shepherd) Dan =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Friday, June 25, 2010 10:29 PM > To: NETCONF > Subject: [Netconf] bug in ietf-netconf-monitoring.yang >=20 > Hi, >=20 > Please use the correct data type from ietf-yang-types, since=20 > that module is already imported anyway: >=20 > /netconf-state/datastores/datastore/locks/lock-type/partial-lo > cks/partial-locks/select >=20 > leaf-list select { > type string; > ^^^^^^ > min-elements 1; > description > "The xpath expression which was used to request > the lock. The select expression indicates the > original intended scope of the lock."; > } >=20 >=20 > s/string/yang:xpath1.0/ >=20 > Tools need to be aware of QNames in the content. >=20 >=20 >=20 > Andy >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From dromasca@avaya.com Sun Jun 27 03:15:14 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A00053A680E for ; Sun, 27 Jun 2010 03:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.699, 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 tAwqdDUIWQ1A for ; Sun, 27 Jun 2010 03:15:13 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id D8BAE3A6853 for ; Sun, 27 Jun 2010 03:15:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,491,1272859200"; d="scan'208";a="225122439" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 Jun 2010 06:15:22 -0400 X-IronPort-AV: E=Sophos;i="4.53,491,1272859200"; d="scan'208";a="486760289" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Jun 2010 06:15:21 -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: Sun, 27 Jun 2010 12:15:13 +0200 Message-ID: In-Reply-To: <4C243C9B.4070107@iwl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] ietf-netconf-partial-lock.yang Thread-Index: AcsUJiLv8KQ6B6PuSD2wBtk7OUQ3kABu1OwQ References: <4C243C9B.4070107@iwl.com> From: "Romascanu, Dan (Dan)" To: , "Martin Bjorklund" Cc: NETCONF Subject: Re: [Netconf] ietf-netconf-partial-lock.yang X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 10:15:14 -0000 This document was published as RFC 5717. Dan =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Friday, June 25, 2010 8:20 AM > To: Martin Bjorklund > Cc: NETCONF > Subject: [Netconf] ietf-netconf-partial-lock.yang >=20 > Hi, >=20 > I am puzzled by some of the YANG usage in this module. > For the 'lock-id', why on Earth is returning it in the=20 > rpc-reply not mandatory, and in the partial-unlock, the >=20 >=20 > rpc partial-lock { > description > "A NETCONF operation that locks parts of the running datastore."; > input { > leaf-list select { > type string; > *** ^^^^^^ =20 > *** I needed to change this to yang:xpath1.0 to get the XML prefixes > *** automatically in the stack. Should we make an errata request > *** to change string to xpath1.0? >=20 > min-elements 1; > description > "XPath expression that specifies the scope of the lock. > An Instance Identifier expression MUST be used unless the > :xpath capability is supported, in which case any XPath 1.0 > expression is allowed."; > } > } > output { > leaf lock-id { > type lock-id-type; > description > "Identifies the lock, if granted. The lock-id SHOULD be > used in the partial-unlock rpc."; >=20 > *** I cannot find any text that suggests returning the=20 > lock-id is optional > *** I do not understand SHOULD instead of MUST >=20 > } > leaf-list locked-node { > type instance-identifier; > min-elements 1; > description > "List of locked nodes in the running datastore"; > } > } > } >=20 > rpc partial-unlock { > description > "A NETCONF operation that releases a previously acquired > partial-lock."; > input { > leaf lock-id { > type lock-id-type; > description > "Identifies the lock to be released. MUST be the value > received in the response to a partial-lock operation."; >=20 > *** why isn't mandatory=3Dtrue here? > *** what lock is released if no parameter is provided? >=20 > } > } > } > } >=20 >=20 > Andy >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From mehmet.ersue@nsn.com Sun Jun 27 06:00:09 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E67B93A67D4 for ; Sun, 27 Jun 2010 06:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=0.293, 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 tQ4aKdPKAc7L for ; Sun, 27 Jun 2010 06:00:09 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id C66223A63D3 for ; Sun, 27 Jun 2010 06:00:07 -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 o5RD0Bb2028342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 27 Jun 2010 15:00:11 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5RD0Ah4023648; Sun, 27 Jun 2010 15:00:10 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 27 Jun 2010 15:00:09 +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: Sun, 27 Jun 2010 15:00:09 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A649F068B@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] bug in ietf-netconf-monitoring.yang Thread-Index: AcsUnJfZOir0xaiHSZievtZThZ54yQBRGNcQAAWqKsA= References: <4C250371.50302@iwl.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Romascanu, Dan (Dan)" , , "NETCONF" X-OriginalArrivalTime: 27 Jun 2010 13:00:09.0899 (UTC) FILETIME=[AC6B7FB0:01CB15F8] Subject: Re: [Netconf] bug in ietf-netconf-monitoring.yang X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 13:00:10 -0000 I think we should include this into the RFC=20 editors notes with OLD/NEW text but don't=20 want to talk for the authors. Current RFC editors notes can be deleted as=20 they have been incorporated into the v15 draft. 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: Sunday, June 27, 2010 12:12 PM > To: andyb@iwl.com; NETCONF > Subject: Re: [Netconf] bug in ietf-netconf-monitoring.yang >=20 > Should this edit be included in the RFC Editor notes?=20 >=20 > Were all the other current RFC Editor notes made redundant by the new > version and can they be deleted?=20 >=20 > (Questions for the editors and document shepherd) >=20 > Dan > =20 >=20 > > -----Original Message----- > > From: netconf-bounces@ietf.org=20 > > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > > Sent: Friday, June 25, 2010 10:29 PM > > To: NETCONF > > Subject: [Netconf] bug in ietf-netconf-monitoring.yang > >=20 > > Hi, > >=20 > > Please use the correct data type from ietf-yang-types, since=20 > > that module is already imported anyway: > >=20 > > /netconf-state/datastores/datastore/locks/lock-type/partial-lo > > cks/partial-locks/select > >=20 > > leaf-list select { > > type string; > > ^^^^^^ > > min-elements 1; > > description > > "The xpath expression which was used to request > > the lock. The select expression indicates the > > original intended scope of the lock."; > > } > >=20 > >=20 > > s/string/yang:xpath1.0/ > >=20 > > Tools need to be aware of QNames in the content. > >=20 > >=20 > >=20 > > Andy > >=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 andyb@iwl.com Sun Jun 27 07:54:58 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88CC43A687B for ; Sun, 27 Jun 2010 07:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.737 X-Spam-Level: X-Spam-Status: No, score=-2.737 tagged_above=-999 required=5 tests=[AWL=0.862, 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 4OOjkTCK12il for ; Sun, 27 Jun 2010 07:54:57 -0700 (PDT) Received: from smtp114.iad.emailsrvr.com (smtp114.iad.emailsrvr.com [207.97.245.114]) by core3.amsl.com (Postfix) with ESMTP id 6D28B3A67D7 for ; Sun, 27 Jun 2010 07:54:57 -0700 (PDT) Received: from relay1.r1.iad.emailsrvr.com (localhost [127.0.0.1]) by relay1.r1.iad.emailsrvr.com (SMTP Server) with ESMTP id C54A644C03F; Sun, 27 Jun 2010 10:55:06 -0400 (EDT) Received: by relay1.r1.iad.emailsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 66C4A44C006; Sun, 27 Jun 2010 10:55:06 -0400 (EDT) Message-ID: <4C27667B.8080109@iwl.com> Date: Sun, 27 Jun 2010 07:55:55 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4C243C9B.4070107@iwl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] ietf-netconf-partial-lock.yang X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 14:54:58 -0000 On 06/27/2010 03:15 AM, Romascanu, Dan (Dan) wrote: > This document was published as RFC 5717. > > I know that. It is full of bugs, most of which I ignored because it is an RFC already. Since it is an RFC the WG should have no problem fully understanding it and explaining what lock is released when there is no lock-id given. One part says SHOULD provide a lock-id and another says the lock-id MUST be correct. If that isn't a bug then how is it interoperable? > Dan > Andy > > > >> -----Original Message----- >> From: netconf-bounces@ietf.org >> [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman >> Sent: Friday, June 25, 2010 8:20 AM >> To: Martin Bjorklund >> Cc: NETCONF >> Subject: [Netconf] ietf-netconf-partial-lock.yang >> >> Hi, >> >> I am puzzled by some of the YANG usage in this module. >> For the 'lock-id', why on Earth is returning it in the >> rpc-reply not mandatory, and in the partial-unlock, the >> >> >> rpc partial-lock { >> description >> "A NETCONF operation that locks parts of the running datastore."; >> input { >> leaf-list select { >> type string; >> *** ^^^^^^ >> *** I needed to change this to yang:xpath1.0 to get the XML prefixes >> *** automatically in the stack. Should we make an errata request >> *** to change string to xpath1.0? >> >> min-elements 1; >> description >> "XPath expression that specifies the scope of the lock. >> An Instance Identifier expression MUST be used unless the >> :xpath capability is supported, in which case any XPath 1.0 >> expression is allowed."; >> } >> } >> output { >> leaf lock-id { >> type lock-id-type; >> description >> "Identifies the lock, if granted. The lock-id SHOULD be >> used in the partial-unlock rpc."; >> >> *** I cannot find any text that suggests returning the >> lock-id is optional >> *** I do not understand SHOULD instead of MUST >> >> } >> leaf-list locked-node { >> type instance-identifier; >> min-elements 1; >> description >> "List of locked nodes in the running datastore"; >> } >> } >> } >> >> rpc partial-unlock { >> description >> "A NETCONF operation that releases a previously acquired >> partial-lock."; >> input { >> leaf lock-id { >> type lock-id-type; >> description >> "Identifies the lock to be released. MUST be the value >> received in the response to a partial-lock operation."; >> >> *** why isn't mandatory=true here? >> *** what lock is released if no parameter is provided? >> >> } >> } >> } >> } >> >> >> Andy >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > From dromasca@avaya.com Sun Jun 27 09:31:07 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 181EC3A6784 for ; Sun, 27 Jun 2010 09:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.676, 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 Fyx0woBfkATA for ; Sun, 27 Jun 2010 09:31:03 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id D45533A67B4 for ; Sun, 27 Jun 2010 09:30:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,492,1272859200"; d="scan'208";a="225148120" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 Jun 2010 12:31:01 -0400 X-IronPort-AV: E=Sophos;i="4.53,492,1272859200"; d="scan'208";a="476362983" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 27 Jun 2010 12:31:00 -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: Sun, 27 Jun 2010 18:30:38 +0200 Message-ID: In-Reply-To: <4C27667B.8080109@iwl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] ietf-netconf-partial-lock.yang Thread-Index: AcsWCL0c3RKDxLkPSj2hQoUo30uOYQACKBVA References: <4C243C9B.4070107@iwl.com> <4C27667B.8080109@iwl.com> From: "Romascanu, Dan (Dan)" To: Cc: NETCONF Subject: Re: [Netconf] ietf-netconf-partial-lock.yang X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 16:31:08 -0000 Hi Andy, See in-line.=20 Dan > -----Original Message----- > From: Andy Bierman [mailto:andyb@iwl.com]=20 > Sent: Sunday, June 27, 2010 5:56 PM > To: Romascanu, Dan (Dan) > Cc: Martin Bjorklund; NETCONF > Subject: Re: [Netconf] ietf-netconf-partial-lock.yang >=20 > On 06/27/2010 03:15 AM, Romascanu, Dan (Dan) wrote: > > This document was published as RFC 5717. > > > > =20 >=20 > I know that. > It is full of bugs, most of which I ignored because it is an=20 > RFC already. Since it is an RFC the WG should have no=20 > problem fully understanding it and explaining what lock is=20 > released when there is no lock-id given. It would have been better if problems (if agreed to be such) were discovered before publication. This requires careful review from all WG participants at all phases.=20 Now we are where we are and we should decide if a. it's a problem b. it it's a problem how should we deal with it (errata, RFC revision, other?) >=20 > One part says SHOULD provide a lock-id and another > says the lock-id MUST be correct. If that isn't a bug > then how is it interoperable? My reading is that of the lock-id is provided in the response to the partial-lock operation, then this MUST be the value to be included in a partial-unlock. Why this is a SHOULD in the partial-lock response and what to do if a lock-id is not available - open questions to the editors I guess.=20 >=20 > > Dan > > =20 >=20 > Andy >=20 > > =20 > > > > =20 > >> -----Original Message----- > >> From: netconf-bounces@ietf.org > >> [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > >> Sent: Friday, June 25, 2010 8:20 AM > >> To: Martin Bjorklund > >> Cc: NETCONF > >> Subject: [Netconf] ietf-netconf-partial-lock.yang > >> > >> Hi, > >> > >> I am puzzled by some of the YANG usage in this module. > >> For the 'lock-id', why on Earth is returning it in the=20 > rpc-reply not=20 > >> mandatory, and in the partial-unlock, the > >> > >> > >> rpc partial-lock { > >> description > >> "A NETCONF operation that locks parts of the running=20 > datastore."; > >> input { > >> leaf-list select { > >> type string; > >> *** ^^^^^^ =20 > >> *** I needed to change this to yang:xpath1.0 to get the=20 > XML prefixes > >> *** automatically in the stack. Should we make an errata request > >> *** to change string to xpath1.0? > >> > >> min-elements 1; > >> description > >> "XPath expression that specifies the scope of the lock. > >> An Instance Identifier expression MUST be used unless the > >> :xpath capability is supported, in which case=20 > any XPath 1.0 > >> expression is allowed."; > >> } > >> } > >> output { > >> leaf lock-id { > >> type lock-id-type; > >> description > >> "Identifies the lock, if granted. The lock-id SHOULD be > >> used in the partial-unlock rpc."; > >> > >> *** I cannot find any text that suggests returning the lock-id is=20 > >> optional > >> *** I do not understand SHOULD instead of MUST > >> > >> } > >> leaf-list locked-node { > >> type instance-identifier; > >> min-elements 1; > >> description > >> "List of locked nodes in the running datastore"; > >> } > >> } > >> } > >> > >> rpc partial-unlock { > >> description > >> "A NETCONF operation that releases a previously acquired > >> partial-lock."; > >> input { > >> leaf lock-id { > >> type lock-id-type; > >> description > >> "Identifies the lock to be released. MUST be the value > >> received in the response to a partial-lock operation."; > >> > >> *** why isn't mandatory=3Dtrue here? > >> *** what lock is released if no parameter is provided? > >> > >> } > >> } > >> } > >> } > >> > >> > >> Andy > >> > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > >> > >> =20 > > =20 >=20 >=20 From andyb@iwl.com Sun Jun 27 09:53:15 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A76683A691D for ; Sun, 27 Jun 2010 09:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=0.661, 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 qIREWh+ilVJX for ; Sun, 27 Jun 2010 09:53:14 -0700 (PDT) Received: from smtp144.dfw.emailsrvr.com (smtp144.dfw.emailsrvr.com [67.192.241.144]) by core3.amsl.com (Postfix) with ESMTP id DA0F73A691E for ; Sun, 27 Jun 2010 09:53:14 -0700 (PDT) Received: from relay14.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay14.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 45F7690859B; Sun, 27 Jun 2010 12:53:24 -0400 (EDT) Received: by relay14.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 07968908414; Sun, 27 Jun 2010 12:53:23 -0400 (EDT) Message-ID: <4C278236.4090308@iwl.com> Date: Sun, 27 Jun 2010 09:54:14 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4C243C9B.4070107@iwl.com> <4C27667B.8080109@iwl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] ietf-netconf-partial-lock.yang X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 16:53:15 -0000 On 06/27/2010 09:30 AM, Romascanu, Dan (Dan) wrote: > Hi Andy, > > See in-line. > > Dan > > > >> -----Original Message----- >> From: Andy Bierman [mailto:andyb@iwl.com] >> Sent: Sunday, June 27, 2010 5:56 PM >> To: Romascanu, Dan (Dan) >> Cc: Martin Bjorklund; NETCONF >> Subject: Re: [Netconf] ietf-netconf-partial-lock.yang >> >> On 06/27/2010 03:15 AM, Romascanu, Dan (Dan) wrote: >> >>> This document was published as RFC 5717. >>> >>> >>> >> I know that. >> It is full of bugs, most of which I ignored because it is an >> RFC already. Since it is an RFC the WG should have no >> problem fully understanding it and explaining what lock is >> released when there is no lock-id given. >> > It would have been better if problems (if agreed to be such) were > discovered before publication. This requires careful review from all WG > participants at all phases. > > Now we are where we are and we should decide if a. it's a problem b. it > it's a problem how should we deal with it (errata, RFC revision, other?) > > >> One part says SHOULD provide a lock-id and another >> says the lock-id MUST be correct. If that isn't a bug >> then how is it interoperable? >> > My reading is that of the lock-id is provided in the response to the > partial-lock operation, then this MUST be the value to be included in a > partial-unlock. Why this is a SHOULD in the partial-lock response and > what to do if a lock-id is not available - open questions to the editors > I guess. > > The current YANG text says that the lock-id is optional to implement by the server. It does not have to be returned in the reply. IMO, this is a horrible for a standard. It also breaks the monitoring module because the list is keyed by the lock-id, so it is mandatory from the monitoring POV. The server MUST make sure the same session is issuing the partial-lock that is calling partial-lock. If the client only has 1 partial-lock, then the lock-id is redundant. IMO, this sort of optimization to save a'uint32' leaf is beyond clueless. It increases client complexity greatly because no developer is going to design code for a max of 1 partial lock. What if the client wants more than 1 partial-lock from a server that doesn't implement lock-id? Does the server hand out multiple locks without any way to distinguish them for partial-unlock? How broken is that? If not, then the server is non-compliant because it MUST support multiple concurrent locks. How does the client know if the server implements client-id without trying to lock something? (It doesn't) > >> >>> Dan >>> >>> >> Andy >> >> Andy From mbj@tail-f.com Mon Jun 28 01:13:46 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C72B03A69A1 for ; Mon, 28 Jun 2010 01:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.05 X-Spam-Level: X-Spam-Status: No, score=0.05 tagged_above=-999 required=5 tests=[AWL=-0.318, 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 vqsMHJbXIZf4 for ; Mon, 28 Jun 2010 01:13:46 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E56A63A699D for ; Mon, 28 Jun 2010 01:13:45 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A2DC7616001; Mon, 28 Jun 2010 10:13:54 +0200 (CEST) Date: Mon, 28 Jun 2010 07:57:44 +0200 (CEST) Message-Id: <20100628.075744.266020143.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4C243C9B.4070107@iwl.com> References: <4C243C9B.4070107@iwl.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] ietf-netconf-partial-lock.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: Mon, 28 Jun 2010 08:13:46 -0000 Andy Bierman wrote: > Hi, > > I am puzzled by some of the YANG usage in this module. > For the 'lock-id', why on Earth is returning it in > the rpc-reply not mandatory, and in the partial-unlock, > the > > > rpc partial-lock { > description > "A NETCONF operation that locks parts of the running datastore."; > input { > leaf-list select { > type string; > *** ^^^^^^ > *** I needed to change this to yang:xpath1.0 to get the XML prefixes > *** automatically in the stack. Should we make an errata request > *** to change string to xpath1.0? I agree that the correct type is 'xpath1.0'. > output { > leaf lock-id { > type lock-id-type; > description > "Identifies the lock, if granted. The lock-id SHOULD be > used in the partial-unlock rpc."; > > *** I cannot find any text that suggests returning the lock-id is optional Correct; it is not optional. This leaf should have a "mandatory true;" statement. This would be it consistent with the text and XSD. > *** I do not understand SHOULD instead of MUST I don't think either SHOULD or MUST is actually correct. The client can close the connection without doing partial-unlock, so MUST is not right either. > rpc partial-unlock { > description > "A NETCONF operation that releases a previously acquired > partial-lock."; > input { > leaf lock-id { > type lock-id-type; > description > "Identifies the lock to be released. MUST be the value > received in the response to a partial-lock operation."; > > *** why isn't mandatory=true here? > *** what lock is released if no parameter is provided? It should have mandatory true. This would make it consistent with the text and XSD. /martin From mbj@tail-f.com Mon Jun 28 02:05:29 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 785463A69A8 for ; Mon, 28 Jun 2010 02:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.112 X-Spam-Level: X-Spam-Status: No, score=-1.112 tagged_above=-999 required=5 tests=[AWL=0.934, 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 LsLcXugAht4l for ; Mon, 28 Jun 2010 02:05:28 -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 B070E3A6818 for ; Mon, 28 Jun 2010 02:05:28 -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 3F3C5616001; Mon, 28 Jun 2010 11:05:38 +0200 (CEST) Date: Mon, 28 Jun 2010 11:05:37 +0200 (CEST) Message-Id: <20100628.110537.108627842.mbj@tail-f.com> To: mehmet.ersue@nsn.com From: Martin Bjorklund In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A649F068B@DEMUEXC006.nsn-intra.net> References: <4C250371.50302@iwl.com> <80A0822C5E9A4440A5117C2F4CD36A649F068B@DEMUEXC006.nsn-intra.net> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] bug in ietf-netconf-monitoring.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: Mon, 28 Jun 2010 09:05:29 -0000 Hi, "Ersue, Mehmet (NSN - DE/Munich)" wrote: > > I think we should include this into the RFC > editors notes with OLD/NEW text but don't > want to talk for the authors. I agree that we should make this change: OLD: leaf-list select { type string; min-elements 1; NEW: leaf-list select { type yang:xpath1.0; min-elements 1; > Current RFC editors notes can be deleted as > they have been incorporated into the v15 draft. Yes. /martin From bertietf@bwijnen.net Mon Jun 28 03:23:23 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28F83A68D5 for ; Mon, 28 Jun 2010 03:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.794 X-Spam-Level: X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[AWL=0.805, 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 c7cT5pqA0xIC for ; Mon, 28 Jun 2010 03:23:22 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 0133B3A6905 for ; Mon, 28 Jun 2010 03:23:20 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OTBUm-00076J-21; Mon, 28 Jun 2010 12:23:26 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-46.ripe.net) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OTBUl-0003TJ-V0; Mon, 28 Jun 2010 12:23:19 +0200 Message-ID: <4C287817.5070306@bwijnen.net> Date: Mon, 28 Jun 2010 12:23:19 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Martin Bjorklund References: <4C243C9B.4070107@iwl.com> <20100628.075744.266020143.mbj@tail-f.com> In-Reply-To: <20100628.075744.266020143.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd47b85d3ed8c6629c40eef33036a3c2e0e X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd47b85d3ed8c6629c40eef33036a3c2e0e Cc: netconf@ietf.org Subject: Re: [Netconf] ietf-netconf-partial-lock.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: Mon, 28 Jun 2010 10:23:23 -0000 I suggest that we create proposed text for reporting these errata We then let the WG read/think-about/check it, and once we agree we report it as an errata and keep it on the shelf for whever we do a revision. Bert Martin Bjorklund wrote: > Andy Bierman wrote: > >> Hi, >> >> I am puzzled by some of the YANG usage in this module. >> For the 'lock-id', why on Earth is returning it in >> the rpc-reply not mandatory, and in the partial-unlock, >> the >> >> >> rpc partial-lock { >> description >> "A NETCONF operation that locks parts of the running datastore."; >> input { >> leaf-list select { >> type string; >> *** ^^^^^^ >> *** I needed to change this to yang:xpath1.0 to get the XML prefixes >> *** automatically in the stack. Should we make an errata request >> *** to change string to xpath1.0? >> > > I agree that the correct type is 'xpath1.0'. > > >> output { >> leaf lock-id { >> type lock-id-type; >> description >> "Identifies the lock, if granted. The lock-id SHOULD be >> used in the partial-unlock rpc."; >> >> *** I cannot find any text that suggests returning the lock-id is optional >> > > Correct; it is not optional. This leaf should have a "mandatory > true;" statement. This would be it consistent with the text and XSD. > > >> *** I do not understand SHOULD instead of MUST >> > > I don't think either SHOULD or MUST is actually correct. The client > can close the connection without doing partial-unlock, so MUST is not > right either. > > >> rpc partial-unlock { >> description >> "A NETCONF operation that releases a previously acquired >> partial-lock."; >> input { >> leaf lock-id { >> type lock-id-type; >> description >> "Identifies the lock to be released. MUST be the value >> received in the response to a partial-lock operation."; >> >> *** why isn't mandatory=true here? >> *** what lock is released if no parameter is provided? >> > > It should have mandatory true. This would make it consistent with the > text and XSD. > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From dromasca@avaya.com Mon Jun 28 03:42:18 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D463A6876 for ; Mon, 28 Jun 2010 03:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.665, 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 MDaoPKvKaXnl for ; Mon, 28 Jun 2010 03:42:14 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 7C9EB3A6905 for ; Mon, 28 Jun 2010 03:42:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,496,1272859200"; d="scan'208";a="22675817" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 28 Jun 2010 06:42:24 -0400 X-IronPort-AV: E=Sophos;i="4.53,496,1272859200"; d="scan'208";a="486912163" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Jun 2010 06:42: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: Mon, 28 Jun 2010 12:42:10 +0200 Message-ID: In-Reply-To: <20100628.110537.108627842.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] bug in ietf-netconf-monitoring.yang Thread-Index: AcsWoRXC8XukZHXjQfiDhSuVkBXTZQADVJvw References: <4C250371.50302@iwl.com><80A0822C5E9A4440A5117C2F4CD36A649F068B@DEMUEXC006.nsn-intra.net> <20100628.110537.108627842.mbj@tail-f.com> From: "Romascanu, Dan (Dan)" To: "Martin Bjorklund" , Cc: netconf@ietf.org Subject: Re: [Netconf] bug in ietf-netconf-monitoring.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: Mon, 28 Jun 2010 10:42:18 -0000 I believe this change is minimal from the IESG point of view, but I would like to make sure that the WG has consensus about it. Mehmet, can you confirm this?=20 Thanks and Regards, Dan =20 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 > Sent: Monday, June 28, 2010 12:06 PM > To: mehmet.ersue@nsn.com > Cc: Romascanu, Dan (Dan); andyb@iwl.com; netconf@ietf.org > Subject: Re: [Netconf] bug in ietf-netconf-monitoring.yang >=20 > Hi, >=20 > "Ersue, Mehmet (NSN - DE/Munich)" wrote: > >=20 > > I think we should include this into the RFC editors notes=20 > with OLD/NEW=20 > > text but don't want to talk for the authors. >=20 > I agree that we should make this change: >=20 > OLD: >=20 > leaf-list select { > type string; > min-elements 1; >=20 > NEW: >=20 > leaf-list select { > type yang:xpath1.0; > min-elements 1; >=20 >=20 > > Current RFC editors notes can be deleted as they have been=20 > > incorporated into the v15 draft. >=20 > Yes. >=20 >=20 > /martin >=20 From bertietf@bwijnen.net Mon Jun 28 04:39:09 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F72B3A6A21 for ; Mon, 28 Jun 2010 04:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.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 EzS8hzByVSzx for ; Mon, 28 Jun 2010 04:39:08 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 8117328B56A for ; Mon, 28 Jun 2010 04:39:05 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.1.103]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OTCg5-00031g-MW; Mon, 28 Jun 2010 13:39:11 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-46.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OTCg5-0007Zl-Hv; Mon, 28 Jun 2010 13:39:05 +0200 Message-ID: <4C2889D9.8060000@bwijnen.net> Date: Mon, 28 Jun 2010 13:39:05 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Margaret Wasserman References: <20100602.152910.125098302.mbj@tail-f.com><7E044AE9-6548-491D-9BD5-26472D6EB596@lilacglade.org><20100610.164404.103755057.mbj@tail-f.com> <26241D4E-D31F-48B2-B7FA-8C7623BFB24D@lilacglade.org> <9A1936F3823F417EB245ED8D40A67F17@BertLaptop> In-Reply-To: <9A1936F3823F417EB245ED8D40A67F17@BertLaptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd44acb7dcb9930c22b47c374adc97298da X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd44acb7dcb9930c22b47c374adc97298da Cc: netconf@ietf.org Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-01.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, 28 Jun 2010 11:39:09 -0000 Margareth, pls go ahead andmake thse changes. Nobody has commented, so I take that as agreement Isince had indicated I would do so unless anyone objected). I think we are then done with this document and we can then submit it to our AD. Thanks, Bert and Mehmet Bert Wijnen wrote: > Speaking as co-chair > > This seems fine to me. > > If anyone disagrees. PLEASE DO SPEAK UP by 15 June at the latest > > Bert > ----- Original Message ----- > From: "Margaret Wasserman" > To: "Martin Bjorklund" > Cc: > Sent: Thursday, June 10, 2010 11:12 PM > Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-01.txt > > > > Hi Martin, > > On Jun 10, 2010, at 10:44 AM, Martin Bjorklund wrote: > >>> Maybe we would be better off removing this paragraph altogether? >>> >> That would be fine with me. >> > > Okay. Unless anyone objects, I will make this change and the other > changes you suggested and resubmit some time next week. > > Thanks! > Margaret > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From mehmet.ersue@nsn.com Mon Jun 28 05:27:55 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50F313A659A for ; Mon, 28 Jun 2010 05:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.274, 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 iLOyNkzyr+yP for ; Mon, 28 Jun 2010 05:27:53 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 38EDA3A68DF for ; Mon, 28 Jun 2010 05:27:52 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o5SCRtGq023263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Jun 2010 14:27:55 +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 o5SCRpRH000411; Mon, 28 Jun 2010 14:27:54 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jun 2010 14:27:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB16BD.5390AD8C" Date: Mon, 28 Jun 2010 14:27:51 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A649F0926@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus of Proposed Change WAS:RE: [Netconf] bug in ietf-netconf-monitoring.yang Thread-Index: AcsWoRXC8XukZHXjQfiDhSuVkBXTZQADVJvwAAJrlEA= References: <4C250371.50302@iwl.com><80A0822C5E9A4440A5117C2F4CD36A649F068B@DEMUEXC006.nsn-intra.net> <20100628.110537.108627842.mbj@tail-f.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 28 Jun 2010 12:27:52.0748 (UTC) FILETIME=[543376C0:01CB16BD] Subject: [Netconf] Consensus of Proposed Change WAS:RE: bug in ietf-netconf-monitoring.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: Mon, 28 Jun 2010 12:27:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB16BD.5390AD8C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, NETCONF Monitoring draft passed the IESG review. Though there is one small issue left. Andy proposed to use "yang:xpath1.0" instead of "string" for the type=20 statement in the definition of "leaf-list select"=20 (see attached mail and OLD/NEW text below).=20 The draft authors and myself (as the document shepherd) support this change. If there are no strong objections by June 30, 2010, EOB=20 we are going to change the text as proposed and will ask=20 Dan to consider to bring the draft to the next step.=20 Many thanks to the authors to bring the Monitoring draft=20 to this stage and all who contributed to the development.=20 Cheers, Mehmet =20 > -----Original Message----- > From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: Monday, June 28, 2010 12:42 PM > To: Martin Bjorklund; Ersue, Mehmet (NSN - DE/Munich) > Cc: andyb@iwl.com; netconf@ietf.org > Subject: RE: [Netconf] bug in ietf-netconf-monitoring.yang >=20 > I believe this change is minimal from the IESG point of view, but I > would like to make sure that the WG has consensus about it.=20 > Mehmet, can > you confirm this?=20 >=20 > Thanks and Regards, >=20 > Dan > =20 >=20 > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 > > Sent: Monday, June 28, 2010 12:06 PM > > To: mehmet.ersue@nsn.com > > Cc: Romascanu, Dan (Dan); andyb@iwl.com; netconf@ietf.org > > Subject: Re: [Netconf] bug in ietf-netconf-monitoring.yang > >=20 > > Hi, > >=20 > > "Ersue, Mehmet (NSN - DE/Munich)" wrote: > > >=20 > > > I think we should include this into the RFC editors notes=20 > > with OLD/NEW=20 > > > text but don't want to talk for the authors. > >=20 > > I agree that we should make this change: > >=20 > > OLD: > >=20 > > leaf-list select { > > type string; > > min-elements 1; > >=20 > > NEW: > >=20 > > leaf-list select { > > type yang:xpath1.0; > > min-elements 1; > >=20 > >=20 > > > Current RFC editors notes can be deleted as they have been=20 > > > incorporated into the v15 draft. > >=20 > > Yes. > >=20 > >=20 > > /martin > >=20 >=20 ------_=_NextPart_001_01CB16BD.5390AD8C Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from demuexc022.nsn-intra.net ([10.150.128.35]) by DEMUEXC006.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jun 2010 21:28:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jun 2010 21:28:33 +0200 Received: from demumfd001.nsn-inter.net (DEMUMFD001 [93.183.12.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5PJSXte006918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Jun 2010 21:28:33 +0200 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o5PJSV6Y028462; Fri, 25 Jun 2010 21:28:32 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07E5C3A67EC; Fri, 25 Jun 2010 12:28:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1DE13A6857 for ; Fri, 25 Jun 2010 12:28:16 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7g5x9Q+WUADk for ; Fri, 25 Jun 2010 12:28:16 -0700 (PDT) Received: from smtp194.dfw.emailsrvr.com (smtp194.dfw.emailsrvr.com [67.192.241.194]) by core3.amsl.com (Postfix) with ESMTP id EE2573A6861 for ; Fri, 25 Jun 2010 12:28:15 -0700 (PDT) Received: from relay19.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay19.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id A14AC274868E for ; Fri, 25 Jun 2010 15:28:24 -0400 (EDT) Received: by relay19.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 83D8E2748322 for ; Fri, 25 Jun 2010 15:28:24 -0400 (EDT) Content-class: urn:content-classes:message Subject: [Netconf] bug in ietf-netconf-monitoring.yang Date: Fri, 25 Jun 2010 21:28:49 +0200 Message-ID: <4C250371.50302@iwl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] bug in ietf-netconf-monitoring.yang Thread-Index: AcsUnJlA+iBNcSb8TLmnGNbdOUGP5Q== List-Help: List-Subscribe: , List-Unsubscribe: , From: "ext Andy Bierman" Sender: To: "NETCONF" Reply-To: Hi, Please use the correct data type from ietf-yang-types, since that module is already imported anyway: /netconf-state/datastores/datastore/locks/lock-type/partial-locks/partial= -locks/select leaf-list select { type string; ^^^^^^ min-elements 1; description "The xpath expression which was used to request the lock. The select expression indicates the original intended scope of the lock."; } s/string/yang:xpath1.0/ Tools need to be aware of QNames in the content. Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------_=_NextPart_001_01CB16BD.5390AD8C-- From bertietf@bwijnen.net Tue Jun 29 23:36:58 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0837D3A6A94 for ; Tue, 29 Jun 2010 23:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.604, 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 fMInNLaa7Cgp for ; Tue, 29 Jun 2010 23:36:56 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id AFF7C3A6C37 for ; Tue, 29 Jun 2010 23:36:52 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.1.103]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OTqun-000596-K5 for netconf@ietf.org; Wed, 30 Jun 2010 08:37:03 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OTqun-0002qm-Au for netconf@ietf.org; Wed, 30 Jun 2010 08:36:57 +0200 Message-ID: <4C2AE609.7030206@bwijnen.net> Date: Wed, 30 Jun 2010 08:36:57 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4fa47549ef339b5a3c0a930cb739fb1d5 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4fa47549ef339b5a3c0a930cb739fb1d5 Subject: [Netconf] [Fwd: FW: Third Call for Nomcom 2010-11 Volunteers] X-BeenThere: netconf@ietf.org X-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, 30 Jun 2010 06:36:58 -0000 Pls volunteer if you are eligable. See below Bert and Mehmet -------- Original Message -------- Subject: FW: Third Call for Nomcom 2010-11 Volunteers Date: Tue, 29 Jun 2010 23:36:26 +0200 From: Romascanu, Dan (Dan) To: Please send this third call for volunteers for NomComm to your WG lists. Participating in NomComm is an important contribution to the future of the IETF. Regards, Dan -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Thomas Walsh Sent: Wednesday, June 30, 2010 12:31 AM To: ietf@ietf.org Subject: FW: Third Call for Nomcom 2010-11 Volunteers Please volunteer if you are eligible. You must have attended 3 of the last 5 IETF meetings to be eligible. -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of NomCom Chair Sent: Monday, June 28, 2010 4:58 PM To: IETF Announcement list Subject: Third Call for Nomcom 2010-11 Volunteers Hi all, This is the Third call for Volunteers for the 2010-2011 Nomcom. We are now 2/3 of the way through the volunteer period so if you are considering volunteering please do so now as the time in which you may volunteer is beginning to run short. The call for volunteers remains open until 17:00 PDT (24:00 UTC) on July 8, 2010. I am pleased to report that we currently have 65 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. I will publish the current list of volunteers in a separate message. If you volunteered before 12:00 PDT (19:00 UTC) on June 28 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! We still need additional volunteers, please! If you have attended at least 3 of the last 5 IETF meetings you are eligible to volunteer. The 10 nominating committee members are selected randomly from a pool of volunteers. The details of the operation of Nomcom may be found in RFC 3777. The process on how to volunteer for Nomcom is in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ The lists of open positions and people whose terms end in March 2011 and thus the positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ Please volunteer by sending an email before: 17:00 PDT (24:00 UTC) July 8, 2010 as follows: To: nomcom-chair@ietf.org Subject: Nomcom 2010-11 Volunteer Please include the following information in the body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form // // For confirmation if selected Please expect an email response from me within 3 days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "Duplicate:" added to the subject line. Thank you and I hope to hear from you, Thomas Walsh Chair, Nomcom 2010-11 Email: nomcom-chair@ietf.org _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From mehmet.ersue@nsn.com Wed Jun 30 01:23:03 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E11CE3A67F9 for ; Wed, 30 Jun 2010 01:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wx3SF7mqRLAY for ; Wed, 30 Jun 2010 01:23:02 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 7F66D3A67F7 for ; Wed, 30 Jun 2010 01:23:02 -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 o5U8NB6m022328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Jun 2010 10:23:11 +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 o5U8NBfp011672; Wed, 30 Jun 2010 10:23:11 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Jun 2010 10:23:10 +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, 30 Jun 2010 10:23:08 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64A24549@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Third Call for Nomcom 2010-11 Volunteers Thread-Index: AcsXHcG7a5l3hm+ZTgOYixTdF1cuiQAtEjJAAAA4UeAAFpLdUA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 30 Jun 2010 08:23:10.0894 (UTC) FILETIME=[79F5D4E0:01CB182D] Subject: [Netconf] FW: Third Call for Nomcom 2010-11 Volunteers X-BeenThere: netconf@ietf.org X-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, 30 Jun 2010 08:23:04 -0000 =20 Hi All, > Participating in NomComm is an important contribution=20 > to the future of the IETF. Please consider volunteering. Cheers, Mehmet -----Original Message----- From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Tuesday, June 29, 2010 11:36 PM To: ops-chairs@ietf.org Subject: FW: Third Call for Nomcom 2010-11 Volunteers=20 Please send this third call for volunteers for NomComm to your WG lists. Participating in NomComm is an important contribution to the future of the IETF.=20 Regards, Dan -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Thomas Walsh Sent: Wednesday, June 30, 2010 12:31 AM To: ietf@ietf.org Subject: FW: Third Call for Nomcom 2010-11 Volunteers=20 Please volunteer if you are eligible. You must have attended 3 of the last 5 IETF meetings to be eligible. -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of NomCom Chair Sent: Monday, June 28, 2010 4:58 PM To: IETF Announcement list Subject: Third Call for Nomcom 2010-11 Volunteers=20 Hi all, =20 This is the Third call for Volunteers for the 2010-2011 Nomcom.=20 =20 We are now 2/3 of the way through the volunteer period so if you are considering volunteering please do so now as the time in which you may volunteer is beginning to run short. The call for volunteers remains open until 17:00 PDT (24:00 UTC) on July 8, 2010. =20 I am pleased to report that we currently have 65 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. I will publish the current list of volunteers in a separate message. =20 If you volunteered before 12:00 PDT (19:00 UTC) on June 28 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! =20 We still need additional volunteers, please! If you have attended at least 3 of the last 5 IETF meetings you are eligible to volunteer.=20 =20 The 10 nominating committee members are selected randomly from a pool of volunteers. The details of the operation of Nomcom may be found in RFC 3777. The process on how to volunteer for Nomcom is in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ =20 The lists of open positions and people whose terms end in March 2011 and thus the positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ =20 Please volunteer by sending an email before: 17:00 PDT (24:00 UTC) July 8, 2010 as follows: =20 To: nomcom-chair@ietf.org Subject: Nomcom 2010-11 Volunteer =20 Please include the following information in the body: =20 // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name =20 // typically what goes in the Company field // in the IETF Registration Form =20 // =20 // For confirmation if selected =20 Please expect an email response from me within 3 days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "Duplicate:" added to the subject line. =20 Thank you and I hope to hear from you, =20 Thomas Walsh Chair, Nomcom 2010-11 Email: nomcom-chair@ietf.org =20 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf