From andyb@iwl.com Sat May 1 12:32:01 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 456B53A6840 for ; Sat, 1 May 2010 12:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.476 X-Spam-Level: X-Spam-Status: No, score=-0.476 tagged_above=-999 required=5 tests=[AWL=-1.411, BAYES_50=0.001, 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 oD94nGyoUfJo for ; Sat, 1 May 2010 12:32:00 -0700 (PDT) Received: from smtp184.dfw.emailsrvr.com (smtp184.dfw.emailsrvr.com [67.192.241.184]) by core3.amsl.com (Postfix) with ESMTP id 474623A6807 for ; Sat, 1 May 2010 12:32:00 -0700 (PDT) Received: from relay18.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay18.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id ACD1F16F0BFA; Sat, 1 May 2010 15:31:45 -0400 (EDT) Received: by relay18.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 6911D16F0230; Sat, 1 May 2010 15:31:45 -0400 (EDT) Message-ID: <4BDC81A3.1080409@iwl.com> Date: Sat, 01 May 2010 12:31:47 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201004301434.o3UEY42M068686@idle.juniper.net> In-Reply-To: <201004301434.o3UEY42M068686@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] 4741bis -- :url capability issues 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, 01 May 2010 19:32:01 -0000 Phil Shafer wrote: > Andy Bierman writes: > > ... >> There is no support for a URL database, >> so why should there be any partial database editing? >> > > What's an "URL database"? > Good question. The standard does a really awful job of explaining that. It is awkwardly defined as: 1) an edit-content choice for edit-config 2) a source or target config-choice option for copy-config 3) a target of delete-config (Note that the current draft is wrong wrt/ delete-config -- Sec. 7.4 does not exclude 'candidate' as a target, but ietf-netconf.yang does exclue it. 4) config-source choice option for validate If I were learning NETCONF, I would think was supposed to be supported as a database because most the operations that affect it have 'config' in the name. But unlike , you cannot retrieve data with , or lock it before using it as the target of a , or find out what values the server will allow, or what values are currently in use (as a hint). The examples in E.1.2 do not really help much. I think the example is wrong: file://incoming.conf Correct: file://localhost/incoming.conf or file:///incoming.conf > >> Since the URL file always represents a complete database, >> there are no operations other than copy-config and delete-config >> that apply to it. >> > > You aren't editing an URL file, you are using a file as an alternative > to . That's why it's inside a "choice". > > OK -- except the external file will not validate correctly if it contains nc:operation attributes, so this sort of edit-config is likely to be restricted to a top-level merge or replace. >> 2) There is no lock support at all for URL databases, so it is >> not even clear that copy and delete are properly supported. >> >> Issue: Should be allowed in and >> operations? >> > > Again, what's an URL database? This is a new concept not > currently in 4741. > change database to 'file representation of a complete database'. > >> 3) :url interoperability >> >> It is not clear what a client application should expect >> for any given scheme, or what schemes a server SHOULD >> or even MAY support. >> >> Issue: is the :url capability interoperable? >> If not, what should be done about it? >> > > Not sure I follow you here, but the scheme allows the server > to tell the client what it supports. There is no SHOULD or > MUST, and MAY is pointless. > Not pointless to an NMS developer who has to write code to utilize :url on different servers. It's the same reason we picked a mandatory transport (SSH) -- for the benefit of the client, not the server. IMO, HTTP and FTP are awful choices, and SHOULD NOT be supported. I am surprised the IESG review of 4741 let that go in the security section review. In one section we explain how NETCONF requires a secure transport (2.2 & 2.3, although it says must instead of MUST), and in another we give examples of passing the entire config contents over-the-wire in clear-text. (!) > >> Current text: >> Similarly, just because someone says "go write a configuration >> through the URL capability at a particular place", this does not mean >> that an element should do it without proper authorization. >> > > s/element/device/ > > s/someone/a client/ > IMO, the entire SC text for :url needs to be rewritten. I guess that means I volunteer to add some text in 4741bis-03. > >> 5) 'file' scheme >> >> It is not clear whether: >> - absolute path specs must be supported by the server >> - the path-spec represents a conceptual file-system in >> the server, or the real file-system. >> - sub-directories must be supported >> - how many sub-directory levels deep are allowed >> - other restrictions apply, such as naming, number of files, etc. >> - if the internal mirrored NV-store is really a file, >> whether this file is accessible via the parameter. >> - if the external :startup config is accessible via the >> parameter. >> >> Issue: are any guidelines needed for the 'file' scheme? >> This is the most likely scheme to be supported by a server. >> > > There are massive interoperability issues with "file:", but > clearly absolute paths are required (file:///), but that the > device need not allow direct access to its native file systems, > if any, so the device can use any file naming mechanism. There > are no requirements in place re: directories, etc. Given the > extreme range of networking gear, I'm not sure this is worth > diving into. > > Yep -- it's a tar-baby. A server is free to do whatever it wants. Client developers: RTFM and figure it out. IMO, simple and operations would be better, but too late now. > Thanks, > Phil > > Andy From phil@juniper.net Sat May 1 15:23: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 8B2393A6920 for ; Sat, 1 May 2010 15:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.554 X-Spam-Level: X-Spam-Status: No, score=-4.554 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11, 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 VW-hBnPrVC9r for ; Sat, 1 May 2010 15:23:32 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 4568E3A69F2 for ; Sat, 1 May 2010 15:23:00 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKS9yps7eHYEE735W6BEj4aMKkmMrZ9ufh@postini.com; Sat, 01 May 2010 15:22:48 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Sat, 1 May 2010 13:57:10 -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); Sat, 1 May 2010 13:57:09 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 1 May 2010 13:57:08 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Sat, 1 May 2010 13:57:08 -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 o41Kv7D84507; Sat, 1 May 2010 13:57:07 -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 o41Ke4RF019392; Sat, 1 May 2010 20:40:04 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005012040.o41Ke4RF019392@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20100430.233126.188322952.mbj@tail-f.com> Date: Sat, 1 May 2010 16:40:04 -0400 From: Phil Shafer X-OriginalArrivalTime: 01 May 2010 20:57:08.0391 (UTC) FILETIME=[DCD31370:01CAE970] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis -- :url capability issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 01 May 2010 22:23:35 -0000 Martin Bjorklund writes: >(But I don't think this is an important feature, and would rather see >it removed.) I'm not on board with a 4741bis that removes features or "breaks" previously working implementations. There are many things that NETCONF allows that YANG does not, but that doesn't mean we can reasonably redesign NETCONF into a YANG-only transport. Thanks, Phil From phil@juniper.net Sat May 1 15:41: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 D87633A67FB for ; Sat, 1 May 2010 15:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.484 X-Spam-Level: X-Spam-Status: No, score=-5.484 tagged_above=-999 required=5 tests=[AWL=1.115, 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 Og7vpNSHce7y for ; Sat, 1 May 2010 15:41:41 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id F00193A68AD for ; Sat, 1 May 2010 15:41:40 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKS9yuFiha87lCo7ab0/JbH3OAWWRGMgdi@postini.com; Sat, 01 May 2010 15:41:27 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Sat, 1 May 2010 14:17:47 -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); Sat, 1 May 2010 14:17:47 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 1 May 2010 14:17:46 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Sat, 1 May 2010 14:17:46 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o41LHjD91768; Sat, 1 May 2010 14:17:45 -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 o41L0gWl020720; Sat, 1 May 2010 21:00:42 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005012100.o41L0gWl020720@idle.juniper.net> To: In-Reply-To: <4BDC81A3.1080409@iwl.com> Date: Sat, 1 May 2010 17:00:42 -0400 From: Phil Shafer X-OriginalArrivalTime: 01 May 2010 21:17:46.0188 (UTC) FILETIME=[BE9BE8C0:01CAE973] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] 4741bis -- :url capability issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 01 May 2010 22:41:43 -0000 Andy Bierman writes: >> What's an "URL database"? >Good question. >The standard does a really awful job of explaining that. The standard does not use that term. IMHO these were meant as files, not databases. This seems plain since, e.g. an url cannot be the target of an edit-config. Thanks, Phil From andyb@iwl.com Sat May 1 15:43: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 8F0893A67FB for ; Sat, 1 May 2010 15:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[AWL=-1.055, 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 HDzXtWmVa7Ha for ; Sat, 1 May 2010 15:43:30 -0700 (PDT) Received: from smtp114.dfw.emailsrvr.com (smtp114.dfw.emailsrvr.com [67.192.241.114]) by core3.amsl.com (Postfix) with ESMTP id C302C3A679C for ; Sat, 1 May 2010 15:43:30 -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 55D372E401EA; Sat, 1 May 2010 18:43:16 -0400 (EDT) Received: by relay21.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 150A22E4011C; Sat, 1 May 2010 18:43:16 -0400 (EDT) Message-ID: <4BDCAE86.7050906@iwl.com> Date: Sat, 01 May 2010 15:43:18 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201005012040.o41Ke4RF019392@idle.juniper.net> In-Reply-To: <201005012040.o41Ke4RF019392@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis -- :url capability issues 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, 01 May 2010 22:43:31 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >> (But I don't think this is an important feature, and would rather see >> it removed.) >> > > I'm not on board with a 4741bis that removes features or "breaks" > previously working implementations. > > But there are no implementations of 4741bis yet, because it isn't done yet. Your conformance to RFC 4741 is not affected by this document. > There are many things that NETCONF allows that YANG does not, but > that doesn't mean we can reasonably redesign NETCONF into a YANG-only > transport. > I agreed with you that the 4741bis document does not have to forbid a string element instead of an XML sub-tree. But there is no need to support a string element in the standard. If the NETCONF vendor does not choose to implement any modular XML content, which may include YANG modules, then the market can decide if that is useful. I think it is better to define modular content in XML namespaces. An un-versioned, no-schema, string database seems to retain all the bad parts of CLI. Why bother? > Thanks, > Phil > > Andy From mark.scott@ericsson.com Mon May 3 08:59: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 299493A6CDC for ; Mon, 3 May 2010 08:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.467, 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 hLMVkLzn53Pq for ; Mon, 3 May 2010 08:59:42 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 3365728C1D6 for ; Mon, 3 May 2010 08:59:40 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o43G4YCu019350; Mon, 3 May 2010 11:04:35 -0500 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.162]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 3 May 2010 11:59:21 -0400 From: Mark Scott To: Juergen Schoenwaelder Date: Mon, 3 May 2010 11:59:20 -0400 Thread-Topic: [Netconf] AD review of draft-ietf-netconf-monitoring-12 Thread-Index: AcronFGFDqpcww97R/e7JcoQ8Pr63wCMa3lw Message-ID: <75C89D709A9670428520E1CF8DD1344F2087EE1428@EUSAACMS0714.eamcs.ericsson.se> References: <20100428.125626.169114362.mbj@tail-f.com> <80A0822C5E9A4440A5117C2F4CD36A647A2174@DEMUEXC006.nsn-intra.net> <75C89D709A9670428520E1CF8DD1344F2087E77834@EUSAACMS0714.eamcs.ericsson.se> <75C89D709A9670428520E1CF8DD1344F2087E78551@EUSAACMS0714.eamcs.ericsson.se> <4BDB14F5.7000509@iwl.com> <75C89D709A9670428520E1CF8DD1344F2087EE0E8E@EUSAACMS0714.eamcs.ericsson.se> <20100430193439.GA4169@elstar.local> In-Reply-To: <20100430193439.GA4169@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 03 May 2010 15:59:44 -0000 Juergen, Thank you for the comments. To address your questions: The "can be used to uniquely..." was meant to state that in combination wit= h the other data it could uniquely identify a session. I.e. for a user 'Jo= e' you would not reply with username 'Joe-a' or 'Joe-b'. You would reply '= Joe' which in combination with other data like session-id and source-host p= rovide uniqueness. Agreed the text should be clearer. The "human or machine" was added to explicitly cover various authentication= methods such as (human) login credentials vs. (machine) keys in the case o= f SSH. It isn't needed though and I will remove it. For the revised text, if I could suggest one of these: 1. In the interest of being even more precise: "The username is the NETCONF transport protocol identity used =20 by the client to authenticate with the server." 2. Or perhaps you didn't want to tie specifically to transport for flexibi= lity to accommodate NETCONF security features: "The username is the NETCONF identity used by the client to =20 authenticate with the NETCONF server." My preference is the first one. If neither was the intent what is the "authenticated identity" referring to= in your proposed text? thank you, Mark -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: April-30-10 3:35 PM To: Mark Scott Cc: andyb@iwl.com; netconf@ietf.org Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12 On Fri, Apr 30, 2010 at 07:59:45PM +0200, Mark Scott wrote: >=20 > I will also remove the text suggesting the special handling ('if present'= ) from sec 2.1.4: >=20 > "username (string) > The username contains an identifier which can be used to=20 > uniquely identify an individual client (human or machine)." Now that we have the text in front of us: 'contains an identifier' or 'is an identifier'? what does 'uniquely identify an individual client' mean? If I have user joe using two clients a and b to access a server concurrently, will the usernames be "joe-a" and "joe-b"? Likely not, but the text says "uniquely identify an individual client". And what does (human or machine) mean? Whether joe relates to a human or a program, a server won't know. So what about this: The username identifies the authenticated identity on which behalf a client accesses a server. I believe this is shorter and more precise. =20 > and from the yang module: >=20 > "leaf username { > type string; > description > "The username contains an identifier which can > be used to uniquely identify an individual client (human > or machine). This is likely to be implementation specific > and subject to the security requirements of the device > vendor and/or operators, e.g., an SSH user, a host RSA > fingerprint or other identifier deemed acceptable."; > }" Similar changes should be done here if people like my proposal. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mark.scott@ericsson.com Mon May 3 09:14: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 BEAD63A6C23 for ; Mon, 3 May 2010 09:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKJvBZUOKVp8 for ; Mon, 3 May 2010 09:14:24 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id EECD23A6A37 for ; Mon, 3 May 2010 09:14:23 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o43GE7XB018136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 May 2010 11:14:08 -0500 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.162]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 3 May 2010 12:14:07 -0400 From: Mark Scott To: Martin Bjorklund Date: Mon, 3 May 2010 12:14:06 -0400 Thread-Topic: [Netconf] AD review of draft-ietf-netconf-monitoring-12 Thread-Index: Acrop9kX7nkIubziS5SA3pclRJyP9gCMcx/A Message-ID: <75C89D709A9670428520E1CF8DD1344F2087EE144B@EUSAACMS0714.eamcs.ericsson.se> References: <75C89D709A9670428520E1CF8DD1344F2087E78551@EUSAACMS0714.eamcs.ericsson.se> <4BDB14F5.7000509@iwl.com> <75C89D709A9670428520E1CF8DD1344F2087EE0E8E@EUSAACMS0714.eamcs.ericsson.se> <20100430.225743.53755455.mbj@tail-f.com> In-Reply-To: <20100430.225743.53755455.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 03 May 2010 16:14:24 -0000 I don't agree that username should be mandatory. Per earlier exchanges the monitoring draft will identify this as potentiall= y sensitive data in the security considerations. Under some circumstances = it may not be part of the reply. Mark > "username (string) > The username contains an identifier which can be used to=20 > uniquely identify an individual client (human or machine)." >=20 > and from the yang module: >=20 > "leaf username { > type string; > description > "The username contains an identifier which can > be used to uniquely identify an individual client (human > or machine). This is likely to be implementation specific > and subject to the security requirements of the device > vendor and/or operators, e.g., an SSH user, a host RSA > fingerprint or other identifier deemed acceptable."; > }" If we agree that the username is always there, we should add a 'mandatory true;' statement to the leaf. /martin From mbj@tail-f.com Mon May 3 09:30: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 5639828C22C for ; Mon, 3 May 2010 09:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.023 X-Spam-Level: X-Spam-Status: No, score=0.023 tagged_above=-999 required=5 tests=[AWL=-0.531, 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 gOCbE85dCElx for ; Mon, 3 May 2010 09:30:45 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4231D28C234 for ; Mon, 3 May 2010 09:30:35 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id DA38F616001; Mon, 3 May 2010 18:30:19 +0200 (CEST) Date: Mon, 03 May 2010 18:30:19 +0200 (CEST) Message-Id: <20100503.183019.163118321.mbj@tail-f.com> To: mark.scott@ericsson.com From: Martin Bjorklund In-Reply-To: <75C89D709A9670428520E1CF8DD1344F2087EE144B@EUSAACMS0714.eamcs.ericsson.se> References: <75C89D709A9670428520E1CF8DD1344F2087EE0E8E@EUSAACMS0714.eamcs.ericsson.se> <20100430.225743.53755455.mbj@tail-f.com> <75C89D709A9670428520E1CF8DD1344F2087EE144B@EUSAACMS0714.eamcs.ericsson.se> 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] AD review of draft-ietf-netconf-monitoring-12 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 03 May 2010 16:30:46 -0000 Mark Scott wrote: > I don't agree that username should be mandatory. > > Per earlier exchanges the monitoring draft will identify this as potentially > sensitive data in the security considerations. Under some circumstances it may > not be part of the reply. But whether it is included in the reply b/c of access control policies (or filtering) is orthogonal to if it is mandatory in the data model or not. From a data modelling perspective, it is mandatory, which means that it is always there -- but that does not mean that it is included in all NETCONF PDUs. /martin From andyb@iwl.com Mon May 3 09:51: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 AADFD3A6A1D for ; Mon, 3 May 2010 09:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=-0.849, 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 PWtfee5PwygV for ; Mon, 3 May 2010 09:51:41 -0700 (PDT) Received: from smtp144.iad.emailsrvr.com (smtp144.iad.emailsrvr.com [207.97.245.144]) by core3.amsl.com (Postfix) with ESMTP id E1C533A688C for ; Mon, 3 May 2010 09:51:40 -0700 (PDT) Received: from relay4.r5.iad.mlsrvr.com (localhost [127.0.0.1]) by relay4.r5.iad.mlsrvr.com (SMTP Server) with ESMTP id B667FC350; Mon, 3 May 2010 12:51:25 -0400 (EDT) Received: by relay4.r5.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 03388C338; Mon, 3 May 2010 12:51:24 -0400 (EDT) Message-ID: <4BDEFF10.2000507@iwl.com> Date: Mon, 03 May 2010 09:51:28 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Bjorklund References: <75C89D709A9670428520E1CF8DD1344F2087EE0E8E@EUSAACMS0714.eamcs.ericsson.se> <20100430.225743.53755455.mbj@tail-f.com> <75C89D709A9670428520E1CF8DD1344F2087EE144B@EUSAACMS0714.eamcs.ericsson.se> <20100503.183019.163118321.mbj@tail-f.com> In-Reply-To: <20100503.183019.163118321.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12 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, 03 May 2010 16:51:41 -0000 Martin Bjorklund wrote: > Mark Scott wrote: > >> I don't agree that username should be mandatory. >> >> Per earlier exchanges the monitoring draft will identify this as potentially >> sensitive data in the security considerations. Under some circumstances it may >> not be part of the reply. >> > > But whether it is included in the reply b/c of access control policies > (or filtering) is orthogonal to if it is mandatory in the data model > or not. From a data modelling perspective, it is mandatory, which > means that it is always there -- but that does not mean that it is > included in all NETCONF PDUs. > > yang-12, sec. 7.13.3, para 2: If a leaf in the output tree has a "mandatory" statement with the value "true", the leaf MUST be present in a NETCONF RPC reply. No wonder he is confused. > /martin > > Andy From mbj@tail-f.com Mon May 3 10:04: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 3A8E33A6A1F for ; Mon, 3 May 2010 10:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.058 X-Spam-Level: X-Spam-Status: No, score=0.058 tagged_above=-999 required=5 tests=[AWL=-0.496, 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 MFLaIGqxGASC for ; Mon, 3 May 2010 10:04:11 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6A6913A695C for ; Mon, 3 May 2010 10:04:11 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 89ED8616001; Mon, 3 May 2010 19:03:56 +0200 (CEST) Date: Mon, 03 May 2010 19:04:05 +0200 (CEST) Message-Id: <20100503.190405.246712699.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4BDEFF10.2000507@iwl.com> References: <75C89D709A9670428520E1CF8DD1344F2087EE144B@EUSAACMS0714.eamcs.ericsson.se> <20100503.183019.163118321.mbj@tail-f.com> <4BDEFF10.2000507@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] AD review of draft-ietf-netconf-monitoring-12 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 03 May 2010 17:04:12 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Mark Scott wrote: > > > >> I don't agree that username should be mandatory. > >> > >> Per earlier exchanges the monitoring draft will identify this as potentially > >> sensitive data in the security considerations. Under some circumstances it > >> may > >> not be part of the reply. > >> > > > > But whether it is included in the reply b/c of access control policies > > (or filtering) is orthogonal to if it is mandatory in the data model > > or not. From a data modelling perspective, it is mandatory, which > > means that it is always there -- but that does not mean that it is > > included in all NETCONF PDUs. > > > > > > yang-12, sec. 7.13.3, para 2: > > If a leaf in the output tree has a "mandatory" statement with the > value "true", the leaf MUST be present in a NETCONF RPC reply. > > No wonder he is confused. Ok, it could be more clear but this is for the output statement. Section 7.6.5 says that the mandatory statement is a constraint and covered by the rules in setion 8. Section 8 says about state data: o If the constraint is defined on state data, it MUST be true in a reply to a operation without a filter. It doesn't explicitly mention access control though... /martin From andyb@iwl.com Mon May 3 10:40: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 EE1C33A6809 for ; Mon, 3 May 2010 10:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=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 oZSDs0ThYp+L for ; Mon, 3 May 2010 10:40:10 -0700 (PDT) Received: from smtp154.dfw.emailsrvr.com (smtp154.dfw.emailsrvr.com [67.192.241.154]) by core3.amsl.com (Postfix) with ESMTP id 55D1B3A659A for ; Mon, 3 May 2010 10:40:10 -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 38DCC3F0399; Mon, 3 May 2010 13:39:54 -0400 (EDT) Received: by relay5.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 1B19F3EF26F; Mon, 3 May 2010 13:39:53 -0400 (EDT) Message-ID: <4BDF0A6E.5040306@iwl.com> Date: Mon, 03 May 2010 10:39:58 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Bjorklund References: <75C89D709A9670428520E1CF8DD1344F2087EE144B@EUSAACMS0714.eamcs.ericsson.se> <20100503.183019.163118321.mbj@tail-f.com> <4BDEFF10.2000507@iwl.com> <20100503.190405.246712699.mbj@tail-f.com> In-Reply-To: <20100503.190405.246712699.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12 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, 03 May 2010 17:40:12 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: > >> Martin Bjorklund wrote: >> >>> Mark Scott wrote: >>> >>> >>>> I don't agree that username should be mandatory. >>>> >>>> Per earlier exchanges the monitoring draft will identify this as potentially >>>> sensitive data in the security considerations. Under some circumstances it >>>> may >>>> not be part of the reply. >>>> >>>> >>> But whether it is included in the reply b/c of access control policies >>> (or filtering) is orthogonal to if it is mandatory in the data model >>> or not. From a data modelling perspective, it is mandatory, which >>> means that it is always there -- but that does not mean that it is >>> included in all NETCONF PDUs. >>> >>> >>> >> yang-12, sec. 7.13.3, para 2: >> >> If a leaf in the output tree has a "mandatory" statement with the >> value "true", the leaf MUST be present in a NETCONF RPC reply. >> >> No wonder he is confused. >> > > Ok, it could be more clear but this is for the output statement. > Section 7.6.5 says that the mandatory statement is a constraint and > covered by the rules in setion 8. Section 8 says about state data: > > o If the constraint is defined on state data, it MUST be true in a > reply to a operation without a filter. > > It doesn't explicitly mention access control though... > > The text is misleading. The mandatory-stmt is supposed to mean mandatory-to-implement, not mandatory-to-be-present-in-the-reply. The draft cleverly avoids mentioning the fact that mandatory=false for all config=false nodes means that those nodes are optional-to-implement for the server. A server can advertise the module, and elect to never include an optional config=false node in an rpc-reply. The issue has nothing to do with rpc output section vs. get/get-config output. It is really about module conformance. > /martin > > Andy From mark.scott@ericsson.com Tue May 4 08:08: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 D77FE28C103 for ; Tue, 4 May 2010 08:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.879 X-Spam-Level: X-Spam-Status: No, score=-2.879 tagged_above=-999 required=5 tests=[AWL=-0.280, 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 2MxySZxB-vA8 for ; Tue, 4 May 2010 08:08:17 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id E4F0228C114 for ; Tue, 4 May 2010 08:07:56 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o44F7aeT016336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 May 2010 10:07:39 -0500 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.162]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 4 May 2010 11:07:23 -0400 From: Mark Scott To: Martin Bjorklund , "andyb@iwl.com" Date: Tue, 4 May 2010 11:07:23 -0400 Thread-Topic: [Netconf] AD review of draft-ietf-netconf-monitoring-12 Thread-Index: Acrq4q12BWi2cSbsRA+IK/bcH5RkagAs+xsQ Message-ID: <75C89D709A9670428520E1CF8DD1344F2087F1DA62@EUSAACMS0714.eamcs.ericsson.se> References: <75C89D709A9670428520E1CF8DD1344F2087EE144B@EUSAACMS0714.eamcs.ericsson.se> <20100503.183019.163118321.mbj@tail-f.com> <4BDEFF10.2000507@iwl.com> <20100503.190405.246712699.mbj@tail-f.com> In-Reply-To: <20100503.190405.246712699.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 04 May 2010 15:08:19 -0000 Thanks for the clarifications but I still interpret this as meaning we'd be= expected to put this sensitive state data in an unfiltered reply. In the absence of standard access control the handling of sensitive data (b= oth state and config) is easier when it is not mandatory. So my preference remains that this be optional. Mark -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: May-03-10 1:04 PM To: andyb@iwl.com Cc: Mark Scott; dromasca@avaya.com; mehmet.ersue@nsn.com; netconf@ietf.org Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12 Andy Bierman wrote: > Martin Bjorklund wrote: > > Mark Scott wrote: > > =20 > >> I don't agree that username should be mandatory. > >> > >> Per earlier exchanges the monitoring draft will identify this as poten= tially > >> sensitive data in the security considerations. Under some circumstanc= es it > >> may > >> not be part of the reply. > >> =20 > > > > But whether it is included in the reply b/c of access control policies > > (or filtering) is orthogonal to if it is mandatory in the data model > > or not. From a data modelling perspective, it is mandatory, which > > means that it is always there -- but that does not mean that it is > > included in all NETCONF PDUs. > > > > =20 >=20 > yang-12, sec. 7.13.3, para 2: >=20 > If a leaf in the output tree has a "mandatory" statement with the > value "true", the leaf MUST be present in a NETCONF RPC reply. >=20 > No wonder he is confused. Ok, it could be more clear but this is for the output statement. Section 7.6.5 says that the mandatory statement is a constraint and covered by the rules in setion 8. Section 8 says about state data: o If the constraint is defined on state data, it MUST be true in a reply to a operation without a filter. It doesn't explicitly mention access control though... /martin From andyb@iwl.com Tue May 4 08:24: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 E3FFE3A6C34 for ; Tue, 4 May 2010 08:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.286, 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 r2XNcJYadHhr for ; Tue, 4 May 2010 08:24:34 -0700 (PDT) Received: from smtp164.dfw.emailsrvr.com (smtp164.dfw.emailsrvr.com [67.192.241.164]) by core3.amsl.com (Postfix) with ESMTP id 2095328C12C for ; Tue, 4 May 2010 08:20:35 -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 6645E14A5D; Tue, 4 May 2010 11:20:21 -0400 (EDT) Received: by relay16.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id CC330103CE; Tue, 4 May 2010 11:20:20 -0400 (EDT) Message-ID: <4BE03B3A.10004@iwl.com> Date: Tue, 04 May 2010 08:20:26 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Mark Scott References: <75C89D709A9670428520E1CF8DD1344F2087EE144B@EUSAACMS0714.eamcs.ericsson.se> <20100503.183019.163118321.mbj@tail-f.com> <4BDEFF10.2000507@iwl.com> <20100503.190405.246712699.mbj@tail-f.com> <75C89D709A9670428520E1CF8DD1344F2087F1DA62@EUSAACMS0714.eamcs.ericsson.se> In-Reply-To: <75C89D709A9670428520E1CF8DD1344F2087F1DA62@EUSAACMS0714.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12 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, 04 May 2010 15:24:35 -0000 Mark Scott wrote: > Thanks for the clarifications but I still interpret this as meaning we'd be expected to put this sensitive state data in an unfiltered reply. > > In the absence of standard access control the handling of sensitive data (both state and config) is easier when it is not mandatory. > > So my preference remains that this be optional. > > The conformance for this YANG module is a bit strange. There are only 3 mandatory-to-implement leafs: - /netconf-state/sessions/session-id - /netconf-state/sessions/transport - /netconf-state/sessions/login-time There is also a mandatory-to-implement operation (get-schema). A server can advertise this module and not implement anything else. Not sure that is obvious to everyone. I guess I prefer the SMIv2-style conformance. Although extra work for the author, it does make it clear what a client developer can hope to count on from a compliant server. In this case, nothing worthwhile at all. > Mark > Andy > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: May-03-10 1:04 PM > To: andyb@iwl.com > Cc: Mark Scott; dromasca@avaya.com; mehmet.ersue@nsn.com; netconf@ietf.org > Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12 > > Andy Bierman wrote: > >> Martin Bjorklund wrote: >> >>> Mark Scott wrote: >>> >>> >>>> I don't agree that username should be mandatory. >>>> >>>> Per earlier exchanges the monitoring draft will identify this as potentially >>>> sensitive data in the security considerations. Under some circumstances it >>>> may >>>> not be part of the reply. >>>> >>>> >>> But whether it is included in the reply b/c of access control policies >>> (or filtering) is orthogonal to if it is mandatory in the data model >>> or not. From a data modelling perspective, it is mandatory, which >>> means that it is always there -- but that does not mean that it is >>> included in all NETCONF PDUs. >>> >>> >>> >> yang-12, sec. 7.13.3, para 2: >> >> If a leaf in the output tree has a "mandatory" statement with the >> value "true", the leaf MUST be present in a NETCONF RPC reply. >> >> No wonder he is confused. >> > > Ok, it could be more clear but this is for the output statement. > Section 7.6.5 says that the mandatory statement is a constraint and > covered by the rules in setion 8. Section 8 says about state data: > > o If the constraint is defined on state data, it MUST be true in a > reply to a operation without a filter. > > It doesn't explicitly mention access control though... > > > /martin > > From bertietf@bwijnen.net Tue May 4 09:07: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 B10353A6C96 for ; Tue, 4 May 2010 09:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=0.573, 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 Z7W9wXDQeSnl for ; Tue, 4 May 2010 09:07:06 -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 49E733A6C93 for ; Tue, 4 May 2010 09:07:04 -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 1O9Kdv-0004hp-RQ for netconf@ietf.org; Tue, 04 May 2010 18:06:49 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=dhcp-26-33.ripemtg.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1O9Kdv-0002xe-O1 for netconf@ietf.org; Tue, 04 May 2010 18:06:43 +0200 Message-ID: <4BE04612.3090805@bwijnen.net> Date: Tue, 04 May 2010 18:06:42 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Netconf References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd453504133554e2869a34aae3dab93453b X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd453504133554e2869a34aae3dab93453b Subject: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 16:07:07 -0000 We have one day left before thsi WG Last Call ends. If you do have any comments, pls make sure we get it no later than tomorrow May 5th (any timezone) Bert and Mehmet Bert Wijnen (IETF) wrote: > This email starts a formal WG Last Call for the > draft-ietf-netconf-with-defaults-07.txt document > > The document is intended to be published as Proposed Standard. > > WGLC ends on May 5th 2010 (any timezone). > > Pls do review and send us your comments and feedback. > Also, if you see no problems with the document pls let us know. > A comment like: > I read the document and am happy with it. > isusefull too. It helps us determine how many people actually did > review. > > Thanks, > Bert and Mehmet (WG chairs) > > > ----- Original Message ----- From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Cc: netconf@ietf.org > Sent: Monday, April 19, 2010 2:45 PM > Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-07.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Network Configuration Working Group > of the IETF. > > > Title : With-defaults capability for NETCONF > Author(s) : A. Bierman, B. Lengyel > Filename : draft-ietf-netconf-with-defaults-07.txt > Pages : 21 > Date : 2010-04-19 > > The NETCONF protocol defines ways to read configuration data from a > NETCONF server. Part of this data is not set by the NETCONF client, > but rather a default value is used. In many situations the NETCONF > client has a priori knowledge about default data, so the NETCONF > server does not need to send it to the client. In other situations > the NETCONF client will need this data as part of the NETCONF reply> messages. This document defines a capability-based extension > to the NETCONF protocol that allows the NETCONF client to control > whether default values are part of NETCONF messages or > output to the target URL. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-with-defaults-07.txt > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From j.schoenwaelder@jacobs-university.de Tue May 4 10:42: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 848873A695C for ; Tue, 4 May 2010 10:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.032 X-Spam-Level: X-Spam-Status: No, score=-0.032 tagged_above=-999 required=5 tests=[AWL=-0.383, 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 hMO1klXFbfs3 for ; Tue, 4 May 2010 10:41:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A58973A6A24 for ; Tue, 4 May 2010 10:41:54 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BE11AC000F; Tue, 4 May 2010 19:41:40 +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 HR8xbrOfWZCe; Tue, 4 May 2010 19:41:39 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A6611C000D; Tue, 4 May 2010 19:41:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7CE0311E243E; Tue, 4 May 2010 19:41:39 +0200 (CEST) Date: Tue, 4 May 2010 19:41:39 +0200 From: Juergen Schoenwaelder To: Mark Scott Message-ID: <20100504174139.GA5737@elstar.local> Mail-Followup-To: Mark Scott , Martin Bjorklund , "andyb@iwl.com" , "netconf@ietf.org" References: <75C89D709A9670428520E1CF8DD1344F2087EE144B@EUSAACMS0714.eamcs.ericsson.se> <20100503.183019.163118321.mbj@tail-f.com> <4BDEFF10.2000507@iwl.com> <20100503.190405.246712699.mbj@tail-f.com> <75C89D709A9670428520E1CF8DD1344F2087F1DA62@EUSAACMS0714.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75C89D709A9670428520E1CF8DD1344F2087F1DA62@EUSAACMS0714.eamcs.ericsson.se> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12 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, 04 May 2010 17:42:02 -0000 On Tue, May 04, 2010 at 05:07:23PM +0200, Mark Scott wrote: > Thanks for the clarifications but I still interpret this as meaning we'd be expected to put this sensitive state data in an unfiltered reply. > > In the absence of standard access control the handling of sensitive data (both state and config) is easier when it is not mandatory. > > So my preference remains that this be optional. I tend to disagree with this. The lack of standard access control does not mean there is no access control. Furthermore, NETCONF runs over secure transports so there is no arbitrary access to this data even if you do not have granular access control. If we go down the path of making everything optional because of the lack of access control, where do we end with NETCONF? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Tue May 4 11:44: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 6E78C28C1C7 for ; Tue, 4 May 2010 11:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.463 X-Spam-Level: X-Spam-Status: No, score=-4.463 tagged_above=-999 required=5 tests=[AWL=-0.464, 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 V9Rry7tc2yuP for ; Tue, 4 May 2010 11:44:18 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 48E6028C1C9 for ; Tue, 4 May 2010 11:38:11 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKS+BpgH5gNof1JbgerVV7xWKg2ikMjc4t@postini.com; Tue, 04 May 2010 11:37:58 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Tue, 4 May 2010 11:36:44 -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); Tue, 4 May 2010 11:36:44 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 May 2010 11:36:44 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 May 2010 11:36: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 o44IahD09710; Tue, 4 May 2010 11:36: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 o44IJb5J050139; Tue, 4 May 2010 18:19:37 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005041819.o44IJb5J050139@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20100504174139.GA5737@elstar.local> Date: Tue, 4 May 2010 14:19:37 -0400 From: Phil Shafer X-OriginalArrivalTime: 04 May 2010 18:36:44.0075 (UTC) FILETIME=[BEC7B7B0:01CAEBB8] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 04 May 2010 18:44:19 -0000 Juergen Schoenwaelder writes: >If we go down the path of making everything optional because of the >lack of access control, where do we end with NETCONF? We'll end up right where we started off, where there's an implicit assumption that the administrator will provision the permissions of the client to allow the client to perform the actions the administrator needs for that client to perform. For example, if you want the client to back up your configuration, you need to give them full read-only access to the configuration. If the app is making VPNs, they need write access to all the appropriate configuration. If there's a leaf in the VPN config that the admin does not want the app to turn on, then it doesn't need write access to that. What the admin wants to app to do will dictate the permissions required by that app. In short, the issue of access control is orthogonal to the needs of the specific client application. Either the app can to the work it needs to do or it cannot. One doesn't expect to have an application auto-provision the user that it's going to use to login, right? Is the value of the ACM to report when something is not configured correctly? So the question becomes if you build the all-singing all-dancing access control solution, what is the target use case? The VPN config app? The admin that's setting up the VPN config app? Is there any realistic chance of displacing the CLI as the main avenue for configuring users and permissions? Is this a problem domain that we feel will convince people that NETCONF and YANG are the keys to addressing their configuration needs? Are ISPs dying to configure user permissions in an automated way, especially given their use of RADIUS, etc? Sorry, I know this is a tangent, but I just don't get it.... Thanks, Phil From mbj@tail-f.com Tue May 4 13:01:00 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B4C23A6D89 for ; Tue, 4 May 2010 13:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.141 X-Spam-Level: X-Spam-Status: No, score=0.141 tagged_above=-999 required=5 tests=[AWL=-0.413, 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 lfH-Tk1q+Qrf for ; Tue, 4 May 2010 13:00:59 -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 921BA28C51E for ; Tue, 4 May 2010 12:24:45 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id C2CEC616001; Tue, 4 May 2010 21:24:30 +0200 (CEST) Date: Tue, 04 May 2010 21:25:10 +0200 (CEST) Message-Id: <20100504.212510.03795651.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100504174139.GA5737@elstar.local> References: <20100503.190405.246712699.mbj@tail-f.com> <75C89D709A9670428520E1CF8DD1344F2087F1DA62@EUSAACMS0714.eamcs.ericsson.se> <20100504174139.GA5737@elstar.local> 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] AD review of draft-ietf-netconf-monitoring-12 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 04 May 2010 20:01:00 -0000 Juergen Schoenwaelder wrote: > On Tue, May 04, 2010 at 05:07:23PM +0200, Mark Scott wrote: > > Thanks for the clarifications but I still interpret this as meaning we'd be > > expected to put this sensitive state data in an unfiltered reply. > > > > In the absence of standard access control the handling of sensitive data > > (both state and config) is easier when it is not mandatory. > > > > So my preference remains that this be optional. > > I tend to disagree with this. The lack of standard access control does > not mean there is no access control. Furthermore, NETCONF runs over > secure transports so there is no arbitrary access to this data even if > you do not have granular access control. > > If we go down the path of making everything optional because of the > lack of access control, where do we end with NETCONF? I agree with Juergen. Marking stuff as optional in the data model b/c access control or subtree filtering might prune the data from some replies for some users is wrong. In this particular case, it seems we agree that all sessions must have a corresponding user name, thus this leaf should be marked as mandatory. /martin From j.schoenwaelder@jacobs-university.de Wed May 5 06:12: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 847323A69E0 for ; Wed, 5 May 2010 06:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[AWL=-0.362, 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 46VFwJcJHQsD for ; Wed, 5 May 2010 06:12:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 293083A68D0 for ; Wed, 5 May 2010 06:12:28 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B989C0024; Wed, 5 May 2010 15:12:14 +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 2g-4NoXKTvzC; Wed, 5 May 2010 15:12:13 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 65C2AC0028; Wed, 5 May 2010 15:12:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5615F11E5564; Wed, 5 May 2010 15:12:12 +0200 (CEST) Date: Wed, 5 May 2010 15:12:12 +0200 From: Juergen Schoenwaelder To: "Bert (IETF) Wijnen" Message-ID: <20100505131212.GB2892@elstar.local> Mail-Followup-To: "Bert (IETF) Wijnen" , Netconf References: <4BE04612.3090805@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BE04612.3090805@bwijnen.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Netconf Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 05 May 2010 13:12:29 -0000 On Tue, May 04, 2010 at 06:06:42PM +0200, Bert (IETF) Wijnen wrote: > We have one day left before thsi WG Last Call ends. > If you do have any comments, pls make sure we get it no later than > tomorrow May 5th (any timezone) Given that RFC 4741bis is defining NETCONF 1.1, it might have been better to integrate with-defaults straight into 4741bis instead of using a separate document with YANG augmentations and a recommendation that every server SHOULD implement with-defaults, thus leaving the behaviour of the base protocol itself unspecified when it comes to defaults. I do understand the procedural counter argument. Still I thought I air this observation one more last time. /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 May 5 06:24:00 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5412E3A6C0D for ; Wed, 5 May 2010 06:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.672 X-Spam-Level: X-Spam-Status: No, score=0.672 tagged_above=-999 required=5 tests=[AWL=-0.678, 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 WwUYEPy3lbac for ; Wed, 5 May 2010 06:23:49 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id F2BE83A6C1B for ; Wed, 5 May 2010 06:23: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 CAFA02CDE057 for ; Wed, 5 May 2010 15:22:54 +0200 (CEST) From: Ladislav Lhotka To: netconf@ietf.org In-Reply-To: <20100505131212.GB2892@elstar.local> References: <4BE04612.3090805@bwijnen.net> <20100505131212.GB2892@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 05 May 2010 15:22:53 +0200 Message-ID: <1273065773.18014.26.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 13:24:00 -0000 Juergen Schoenwaelder píše v St 05. 05. 2010 v 15:12 +0200: > On Tue, May 04, 2010 at 06:06:42PM +0200, Bert (IETF) Wijnen wrote: > > We have one day left before thsi WG Last Call ends. > > If you do have any comments, pls make sure we get it no later than > > tomorrow May 5th (any timezone) > > Given that RFC 4741bis is defining NETCONF 1.1, it might have been > better to integrate with-defaults straight into 4741bis instead of > using a separate document with YANG augmentations and a recommendation > that every server SHOULD implement with-defaults, thus leaving the > behaviour of the base protocol itself unspecified when it comes to > defaults. +1 Lada > > I do understand the procedural counter argument. Still I thought I air > this observation one more last time. > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Wed May 5 06:41: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 6392428C10A for ; Wed, 5 May 2010 06:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929, 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 CKja0pqr19+a for ; Wed, 5 May 2010 06:41:40 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id BE5193A68F7 for ; Wed, 5 May 2010 06:41:34 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKS+F1eqQK1D27YgPPKhA5OWGRPR6Se7tm@postini.com; Wed, 05 May 2010 06:41:22 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Wed, 5 May 2010 06:39:53 -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, 5 May 2010 06:39:53 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 May 2010 06:39:53 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 May 2010 06:39:52 -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 o45DdqD05135; Wed, 5 May 2010 06:39:52 -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 o45DMjof012941; Wed, 5 May 2010 13:22:45 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005051322.o45DMjof012941@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20100505131212.GB2892@elstar.local> Date: Wed, 5 May 2010 09:22:45 -0400 From: Phil Shafer X-OriginalArrivalTime: 05 May 2010 13:39:52.0854 (UTC) FILETIME=[70E0D360:01CAEC58] MIME-Version: 1.0 Content-Type: text/plain Cc: Netconf Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 13:41:41 -0000 Juergen Schoenwaelder writes: >Given that RFC 4741bis is defining NETCONF 1.1, it might have been >better to integrate with-defaults straight into 4741bis ... I would object to including it directly in 4741bis. I'm uncomfortable with this idea "that RFC 4741bis is defining NETCONF 1.1" and hope that we can limit "bis" to clarification and mild improvments without inventing new material. If the true goal is to invent new material, we should stop calling it "bis" and start calling it "NETCONF 2". Thanks, Phil From lhotka@cesnet.cz Wed May 5 07:16: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 7B9F628C246 for ; Wed, 5 May 2010 07:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.729 X-Spam-Level: X-Spam-Status: No, score=0.729 tagged_above=-999 required=5 tests=[AWL=-0.621, 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 H7D1ndUf0L9N for ; Wed, 5 May 2010 07:16:55 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7E1383A6CBA for ; Wed, 5 May 2010 07:11:58 -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 224892CDE058 for ; Wed, 5 May 2010 16:11:42 +0200 (CEST) From: Ladislav Lhotka To: netconf@ietf.org In-Reply-To: <201005051322.o45DMjof012941@idle.juniper.net> References: <201005051322.o45DMjof012941@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 05 May 2010 16:11:40 +0200 Message-ID: <1273068700.18014.33.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 14:16:56 -0000 Phil Shafer píše v St 05. 05. 2010 v 09:22 -0400: > Juergen Schoenwaelder writes: > >Given that RFC 4741bis is defining NETCONF 1.1, it might have been > >better to integrate with-defaults straight into 4741bis ... > > I would object to including it directly in 4741bis. I'm uncomfortable > with this idea "that RFC 4741bis is defining NETCONF 1.1" and hope > that we can limit "bis" to clarification and mild improvments without > inventing new material. If the true goal is to invent new material, > we should stop calling it "bis" and start calling it "NETCONF 2". Actually, YANG is the new material here, and YANG uses a few important assumptions related to the concept of default values, so IMO the ability of the server to tell (at the very least) its way of handling defaults is a critical prerequisite for YANG. Lada > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Wed May 5 07:47: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 242AA3A6AC8 for ; Wed, 5 May 2010 07:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.689 X-Spam-Level: X-Spam-Status: No, score=-0.689 tagged_above=-999 required=5 tests=[AWL=-1.024, 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 1F6wOuIeTrul for ; Wed, 5 May 2010 07:47: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 7D2BA3A684C for ; Wed, 5 May 2010 07:42:18 -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 ED94910CC1B7; Wed, 5 May 2010 10:42:04 -0400 (EDT) Received: by relay4.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id B926810CBEA5; Wed, 5 May 2010 10:42:04 -0400 (EDT) Message-ID: <4BE183C3.9000309@iwl.com> Date: Wed, 05 May 2010 07:42:11 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Ladislav Lhotka References: <201005051322.o45DMjof012941@idle.juniper.net> <1273068700.18014.33.camel@missotis> In-Reply-To: <1273068700.18014.33.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 05 May 2010 14:47:25 -0000 Ladislav Lhotka wrote: > Phil Shafer píše v St 05. 05. 2010 v 09:22 -0400: > >> Juergen Schoenwaelder writes: >> >>> Given that RFC 4741bis is defining NETCONF 1.1, it might have been >>> better to integrate with-defaults straight into 4741bis ... >>> >> I would object to including it directly in 4741bis. I'm uncomfortable >> with this idea "that RFC 4741bis is defining NETCONF 1.1" and hope >> that we can limit "bis" to clarification and mild improvments without >> inventing new material. If the true goal is to invent new material, >> we should stop calling it "bis" and start calling it "NETCONF 2". >> > > According to wikipedia, 'bis' does essentially mean NETCONF '2'. So what? We have no requirement to maintain backward compatibility with RFC 4741. We are cycling at Proposed Standard. You can expect that servers compliant to 4741 will need to do some work to be compliant to 4741bis. There are specific detailed changes that the WG is debating, 1 at a time, such as the 'capability-changed' error. It does not help to debate abstractions such as whether this is version 1.1, 1.5, or 2.0. > Actually, YANG is the new material here, and YANG uses a few important > assumptions related to the concept of default values, so IMO the ability > of the server to tell (at the very least) its way of handling defaults > is a critical prerequisite for YANG. > YANG does specify default behavior. It says the server MAY leave them out. What's the problem? We don't care about non-YANG content anymore in NETCONF, right? >From a standards POV, it's simply not our problem anymore. So how NETCONF handles defaults outside of YANG is an issue outside the scope of the standard. > Lada > > >> Thanks, >> Phil >> Andy From mark.scott@ericsson.com Wed May 5 08:07: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 0E43F28C269 for ; Wed, 5 May 2010 08:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=-0.233, 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 VXTW4Bfa43K0 for ; Wed, 5 May 2010 08:07:15 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 8A6723A686D for ; Wed, 5 May 2010 08:01:23 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o45F18aO022676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 May 2010 10:01:08 -0500 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.162]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 5 May 2010 11:01:07 -0400 From: Mark Scott To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" Date: Wed, 5 May 2010 11:01:07 -0400 Thread-Topic: [Netconf] AD review of draft-ietf-netconf-monitoring-12 Thread-Index: Acrrv3F4Hd/fV1AuR527Flt9LMTyBQAo5hZQ Message-ID: <75C89D709A9670428520E1CF8DD1344F2087F2C80B@EUSAACMS0714.eamcs.ericsson.se> References: <20100503.190405.246712699.mbj@tail-f.com> <75C89D709A9670428520E1CF8DD1344F2087F1DA62@EUSAACMS0714.eamcs.ericsson.se> <20100504174139.GA5737@elstar.local> <20100504.212510.03795651.mbj@tail-f.com> In-Reply-To: <20100504.212510.03795651.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 05 May 2010 15:07:16 -0000 OK, consensus is 'username' will be mandatory. Mark -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: May-04-10 3:25 PM To: j.schoenwaelder@jacobs-university.de Cc: Mark Scott; andyb@iwl.com; netconf@ietf.org Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12 Juergen Schoenwaelder wrote: > On Tue, May 04, 2010 at 05:07:23PM +0200, Mark Scott wrote: > > Thanks for the clarifications but I still interpret this as meaning we'= d be > > expected to put this sensitive state data in an unfiltered reply. > >=20 > > In the absence of standard access control the handling of sensitive dat= a > > (both state and config) is easier when it is not mandatory. > >=20 > > So my preference remains that this be optional. >=20 > I tend to disagree with this. The lack of standard access control does > not mean there is no access control. Furthermore, NETCONF runs over > secure transports so there is no arbitrary access to this data even if > you do not have granular access control. >=20 > If we go down the path of making everything optional because of the > lack of access control, where do we end with NETCONF? I agree with Juergen. Marking stuff as optional in the data model b/c access control or subtree filtering might prune the data from some replies for some users is wrong. In this particular case, it seems we agree that all sessions must have a corresponding user name, thus this leaf should be marked as mandatory. /martin From phil@juniper.net Wed May 5 08:09: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 235593A6C30 for ; Wed, 5 May 2010 08:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.825 X-Spam-Level: X-Spam-Status: No, score=-5.825 tagged_above=-999 required=5 tests=[AWL=0.774, 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 8dML6+84cqmA for ; Wed, 5 May 2010 08:09:48 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 9314628C2BE for ; Wed, 5 May 2010 08:02:44 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKS+GIha8qjgPPGDZjDcGf0ej2pJWwi/yk@postini.com; Wed, 05 May 2010 08:02:31 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Wed, 5 May 2010 08:01:18 -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); Wed, 5 May 2010 08:01:18 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 May 2010 08:01:18 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 May 2010 08:01:17 -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 o45F1HD43585; Wed, 5 May 2010 08:01:17 -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 o45EiAwX013853; Wed, 5 May 2010 14:44:10 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005051444.o45EiAwX013853@idle.juniper.net> To: Ladislav Lhotka Date: Wed, 5 May 2010 10:44:10 -0400 From: Phil Shafer X-OriginalArrivalTime: 05 May 2010 15:01:17.0729 (UTC) FILETIME=[D07D9910:01CAEC63] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 15:09:50 -0000 Ladislav Lhotka writes: >Actually, YANG is the new material here, and YANG uses a few important >assumptions related to the concept of default values, so IMO the ability >of the server to tell (at the very least) its way of handling defaults >is a critical prerequisite for YANG. YANG gives a way of dealing with default values. They are engraved in the stone in the YANG module. By contrast, with-defaults seems to reflect the SNMP mind set, where there was no way to determine the real underlaying default value since the MIB contained only a suggested default value. I can see a convincing reason why I would need to implement with-defaults, or why I would use it in an application. Thanks, Phil From phil@juniper.net Wed May 5 08:17: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 CCF0128C357 for ; Wed, 5 May 2010 08:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.936 X-Spam-Level: X-Spam-Status: No, score=-5.936 tagged_above=-999 required=5 tests=[AWL=0.663, 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 e-wIs23qIbf2 for ; Wed, 5 May 2010 08:17:45 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 3DE2828C32E for ; Wed, 5 May 2010 08:09:22 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKS+GKFMCRaLtVuMlWcqPF6Kkxli62xsCe@postini.com; Wed, 05 May 2010 08:09:10 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Wed, 5 May 2010 08:09:06 -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, 5 May 2010 08:09:06 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 May 2010 08:09:06 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 May 2010 08:09: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 o45F94D47155; Wed, 5 May 2010 08:09:05 -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 o45Epwit013962; Wed, 5 May 2010 14:51:58 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005051451.o45Epwit013962@idle.juniper.net> To: Date: Wed, 5 May 2010 10:51:58 -0400 From: Phil Shafer X-OriginalArrivalTime: 05 May 2010 15:09:05.0754 (UTC) FILETIME=[E7748BA0:01CAEC64] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 15:17:46 -0000 Andy Bierman writes: >We have no requirement to maintain backward compatibility >with RFC 4741. We are cycling at Proposed Standard. I don't think so. The WG charter limits changes to bug fixes and clarifications. See attached. Thanks, Phil ---- https://datatracker.ietf.org/wg/netconf/charter/ 6. NETCONF implementations have shown that the specification in RFC4741 is not 100% clear and has lead to different interpretations and implementations. Also some errors have been uncovered. So the WG will do an rfc4741bis with following constraints: - bug fixes are to be done - clarifications can be done - extensions can be done only when needed to fix bugs or inconsistencies (i.e. we are not doing a NETCONF V2) - The work can be started based on the discussion in IETF #73 (see http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf). From andyb@iwl.com Wed May 5 08: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 1106328C37B for ; Wed, 5 May 2010 08:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_05=-1.11, 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 5FZsp5HOwi7G for ; Wed, 5 May 2010 08:21:53 -0700 (PDT) Received: from smtp184.iad.emailsrvr.com (smtp184.iad.emailsrvr.com [207.97.245.184]) by core3.amsl.com (Postfix) with ESMTP id 297CD3A6C49 for ; Wed, 5 May 2010 08:14:09 -0700 (PDT) Received: from relay18.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay18.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 577421B4072; Wed, 5 May 2010 11:13:55 -0400 (EDT) Received: by relay18.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id EC1A61B426F; Wed, 5 May 2010 11:13:54 -0400 (EDT) Message-ID: <4BE18B39.4010301@iwl.com> Date: Wed, 05 May 2010 08:14:01 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201005051451.o45Epwit013962@idle.juniper.net> In-Reply-To: <201005051451.o45Epwit013962@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.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, 05 May 2010 15:21:55 -0000 Phil Shafer wrote: > Andy Bierman writes: > >> We have no requirement to maintain backward compatibility >> with RFC 4741. We are cycling at Proposed Standard. >> > > I don't think so. The WG charter limits changes to bug fixes and > clarifications. See attached. > > That is what we are doing. All of the changes have been bug fixes. Even the new confirmed-commit stuff is to address problems with the existing operation. This is irrelevant to the standards process in RFC 2026. We already decided to cycle at PS. RFC 2026 does not require this type of update to be backward compatible. > Thanks, > Phil > Andy > ---- > > https://datatracker.ietf.org/wg/netconf/charter/ > > 6. NETCONF implementations have shown that the specification in > RFC4741 is not 100% clear and has lead to different interpretations > and implementations. Also some errors have been uncovered. So the > WG will do an rfc4741bis with following constraints: > > - bug fixes are to be done > - clarifications can be done > - extensions can be done only when needed to fix bugs > or inconsistencies (i.e. we are not doing a NETCONF V2) > - The work can be started based on the discussion in IETF #73 (see > http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf). > > From phil@juniper.net Wed May 5 08:26: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 6AE5528C2F8 for ; Wed, 5 May 2010 08:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.018 X-Spam-Level: X-Spam-Status: No, score=-6.018 tagged_above=-999 required=5 tests=[AWL=0.581, 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 OzIweXh4Lrf6 for ; Wed, 5 May 2010 08:26:39 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 2C52D28C32E for ; Wed, 5 May 2010 08:17:47 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKS+GMDIPNGybiH9awmraCeLwVA1g27oSf@postini.com; Wed, 05 May 2010 08:17:34 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Wed, 5 May 2010 08:15:54 -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, 5 May 2010 08:15:53 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 May 2010 08:15:53 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 May 2010 08:15:52 -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 o45FFqD50565; Wed, 5 May 2010 08:15:52 -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 o45EwjYT014102; Wed, 5 May 2010 14:58:45 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005051458.o45EwjYT014102@idle.juniper.net> To: In-Reply-To: <4BE18B39.4010301@iwl.com> Date: Wed, 5 May 2010 10:58:45 -0400 From: Phil Shafer X-OriginalArrivalTime: 05 May 2010 15:15:52.0749 (UTC) FILETIME=[DA0B0DD0:01CAEC65] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 15:26:40 -0000 Andy Bierman writes: >That is what we are doing. >All of the changes have been bug fixes. I don't think "with-defaults" fits this charter. Thanks, Phil From andyb@iwl.com Wed May 5 08:28: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 7BB3E28C347 for ; Wed, 5 May 2010 08:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.747 X-Spam-Level: X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[AWL=-0.896, BAYES_40=-0.185, 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 Um34D1YXxgIC for ; Wed, 5 May 2010 08:28:08 -0700 (PDT) Received: from smtp194.dfw.emailsrvr.com (smtp194.dfw.emailsrvr.com [67.192.241.194]) by core3.amsl.com (Postfix) with ESMTP id D8B1428C2C9 for ; Wed, 5 May 2010 08:19:07 -0700 (PDT) Received: from relay9.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 46DAB13D352A; Wed, 5 May 2010 11:18:54 -0400 (EDT) Received: by relay9.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id D2BC313D34A7; Wed, 5 May 2010 11:18:53 -0400 (EDT) Message-ID: <4BE18C64.9070205@iwl.com> Date: Wed, 05 May 2010 08:19:00 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201005051444.o45EiAwX013853@idle.juniper.net> In-Reply-To: <201005051444.o45EiAwX013853@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.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, 05 May 2010 15:28:09 -0000 Phil Shafer wrote: > Ladislav Lhotka writes: > >> Actually, YANG is the new material here, and YANG uses a few important >> assumptions related to the concept of default values, so IMO the ability >> of the server to tell (at the very least) its way of handling defaults >> is a critical prerequisite for YANG. >> > > YANG gives a way of dealing with default values. They are engraved > in the stone in the YANG module. If you think this, then you don't understand YANG. We don't need to repeat all the ways that the meta-dataset can be ambiguous. They are in the ML archive. > By contrast, with-defaults seems > to reflect the SNMP mind set, where there was no way to determine > the real underlaying default value since the MIB contained only a > suggested default value. I can see a convincing reason why I would > need to implement with-defaults, or why I would use it in an > application. > We went through this discussion already. Refer to the archive for details. > Thanks, > Phil > _________ Andy From andyb@iwl.com Wed May 5 08:31: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 73E0428C3AD for ; Wed, 5 May 2010 08:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.341, 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 gFrItD2tfFHd for ; Wed, 5 May 2010 08:31:49 -0700 (PDT) Received: from smtp194.dfw.emailsrvr.com (smtp194.dfw.emailsrvr.com [67.192.241.194]) by core3.amsl.com (Postfix) with ESMTP id 0F2CB3A68C0 for ; Wed, 5 May 2010 08:22:24 -0700 (PDT) Received: from relay9.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 8C76613D394D; Wed, 5 May 2010 11:22:10 -0400 (EDT) Received: by relay9.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 2A5B013D327A; Wed, 5 May 2010 11:22:10 -0400 (EDT) Message-ID: <4BE18D29.3050707@iwl.com> Date: Wed, 05 May 2010 08:22:17 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201005051458.o45EwjYT014102@idle.juniper.net> In-Reply-To: <201005051458.o45EwjYT014102@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.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, 05 May 2010 15:31:50 -0000 Phil Shafer wrote: > Andy Bierman writes: > >> That is what we are doing. >> All of the changes have been bug fixes. >> > > I don't think "with-defaults" fits this charter. > But this document has a different charter. IMO, starting over on with-defaults is a non-starter. That draft has been reviewed by many people, up to 8 times already. It is an insult to these reviewers, not to mention a complete disregard for the schedule (and way overdue milestones), to start over on this work. > Thanks, > Phil > > Andy From lhotka@cesnet.cz Wed May 5 08:49: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 EE86228C37F for ; Wed, 5 May 2010 08:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.776 X-Spam-Level: X-Spam-Status: No, score=0.776 tagged_above=-999 required=5 tests=[AWL=-0.574, 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 yWgxufPyyFwf for ; Wed, 5 May 2010 08:49:49 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3D55528C11F for ; Wed, 5 May 2010 08:42:53 -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 462A42CDE057; Wed, 5 May 2010 17:42:39 +0200 (CEST) From: Ladislav Lhotka To: andyb@iwl.com In-Reply-To: <4BE18D29.3050707@iwl.com> References: <201005051458.o45EwjYT014102@idle.juniper.net> <4BE18D29.3050707@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 05 May 2010 17:42:37 +0200 Message-ID: <1273074157.18014.41.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 15:49:50 -0000 Andy Bierman píše v St 05. 05. 2010 v 08:22 -0700: > Phil Shafer wrote: > > Andy Bierman writes: > > > >> That is what we are doing. > >> All of the changes have been bug fixes. > >> > > > > I don't think "with-defaults" fits this charter. > > > > But this document has a different charter. > IMO, starting over on with-defaults is a non-starter. > That draft has been reviewed by many people, up to 8 times already. > It is an insult to these reviewers, not to mention a complete > disregard for the schedule (and way overdue milestones), > to start over on this work. I believe that integrating with-defaults into 4741bis does not mean starting over and that the authors' and reviewers' work won't be lost at all. The eight iterations helped improve the text and the whole concept considerably. Lada > > > Thanks, > > Phil > > > > > > Andy > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Wed May 5 09:04: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 13C703A6934 for ; Wed, 5 May 2010 09:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[AWL=-0.970, 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 ERvp6tM9qCO0 for ; Wed, 5 May 2010 09:04:07 -0700 (PDT) Received: from smtp194.dfw.emailsrvr.com (smtp194.dfw.emailsrvr.com [67.192.241.194]) by core3.amsl.com (Postfix) with ESMTP id 1EDF33A6D35 for ; Wed, 5 May 2010 08:57:21 -0700 (PDT) Received: from relay9.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id CB51D13D3CA9; Wed, 5 May 2010 11:57:07 -0400 (EDT) Received: by relay9.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 8057013D3C75; Wed, 5 May 2010 11:57:07 -0400 (EDT) Message-ID: <4BE1955A.5020007@iwl.com> Date: Wed, 05 May 2010 08:57:14 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Ladislav Lhotka References: <201005051458.o45EwjYT014102@idle.juniper.net> <4BE18D29.3050707@iwl.com> <1273074157.18014.41.camel@missotis> In-Reply-To: <1273074157.18014.41.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.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, 05 May 2010 16:04:08 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v St 05. 05. 2010 v 08:22 -0700: > >> Phil Shafer wrote: >> >>> Andy Bierman writes: >>> >>> >>>> That is what we are doing. >>>> All of the changes have been bug fixes. >>>> >>>> >>> I don't think "with-defaults" fits this charter. >>> >>> >> But this document has a different charter. >> IMO, starting over on with-defaults is a non-starter. >> That draft has been reviewed by many people, up to 8 times already. >> It is an insult to these reviewers, not to mention a complete >> disregard for the schedule (and way overdue milestones), >> to start over on this work. >> > > I believe that integrating with-defaults into 4741bis does not mean > starting over and that the authors' and reviewers' work won't be lost at > all. The eight iterations helped improve the text and the whole concept > considerably. > I think it does mean starting over. It means rechartering 4741bis, which is a bad idea. It means taking even longer to finish work that is already late. I don't see the problem. The with-defaults draft provides additional functionality to the base protocol -- the ability to detect the defaults behavior of the server and the ability to retrieve data using a specific style. Normally (90% ?) the YANG or XSD schema will provide the defaults so the operator can just 'trust' the server basic mode. (Just use explicit -- it works ;-) When an operator is debugging a server that is not behaving as expected, or when installing a new SW version from a vendor who has been known to change defaults in the past, it is useful to verify the defaults are in fact implemented correctly. When YANG deviations and import-by-revision become factors, retrieving 'report-all' can be even more important for debugging purposes. Whether this is critical, useful, nice-to-have, or useless is a subjective decision. Packaging technical specifications in multiple RFCs is a reality in the IETF. Some people even prefer multiple documents over 1 giant document. > Lada > > >>> Thanks, >>> Phil >>> >>> Andy From kwatsen@juniper.net Wed May 5 15:39: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 586643A6D45 for ; Wed, 5 May 2010 15:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=-0.650, 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 cXdzkFygcSiJ for ; Wed, 5 May 2010 15:39:17 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 634EF3A6D3E for ; Wed, 5 May 2010 15:39:17 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKS+Hzh1Q2MkMRVM1G8/T5LeGTXa5hQeE2@postini.com; Wed, 05 May 2010 15:39:04 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 5 May 2010 15:38:19 -0700 From: Kent Watsen To: "netconf@ietf.org" Date: Wed, 5 May 2010 15:38:19 -0700 Thread-Topic: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt Thread-Index: AcrsXZi0ZAnusI4XS+qgoub24mopXAAPeGaQ Message-ID: <84600D05C20FF943918238042D7670FD36C7D7635F@EMBX01-HQ.jnpr.net> References: <201005051322.o45DMjof012941@idle.juniper.net> <1273068700.18014.33.camel@missotis> In-Reply-To: <1273068700.18014.33.camel@missotis> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 22:39:18 -0000 Lada writes: > IMO the ability of the server to tell (at the very least) its way > of handling defaults is a critical prerequisite for YANG. I agree that this part of the I-D is good; it's important servers define th= eir basic-mode so clients know how to interoperate with them It's the other part of this I-D, forcing trim/explicit servers to support r= eport-all without tagging, that I continue to have issues with; the questio= ns asked in last the email I sent on April 5th remain open As I was explaining to Phil, if supporting report-all was optional, surely = Juniper would not, since the downside risks far exceed any value it brings = (our schema-defined defaults are always correct). But since supporting rep= ort-all is currently not optional, Juniper instead needs to decide if it's = going to support this capability at all Personally, I think this I-D has a great opportunity to introduce the use o= f attributes to let explicit/trim-servers tag the default values as such. = Not only does this remove the downside risks for explicit servers, but it a= lso enables thin-clients to act on that extra bit on information. Note: th= in-client could be the on-box web interface. Now that it's been establishe= d that the WG has never defined a concern for using attributes for metadata= , and there are many good reasons for wanting to do so, it seems like its t= ime has come Please either remove the "MUST support report-all" requirement or introduce= support for tagging defaults Thanks, Kent From andyb@iwl.com Wed May 5 16:11: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 1A4333A6CCC for ; Wed, 5 May 2010 16:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=-0.869, 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 tpyQ-7LSrS6Y for ; Wed, 5 May 2010 16:11:09 -0700 (PDT) Received: from smtp204.iad.emailsrvr.com (smtp204.iad.emailsrvr.com [207.97.245.204]) by core3.amsl.com (Postfix) with ESMTP id 9B50628C18E for ; Wed, 5 May 2010 16:11:07 -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 EE1F81EA611; Wed, 5 May 2010 19:10:53 -0400 (EDT) Received: by relay10.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 7AD1F1EA3CF; Wed, 5 May 2010 19:10:53 -0400 (EDT) Message-ID: <4BE1FB03.7010004@iwl.com> Date: Wed, 05 May 2010 16:10:59 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <201005051322.o45DMjof012941@idle.juniper.net> <1273068700.18014.33.camel@missotis> <84600D05C20FF943918238042D7670FD36C7D7635F@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D7635F@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 05 May 2010 23:11:11 -0000 Kent Watsen wrote: > Lada writes: > >> IMO the ability of the server to tell (at the very least) its way >> of handling defaults is a critical prerequisite for YANG. >> > > I agree that this part of the I-D is good; it's important servers define their basic-mode so clients know how to interoperate with them > > It's the other part of this I-D, forcing trim/explicit servers to support report-all without tagging, that I continue to have issues with; the questions asked in last the email I sent on April 5th remain open > > As I was explaining to Phil, if supporting report-all was optional, surely Juniper would not, since the downside risks far exceed any value it brings (our schema-defined defaults are always correct). But since supporting report-all is currently not optional, Juniper instead needs to decide if it's going to support this capability at all > > Personally, I think this I-D has a great opportunity to introduce the use of attributes to let explicit/trim-servers tag the default values as such. Not only does this remove the downside risks for explicit servers, but it also enables thin-clients to act on that extra bit on information. Note: thin-client could be the on-box web interface. Now that it's been established that the WG has never defined a concern for using attributes for metadata, and there are many good reasons for wanting to do so, it seems like its time has come > > Please either remove the "MUST support report-all" requirement or introduce support for tagging defaults > > I don't see how you could possibly get the XML attribute tag for a leaf that wasn't there (in the reply). You have to return all the nodes in order to return their tags (that means report-all). The WG already decided to have different modes to retrieve only the nodes that matched that mode. This is viewed as a service, rather than requiring the client to go through a 'report-all-with-xml-attributes' for everything and derive the current functionality. A client can lock the config and diff the various contents if they want to construct a tagged reply within the application. The point of the with-defaults capability is to let the client retrieve data with the defaults, instead of allowing the server to omit any leafs. If you don't want to support that functionality in your server, then don't implement this draft. > Thanks, > Kent > > > Andy From phil@juniper.net Wed May 5 16:31: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 0A2C03A6B1E for ; Wed, 5 May 2010 16:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.083 X-Spam-Level: X-Spam-Status: No, score=-6.083 tagged_above=-999 required=5 tests=[AWL=0.516, 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 OKpBomJhlDv9 for ; Wed, 5 May 2010 16:31:21 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 60E5F28C0F1 for ; Wed, 5 May 2010 16:31:18 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKS+H/uCCxhQdmd9Y8ysQ8KcFmauvjNJpv@postini.com; Wed, 05 May 2010 16:31:06 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Wed, 5 May 2010 16:30:20 -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); Wed, 5 May 2010 16:30:20 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 May 2010 16:30:20 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 May 2010 16:30:19 -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 o45NUID91730; Wed, 5 May 2010 16:30:18 -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 o45NDB9Q028400; Wed, 5 May 2010 23:13:11 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005052313.o45NDB9Q028400@idle.juniper.net> To: In-Reply-To: <4BE1FB03.7010004@iwl.com> Date: Wed, 5 May 2010 19:13:11 -0400 From: Phil Shafer X-OriginalArrivalTime: 05 May 2010 23:30:19.0810 (UTC) FILETIME=[ECFD5020:01CAECAA] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 23:31:22 -0000 Andy Bierman writes: >I don't see how you could possibly get the XML attribute tag >for a leaf that wasn't there (in the reply). You have to return >all the nodes in order to return their tags (that means report-all). Kent's suggestion is to flag default leafs with an attribute that makes it obvious that these are defaults, like: 830 This is meant to allow thin clients to know that a value is the default, not "real", and to allow servers to ignore incoming leafs that have this attribute, removing the risk that some app will try to load default-laden config. Thanks, Phil From andyb@iwl.com Wed May 5 17:29: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 8CF1D3A688D for ; Wed, 5 May 2010 17:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[AWL=-0.384, 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 7PO3XjNWrVA6 for ; Wed, 5 May 2010 17:29:50 -0700 (PDT) Received: from smtp194.dfw.emailsrvr.com (smtp194.dfw.emailsrvr.com [67.192.241.194]) by core3.amsl.com (Postfix) with ESMTP id D1F753A67DB for ; Wed, 5 May 2010 17:29:50 -0700 (PDT) Received: from relay9.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 9F5D813D3219; Wed, 5 May 2010 20:29:37 -0400 (EDT) Received: by relay9.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 52CDA13D315F; Wed, 5 May 2010 20:29:37 -0400 (EDT) Message-ID: <4BE20D78.9030204@iwl.com> Date: Wed, 05 May 2010 17:29:44 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201005052313.o45NDB9Q028400@idle.juniper.net> In-Reply-To: <201005052313.o45NDB9Q028400@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 06 May 2010 00:29:51 -0000 Phil Shafer wrote: > Andy Bierman writes: > >> I don't see how you could possibly get the XML attribute tag >> for a leaf that wasn't there (in the reply). You have to return >> all the nodes in order to return their tags (that means report-all). >> > > Kent's suggestion is to flag default leafs with an attribute > that makes it obvious that these are defaults, like: > > > > > 830 > > > > > This is meant to allow thin clients to know that a value > is the default, not "real", and to allow servers to ignore > incoming leafs that have this attribute, removing the risk > that some app will try to load default-laden config. > > I don't think anyone wanted to add this to the draft. The client can get-config(report-all) and check the YANG file to see which values happen to equal the YANG default value. The client can also retrieve report-all and then trim, and compare them. The nodes missing in the 2nd reply are the ones set to the YANG default. > Thanks, > Phil > > Andy From kwatsen@juniper.net Wed May 5 19:43: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 79FD33A6963 for ; Wed, 5 May 2010 19:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.803 X-Spam-Level: X-Spam-Status: No, score=-4.803 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_20=-0.74, 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 eHij2H8LsY5w for ; Wed, 5 May 2010 19:43:43 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 02C963A697F for ; Wed, 5 May 2010 19:43:36 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKS+Isy6i/udLTLJtb98mZV8Fsibm4M8Ab@postini.com; Wed, 05 May 2010 19:43:24 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 5 May 2010 19:43:05 -0700 From: Kent Watsen To: "'andyb@iwl.com'" Date: Wed, 5 May 2010 19:43:04 -0700 Thread-Topic: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt Thread-Index: AcrsszbR34TE53cuQ/qvyBKP+HEF6AADPpqw Message-ID: <84600D05C20FF943918238042D7670FD36C7D76364@EMBX01-HQ.jnpr.net> References: <201005052313.o45NDB9Q028400@idle.juniper.net> <4BE20D78.9030204@iwl.com> In-Reply-To: <4BE20D78.9030204@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 02:43:44 -0000 > I don't think anyone wanted to add this to the draft But this is what *I've* been asking for all along. Good grief, my very fir= st "with-defaults" email on 9/24/2009 was: "My primary comment is that, when using "report-all", the client has no way of knowing which values were explicitly set without also getting the "explicit" config, which would be a waste of bandwidth... A simple fix to this is to have "report-all" mark the default nodes with an attribute indicating just that. For instance: 1500 This approach not only resolves the issue mentioned above, but it also allows the output to be fed directly back into an operation without worries of the device creating a bunch of user- defined nodes in the config tree" > The client can get-config(report-all) and check the > YANG file to see which values happen > to equal the YANG default value. If the client is schema-aware, it won't ask for report-all in the first pla= ce. Again, see my April 5 email. > The client can also retrieve report-all and then trim, > and compare them. The nodes missing in the > 2nd reply are the ones set to the YANG default. A waste of bandwidth and still doesn't resolve the round-tripping concern Why not support tagging default values? Now that we've concluded that the = WG has never defined a concern for using attributes for metadata, what tech= nical issue is holding us back now? From lhotka@cesnet.cz Wed May 5 22:49: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 AD7323A6A34 for ; Wed, 5 May 2010 22:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.817 X-Spam-Level: X-Spam-Status: No, score=0.817 tagged_above=-999 required=5 tests=[AWL=-0.533, 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 zdwqLnl4qmZK for ; Wed, 5 May 2010 22:49:41 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D107A3A67D2 for ; Wed, 5 May 2010 22:49: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 5CBD52CDE057 for ; Thu, 6 May 2010 07:49:26 +0200 (CEST) From: Ladislav Lhotka To: netconf@ietf.org In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D7635F@EMBX01-HQ.jnpr.net> References: <201005051322.o45DMjof012941@idle.juniper.net> <1273068700.18014.33.camel@missotis> <84600D05C20FF943918238042D7670FD36C7D7635F@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 06 May 2010 07:49:25 +0200 Message-ID: <1273124965.26014.5.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 05:49:41 -0000 Kent Watsen píše v St 05. 05. 2010 v 15:38 -0700: > Lada writes: > > IMO the ability of the server to tell (at the very least) its way > > of handling defaults is a critical prerequisite for YANG. > > I agree that this part of the I-D is good; it's important servers > define their basic-mode so clients know how to interoperate with them > So how about moving the "basic-mode" announcement to RFC 4741bis and dealing with "also-supported" and the modifications to the existing operations in a separate document? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Wed May 5 23:20: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 323C83A69E2 for ; Wed, 5 May 2010 23:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.19 X-Spam-Level: X-Spam-Status: No, score=0.19 tagged_above=-999 required=5 tests=[AWL=-0.364, 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 HgeWyvSzkCay for ; Wed, 5 May 2010 23:20:57 -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 31FC33A69D7 for ; Wed, 5 May 2010 23:20:55 -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 DAC39616001; Thu, 6 May 2010 08:20:38 +0200 (CEST) Date: Thu, 06 May 2010 08:20:38 +0200 (CEST) Message-Id: <20100506.082038.132336496.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201005041819.o44IJb5J050139@idle.juniper.net> References: <20100504174139.GA5737@elstar.local> <201005041819.o44IJb5J050139@idle.juniper.net> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: [Netconf] Access Control Motivation (Was: AD review of draft-ietf-netconf-monitoring-12) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 06 May 2010 06:20:59 -0000 Hi, Phil Shafer wrote: > For example, if you want the client to back up your configuration, > you need to give them full read-only access to the configuration. > If the app is making VPNs, they need write access to all the > appropriate configuration. If there's a leaf in the VPN config > that the admin does not want the app to turn on, then it doesn't > need write access to that. What the admin wants to app to do > will dictate the permissions required by that app. Here you argue why it is important to be able to configure access control, but then your conclusion is that we don't need a standard data model to do this? Do you think that it is _better_ with proprietary data models for access control? If so, why is access control special, why do we need standard data models at all? > In short, the issue of access control is orthogonal to the needs > of the specific client application. Either the app can to the work > it needs to do or it cannot. One doesn't expect to have an application > auto-provision the user that it's going to use to login, right? No, just as we don't expect the NETCONF client to set up the initial mgmt interface so we can talk NETCONF to the box. But once the basic interface is there, we do expect NETCONF clients to configure other interfaces and protocol. Same for access control. > Is the value of the ACM to report when something is not configured > correctly? > > So the question becomes if you build the all-singing all-dancing > access control solution, what is the target use case? The VPN > config app? The admin that's setting up the VPN config app? Is > there any realistic chance of displacing the CLI as the main avenue > for configuring users and permissions? > > Is this a problem domain that we feel will convince people that > NETCONF and YANG are the keys to addressing their configuration > needs? Are ISPs dying to configure user permissions in an > automated way, especially given their use of RADIUS, etc? There is no std way to do NETCONF access control (as in checking data rules) for RADIUS. I think you have some vendor-specific way to handle this, so maybe you should publish that in order to solve this problem. /martin From mbj@tail-f.com Thu May 6 00:09: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 D17823A6A09 for ; Thu, 6 May 2010 00:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.205 X-Spam-Level: X-Spam-Status: No, score=0.205 tagged_above=-999 required=5 tests=[AWL=-0.349, 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 7+83H+c4XpZy for ; Thu, 6 May 2010 00:09: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 A572C28C0F4 for ; Thu, 6 May 2010 00:09:36 -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 04A2D616001; Thu, 6 May 2010 09:09:23 +0200 (CEST) Date: Thu, 06 May 2010 09:09:22 +0200 (CEST) Message-Id: <20100506.090922.229777636.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D76364@EMBX01-HQ.jnpr.net> References: <201005052313.o45NDB9Q028400@idle.juniper.net> <4BE20D78.9030204@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76364@EMBX01-HQ.jnpr.net> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 07:09:51 -0000 Hi, Kent Watsen wrote: > > > > I don't think anyone wanted to add this to the draft > > But this is what *I've* been asking for all along. Good grief, my > very first "with-defaults" email on 9/24/2009 was: > > "My primary comment is that, when using "report-all", the client > has no way of knowing which values were explicitly set without > also getting the "explicit" config, which would be a waste of > bandwidth... > > A simple fix to this is to have "report-all" mark the default > nodes with an attribute indicating just that. For instance: > > 1500 I agree that this seems useful. I.e., if the client asks for "report-all", the server MAY add a wd:is-default attribute. The reason for the MAY is that a server that has report-all as basic-mode typically can't do this, so it is useful for explicit and trim servers only. > This approach not only resolves the issue mentioned above, but it > also allows the output to be fed directly back into an > operation without worries of the device creating a bunch of user- > defined nodes in the config tree" But this part has bigger impact on existing code, and probably needs more thought, esp. how it interacts with edit-config default-operation and operation attribute. Take Phil's example: 830 What's really in the db might be just . If you send this back in an edit-config, you might use default-operation replace. But this will (may) create the services and netconf nodes even though they were not there in the original db. One argument against sending data-model info in the reply was that it is a slippery slope; why not also send the type of each leaf? why not indicate which leafs are keys? etc. But in this case the operation (report-all) explicitly asks the server to add nodes based on whether they are defaults or not, so it makes sense to let the server mark those nodes so the client knows which they are. /martin From andyb@iwl.com Thu May 6 00:49: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 B174B3A6AF0 for ; Thu, 6 May 2010 00:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=-0.821, 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 uy7IVkVboTnd for ; Thu, 6 May 2010 00:49:17 -0700 (PDT) Received: from smtp114.iad.emailsrvr.com (smtp114.iad.emailsrvr.com [207.97.245.114]) by core3.amsl.com (Postfix) with ESMTP id A9F3E3A6952 for ; Thu, 6 May 2010 00:49:17 -0700 (PDT) Received: from relay21.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay21.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 20C351B516A; Thu, 6 May 2010 03:49:04 -0400 (EDT) Received: by relay21.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id B35B61B5167; Thu, 6 May 2010 03:49:03 -0400 (EDT) Message-ID: <4BE27477.2030009@iwl.com> Date: Thu, 06 May 2010 00:49:11 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Bjorklund References: <201005052313.o45NDB9Q028400@idle.juniper.net> <4BE20D78.9030204@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76364@EMBX01-HQ.jnpr.net> <20100506.090922.229777636.mbj@tail-f.com> In-Reply-To: <20100506.090922.229777636.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 06 May 2010 07:49:18 -0000 Martin Bjorklund wrote: > Hi, > > Kent Watsen wrote: > >> >>> I don't think anyone wanted to add this to the draft >>> >> But this is what *I've* been asking for all along. Good grief, my >> very first "with-defaults" email on 9/24/2009 was: >> >> "My primary comment is that, when using "report-all", the client >> has no way of knowing which values were explicitly set without >> also getting the "explicit" config, which would be a waste of >> bandwidth... >> >> A simple fix to this is to have "report-all" mark the default >> nodes with an attribute indicating just that. For instance: >> >> 1500 >> > > I agree that this seems useful. I.e., if the client asks for > "report-all", the server MAY add a wd:is-default attribute. The > reason for the MAY is that a server that has report-all as basic-mode > typically can't do this, so it is useful for explicit and trim servers > only. > > So the client cannot rely on it being available in all servers. Sounds useless to me. >> This approach not only resolves the issue mentioned above, but it >> also allows the output to be fed directly back into an >> operation without worries of the device creating a bunch of user- >> defined nodes in the config tree" >> > > Nonsense. This meta-data tagging breaks a fundamental property of NETCONF -- the ability to use output as the input to an or operation. The client must strip out all the XML attributes first, because they will be rejected as 'unknown attributes' during validation. > But this part has bigger impact on existing code, and probably needs > more thought, esp. how it interacts with edit-config default-operation > and operation attribute. Take Phil's example: > > > > > 830 > > > > > What's really in the db might be just . > > If you send this back in an edit-config, you might use > default-operation replace. But this will (may) create the services > and netconf nodes even though they were not there in the original db. > > > One argument against sending data-model info in the reply was that it > is a slippery slope; why not also send the type of each leaf? why not > indicate which leafs are keys? etc. But in this case the operation > (report-all) explicitly asks the server to add nodes based on whether > they are defaults or not, so it makes sense to let the server mark > those nodes so the client knows which they are. > > I do not understand this 'thin client' argument. It seems pointless to me to tag the NETCONF return data with YANG meta-data, just because some application is too lazy to use YANG -- they want to use the meta version of YANG instead, encoded inline. Why not tag all the other meta-data? Why stop at the default-stmt value? What is so special about knowing the value equals the schema default? > /martin > > Andy From mbj@tail-f.com Thu May 6 00:58: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 857103A685B for ; Thu, 6 May 2010 00:58:03 -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.334, 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 2ezKRnJnwmD6 for ; Thu, 6 May 2010 00:58: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 7615A3A67AD for ; Thu, 6 May 2010 00:58:02 -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 1ED82616001; Thu, 6 May 2010 09:57:48 +0200 (CEST) Date: Thu, 06 May 2010 09:57:47 +0200 (CEST) Message-Id: <20100506.095747.207776849.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4BE27477.2030009@iwl.com> References: <84600D05C20FF943918238042D7670FD36C7D76364@EMBX01-HQ.jnpr.net> <20100506.090922.229777636.mbj@tail-f.com> <4BE27477.2030009@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 07:58:03 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi, > > > > Kent Watsen wrote: > > > >> > >>> I don't think anyone wanted to add this to the draft > >>> > >> But this is what *I've* been asking for all along. Good grief, my > >> very first "with-defaults" email on 9/24/2009 was: > >> > >> "My primary comment is that, when using "report-all", the client > >> has no way of knowing which values were explicitly set without > >> also getting the "explicit" config, which would be a waste of > >> bandwidth... > >> > >> A simple fix to this is to have "report-all" mark the default > >> nodes with an attribute indicating just that. For instance: > >> > >> 1500 > >> > > > > I agree that this seems useful. I.e., if the client asks for > > "report-all", the server MAY add a wd:is-default attribute. The > > reason for the MAY is that a server that has report-all as basic-mode > > typically can't do this, so it is useful for explicit and trim servers > > only. > > > > > > So the client cannot rely on it being available in all servers. > Sounds useless to me. It's not useless, since it always allows a client to take the output of a report-all get-config and feed it back into an edit-config. > >> This approach not only resolves the issue mentioned above, but it > >> also allows the output to be fed directly back into an > >> operation without worries of the device creating a bunch of user- > >> defined nodes in the config tree" > >> > > > > > > Nonsense. > > This meta-data tagging breaks a fundamental property > of NETCONF -- the ability to use output > as the input to an or operation. > > The client must strip out all the XML attributes first, > because they will be rejected as 'unknown attributes' > during validation. Well, if we did this, this draft would modify edit-config / copy-config to allow the wd:is-default attribute in the data. So a server that conforms to this spec must understand this new attribute. > I do not understand this 'thin client' argument. > It seems pointless to me to tag the NETCONF return data > with YANG meta-data, just because some application is > too lazy to use YANG -- they want to use the meta version > of YANG instead, encoded inline. Why not tag all the > other meta-data? Why stop at the default-stmt value? > What is so special about knowing the value equals the > schema default? The thin client argument is the reason for having report-all in the first place. If that argument is invalid, I agree with Kent that report-all should not be mandatory. If so, this draft should just define the basic-mode advertisment, and not add the with-defaults parameter. /martin From andyb@iwl.com Thu May 6 01:45: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 9F5313A6839 for ; Thu, 6 May 2010 01:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=-0.685, 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 OJ5bPSBQeuN8 for ; Thu, 6 May 2010 01:45:40 -0700 (PDT) Received: from smtp184.iad.emailsrvr.com (smtp184.iad.emailsrvr.com [207.97.245.184]) by core3.amsl.com (Postfix) with ESMTP id 9B4633A6783 for ; Thu, 6 May 2010 01:45:40 -0700 (PDT) Received: from relay28.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay28.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 764C01B413C; Thu, 6 May 2010 04:45:27 -0400 (EDT) Received: by relay28.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id F07491B412D; Thu, 6 May 2010 04:45:26 -0400 (EDT) Message-ID: <4BE281AE.1030807@iwl.com> Date: Thu, 06 May 2010 01:45:34 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Bjorklund References: <84600D05C20FF943918238042D7670FD36C7D76364@EMBX01-HQ.jnpr.net> <20100506.090922.229777636.mbj@tail-f.com> <4BE27477.2030009@iwl.com> <20100506.095747.207776849.mbj@tail-f.com> In-Reply-To: <20100506.095747.207776849.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 06 May 2010 08:45:41 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: > >> Martin Bjorklund wrote: >> >>> Hi, >>> >>> Kent Watsen wrote: >>> >>> >>>> >>>> >>>>> I don't think anyone wanted to add this to the draft >>>>> >>>>> >>>> But this is what *I've* been asking for all along. Good grief, my >>>> very first "with-defaults" email on 9/24/2009 was: >>>> >>>> "My primary comment is that, when using "report-all", the client >>>> has no way of knowing which values were explicitly set without >>>> also getting the "explicit" config, which would be a waste of >>>> bandwidth... >>>> >>>> A simple fix to this is to have "report-all" mark the default >>>> nodes with an attribute indicating just that. For instance: >>>> >>>> 1500 >>>> >>>> >>> I agree that this seems useful. I.e., if the client asks for >>> "report-all", the server MAY add a wd:is-default attribute. The >>> reason for the MAY is that a server that has report-all as basic-mode >>> typically can't do this, so it is useful for explicit and trim servers >>> only. >>> >>> >>> >> So the client cannot rely on it being available in all servers. >> Sounds useless to me. >> > > It's not useless, since it always allows a client to take the output > of a report-all get-config and feed it back into an edit-config. > > >>>> This approach not only resolves the issue mentioned above, but it >>>> also allows the output to be fed directly back into an >>>> operation without worries of the device creating a bunch of user- >>>> defined nodes in the config tree" >>>> >>>> >>> >>> >> Nonsense. >> >> This meta-data tagging breaks a fundamental property >> of NETCONF -- the ability to use output >> as the input to an or operation. >> >> The client must strip out all the XML attributes first, >> because they will be rejected as 'unknown attributes' >> during validation. >> > > Well, if we did this, this draft would modify edit-config / > copy-config to allow the wd:is-default attribute in the data. So a > server that conforms to this spec must understand this new attribute. > > >> I do not understand this 'thin client' argument. >> It seems pointless to me to tag the NETCONF return data >> with YANG meta-data, just because some application is >> too lazy to use YANG -- they want to use the meta version >> of YANG instead, encoded inline. Why not tag all the >> other meta-data? Why stop at the default-stmt value? >> What is so special about knowing the value equals the >> schema default? >> > > The thin client argument is the reason for having report-all in the > first place. If that argument is invalid, I agree with Kent that > report-all should not be mandatory. If so, this draft should just > define the basic-mode advertisment, and not add the with-defaults > parameter. > > > There are lots of ways that the can be ambiguous, even for an application that understands YANG. That is the reason report-all is needed. It has nothing to do with thin clients vs. smart clients. I do not understand this use-case at all. We have had dumb MIB walker programs for 25 years. Nobody ever asked for a dumb MIB walker that indicated which varbinds were equal to the schema default. What operational problem is solved by hacking the NETCONF protocol to support an XML attribute indicating that a node equals its schema-default-value? What operator problem is solved by knowing this information? > /martin > > Andy From phil@juniper.net Thu May 6 07:21: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 DE96E28C27B for ; Thu, 6 May 2010 07:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.247 X-Spam-Level: X-Spam-Status: No, score=-5.247 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_20=-0.74, 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 w2EeVnJyStae for ; Thu, 6 May 2010 07:21:44 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 17ED328C3F9 for ; Thu, 6 May 2010 06:58:07 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKS+LK3utSFZyPHNsM2DMTXjwkVHLtdPk8@postini.com; Thu, 06 May 2010 06:57:55 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Thu, 6 May 2010 06:53:55 -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); Thu, 6 May 2010 06:53:55 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 06:53:55 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 May 2010 06:53:54 -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 o46DrrD71488; Thu, 6 May 2010 06:53:54 -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 o46DakPe050971; Thu, 6 May 2010 13:36:46 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005061336.o46DakPe050971@idle.juniper.net> To: In-Reply-To: <4BE27477.2030009@iwl.com> Date: Thu, 6 May 2010 09:36:46 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2010 13:53:54.0675 (UTC) FILETIME=[910E4430:01CAED23] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 14:21:46 -0000 Andy Bierman writes: >So the client cannot rely on it being available in all servers. >Sounds useless to me. Your definition of "useless" as "available in all servers" stands in conflict with our extensible, capabilitity-based, feature-friendly architecture. We allow higher-level clients to take advantage of higher-level servers to provide a world that rich enough to complex app and simple enough for trivial ones. We've abandoned the "one size fits all" world view for a more adjustable, real-world one. So if the server doesn't send you this new attribute, then your client is stuck not knowing if the settings are intentional or default values, which it the same way it would work without this new attribute. You aren't losing anything but by allowing smarter clients to deal more intelligently with servers that support this attribute, you allow them to get better insight into what's real and what are defaults. Thanks, Phil From phil@juniper.net Thu May 6 07:30: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 6831428C258 for ; Thu, 6 May 2010 07:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.39 X-Spam-Level: X-Spam-Status: No, score=-5.39 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_05=-1.11, 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 4Km-4jFXX1OM for ; Thu, 6 May 2010 07:30:08 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 2832128C354 for ; Thu, 6 May 2010 07:04:55 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKS+LMd37jIDG9SZZJJTyAQRVWRxUUgTqc@postini.com; Thu, 06 May 2010 07:04:42 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Thu, 6 May 2010 06:58:36 -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); Thu, 6 May 2010 06:58:36 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 06:58:35 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 May 2010 06:58: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 o46DwYD75801; Thu, 6 May 2010 06:58: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 o46DfQCS051020; Thu, 6 May 2010 13:41:26 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005061341.o46DfQCS051020@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20100506.090922.229777636.mbj@tail-f.com> Date: Thu, 6 May 2010 09:41:26 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2010 13:58:35.0296 (UTC) FILETIME=[3851A200:01CAED24] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 14:30:12 -0000 Martin Bjorklund writes: > > > > 830 > > > > >What's really in the db might be just . > >If you send this back in an edit-config, you might use >default-operation replace. But this will (may) create the services >and netconf nodes even though they were not there in the original db. It is a presence container (which it is, since it turns on the netconf protocol), its appearance is supposed to create the netconf node. If is a non-presence container (which it is, since it just holds the set of supported services), its appearance carried no information, so the server can create that node or not, as allowed by the normal YANG operations. >One argument against sending data-model info in the reply was that it >is a slippery slope; why not also send the type of each leaf? why not >indicate which leafs are keys? etc. But in this case the operation >(report-all) explicitly asks the server to add nodes based on whether >they are defaults or not, so it makes sense to let the server mark >those nodes so the client knows which they are. I agree on the slippery slope, but I think that mixing default values into "real" config values is a much more slippery one. This new attribute would help folks that want to venture onto that slope have better footing. Thanks, Phil From phil@juniper.net Thu May 6 07:47: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 3F55128C224 for ; Thu, 6 May 2010 07:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.813 X-Spam-Level: X-Spam-Status: No, score=-4.813 tagged_above=-999 required=5 tests=[AWL=-0.814, 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 tYuCp2Te-etC for ; Thu, 6 May 2010 07:47:40 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 7552528C48A for ; Thu, 6 May 2010 07:26:05 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKS+LRaoFYRZGPgc2dQm/etrSGXlIT9Z40@postini.com; Thu, 06 May 2010 07:25:53 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Thu, 6 May 2010 07:14:54 -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); Thu, 6 May 2010 07:14:54 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 07:14:53 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 May 2010 07:14:53 -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 o46EErD91897; Thu, 6 May 2010 07:14:53 -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 o46DvjQ4051220; Thu, 6 May 2010 13:57:45 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005061357.o46DvjQ4051220@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20100506.082038.132336496.mbj@tail-f.com> Date: Thu, 6 May 2010 09:57:45 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2010 14:14:53.0971 (UTC) FILETIME=[7FA79630:01CAED26] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Access Control Motivation (Was: AD review of draft-ietf-netconf-monitoring-12) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 06 May 2010 14:47:41 -0000 Martin Bjorklund writes: >Here you argue why it is important to be able to configure access >control, but then your conclusion is that we don't need a standard >data model to do this? Do you think that it is _better_ with >proprietary data models for access control? If so, why is access >control special, why do we need standard data models at all? If you look at this from the service providers point of view, access control is a solved problem, with lots of existing any deployed infrastructure. SPs are comfortable managing users and permissions in the CLI world, so just saying "a user can't do anything via the API that they can't do via the CLI" makes them comfortable and happy. Telling them we are going to go make a yet another "better" ACM does not. In the same way we chose ssh as a transport in order to piggy-back on the existing and deployed infrastructure, we should be expecting NETCONF servers to take advantage of the existing and deployed access control infrastructure. If the first thing a potential NETCONF user has to do is understand our custom ACM, this makes a barrier to entry that won't be easily vaulted. I know ACM and user management is a safe, familiar problem domain for network management work, but it's not the problem domain that will make people go "I gotta have that". I'd rather we put our cycles into areas that will make people start to salivate over NETCONF/YANG solutions. I want to model how VPNs work, or how a network of OSPF routers work. I want a standard model here to that my VPN provisioning application or my OSPF sanity checker can use my models to talk to every VPN endpoint or every OSPF router. I don't see the value in an application that configures NETCONF access control. I don't understand when I would use it, who I would sell it to, or when they would need it. I don't see a world where this happens without the CLI and I don't see much value in making a "shadow world" of what already exists in the CLI. Thanks, Phil From phil@juniper.net Thu May 6 07:48:05 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 E7C9A28C307 for ; Thu, 6 May 2010 07:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.055 X-Spam-Level: X-Spam-Status: No, score=-6.055 tagged_above=-999 required=5 tests=[AWL=0.544, 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 P-5STmcfrhvn for ; Thu, 6 May 2010 07:48:04 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id CC1BB3A6C09 for ; Thu, 6 May 2010 07:26:28 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKS+LRhpV01OaXB4rVpHURvZf8NZKj6Hnh@postini.com; Thu, 06 May 2010 07:26:16 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Thu, 6 May 2010 07:16:03 -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); Thu, 6 May 2010 07:16:03 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 07:16:02 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 May 2010 07:16:02 -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 o46EG1D92683; Thu, 6 May 2010 07:16:01 -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 o46Dwri2051236; Thu, 6 May 2010 13:58:53 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005061358.o46Dwri2051236@idle.juniper.net> To: Ladislav Lhotka Date: Thu, 6 May 2010 09:58:53 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2010 14:16:02.0252 (UTC) FILETIME=[A85A70C0:01CAED26] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 14:48:06 -0000 Ladislav Lhotka writes: >So how about moving the "basic-mode" announcement to RFC 4741bis and >dealing with "also-supported" and the modifications to the existing >operations in a separate document? I don't see this as fitting in the "bugs and clarifications" charter. Thanks, Phil From lhotka@cesnet.cz Thu May 6 07:52: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 2B7643A6CE0 for ; Thu, 6 May 2010 07:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.76 X-Spam-Level: X-Spam-Status: No, score=0.76 tagged_above=-999 required=5 tests=[AWL=-0.404, 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 nzHpN1tHxnrw for ; Thu, 6 May 2010 07:52:36 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 70A0C28C355 for ; Thu, 6 May 2010 07:30:29 -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 A74E02CDE058; Thu, 6 May 2010 16:30:15 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <201005061358.o46Dwri2051236@idle.juniper.net> References: <201005061358.o46Dwri2051236@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 06 May 2010 16:30:13 +0200 Message-ID: <1273156213.26014.183.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 14:52:42 -0000 Phil Shafer píše v Čt 06. 05. 2010 v 09:58 -0400: > Ladislav Lhotka writes: > >So how about moving the "basic-mode" announcement to RFC 4741bis and > >dealing with "also-supported" and the modifications to the existing > >operations in a separate document? > > I don't see this as fitting in the "bugs and clarifications" charter. But what's the alternative? Will an implementation be considered 4741bis-compliant if it entirely ignores with-defaults without stating a compelling reason? Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Thu May 6 08:51: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 3AAA73A6DAC for ; Thu, 6 May 2010 08:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[AWL=-0.331, 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 OtBcRjb9RQAG for ; Thu, 6 May 2010 08:51:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A669428C308 for ; Thu, 6 May 2010 08:38:59 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9D2DAC000C; Thu, 6 May 2010 17:38:46 +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 mIy0eCJ0niYZ; Thu, 6 May 2010 17:38:45 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 85DC1C003F; Thu, 6 May 2010 17:38:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6D67511F39A8; Thu, 6 May 2010 17:38:44 +0200 (CEST) Date: Thu, 6 May 2010 17:38:43 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20100506153843.GA1824@elstar.local> Mail-Followup-To: Phil Shafer , Ladislav Lhotka , "netconf@ietf.org" References: <201005061358.o46Dwri2051236@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005061358.o46Dwri2051236@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.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: Thu, 06 May 2010 15:51:52 -0000 On Thu, May 06, 2010 at 03:58:53PM +0200, Phil Shafer wrote: > Ladislav Lhotka writes: > >So how about moving the "basic-mode" announcement to RFC 4741bis and > >dealing with "also-supported" and the modifications to the existing > >operations in a separate document? > > I don't see this as fitting in the "bugs and clarifications" charter. With 4741, your client does not know what the defaults handling mode of a server is. I consider this a bug. Lada's suggestion removes the fuzziness we have, which I think is a good thing. And you usually like to have precise semantics. /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 May 6 08:55: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 C968A3A6BB7 for ; Thu, 6 May 2010 08:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.963 X-Spam-Level: X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=-0.557, 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 vMPS7hvEbYiG for ; Thu, 6 May 2010 08:55:27 -0700 (PDT) Received: from smtp164.dfw.emailsrvr.com (smtp164.dfw.emailsrvr.com [67.192.241.164]) by core3.amsl.com (Postfix) with ESMTP id B0A913A67F8 for ; Thu, 6 May 2010 08:44:40 -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 AF4D6103F8; Thu, 6 May 2010 11:44:27 -0400 (EDT) Received: by relay16.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 71A29103ED; Thu, 6 May 2010 11:44:27 -0400 (EDT) Message-ID: <4BE2E3E1.4050201@iwl.com> Date: Thu, 06 May 2010 08:44:33 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201005061336.o46DakPe050971@idle.juniper.net> In-Reply-To: <201005061336.o46DakPe050971@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 06 May 2010 15:55:27 -0000 Phil Shafer wrote: > Andy Bierman writes: > >> So the client cannot rely on it being available in all servers. >> Sounds useless to me. >> > > Your definition of "useless" as "available in all servers" stands > in conflict with our extensible, capabilitity-based, feature-friendly > architecture. We allow higher-level clients to take advantage of > higher-level servers to provide a world that rich enough to complex > app and simple enough for trivial ones. We've abandoned the "one > size fits all" world view for a more adjustable, real-world one. > > So if the server doesn't send you this new attribute, then your > client is stuck not knowing if the settings are intentional or > default values, which it the same way it would work without this > new attribute. You aren't losing anything but by allowing smarter > clients to deal more intelligently with servers that support this > attribute, you allow them to get better insight into what's real > and what are defaults. > > What operator problem is solved by this solution proposal? > Thanks, > Phil > > Andy From andyb@iwl.com Thu May 6 09:14: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 CC1423A6BA5 for ; Thu, 6 May 2010 09:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.042 X-Spam-Level: X-Spam-Status: No, score=-3.042 tagged_above=-999 required=5 tests=[AWL=0.557, 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 5Dz4Wqbx5q4N for ; Thu, 6 May 2010 09:14:36 -0700 (PDT) Received: from smtp134.iad.emailsrvr.com (smtp134.iad.emailsrvr.com [207.97.245.134]) by core3.amsl.com (Postfix) with ESMTP id 756A428C0FD for ; Thu, 6 May 2010 09:11:28 -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 29BF444C4C8; Thu, 6 May 2010 12:11:13 -0400 (EDT) Received: by relay3.r3.iad.emailsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 502D644C4C2; Thu, 6 May 2010 12:11:12 -0400 (EDT) Message-ID: <4BE2EA25.8030501@iwl.com> Date: Thu, 06 May 2010 09:11:17 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer , Ladislav Lhotka , "netconf@ietf.org" References: <201005061358.o46Dwri2051236@idle.juniper.net> <20100506153843.GA1824@elstar.local> In-Reply-To: <20100506153843.GA1824@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.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, 06 May 2010 16:14:38 -0000 Juergen Schoenwaelder wrote: > On Thu, May 06, 2010 at 03:58:53PM +0200, Phil Shafer wrote: > >> Ladislav Lhotka writes: >> >>> So how about moving the "basic-mode" announcement to RFC 4741bis and >>> dealing with "also-supported" and the modifications to the existing >>> operations in a separate document? >>> >> I don't see this as fitting in the "bugs and clarifications" charter. >> > > With 4741, your client does not know what the defaults handling mode > of a server is. I consider this a bug. Lada's suggestion removes the > fuzziness we have, which I think is a good thing. And you usually like > to have precise semantics. > > The RFC that contains with-defaults is not important. The conformance already says SHOULD implement. Even if we were on schedule, rearranging the deliverables would be a super-low priority. But since we are collectively years behind schedule, it seems like a really bad idea. Whether a server advertises :with-defaults or not has nothing to do with which RFC contains the text. IMO, report-all needs to be mandatory because every server can support it. No matter what defaults mode is used, every implementation of every NETCONF server knows the difference between its own default and a non-default, and knows its own total set of leafs. > /js > > Andy From andyb@iwl.com Thu May 6 09:55: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 3CC0F3A698E for ; Thu, 6 May 2010 09:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.069 X-Spam-Level: X-Spam-Status: No, score=-3.069 tagged_above=-999 required=5 tests=[AWL=0.530, 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 k34A3DbpE3B1 for ; Thu, 6 May 2010 09:55:56 -0700 (PDT) Received: from smtp114.iad.emailsrvr.com (smtp114.iad.emailsrvr.com [207.97.245.114]) by core3.amsl.com (Postfix) with ESMTP id 81FE03A6919 for ; Thu, 6 May 2010 09:55:56 -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 64D371B429F; Thu, 6 May 2010 12:55:43 -0400 (EDT) Received: by relay31.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 05CFB1B4009; Thu, 6 May 2010 12:55:42 -0400 (EDT) Message-ID: <4BE2F496.8010704@iwl.com> Date: Thu, 06 May 2010 09:55:50 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Ladislav Lhotka References: <201005061358.o46Dwri2051236@idle.juniper.net> <1273156213.26014.183.camel@missotis> In-Reply-To: <1273156213.26014.183.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.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, 06 May 2010 16:55:57 -0000 Ladislav Lhotka wrote: > Phil Shafer píše v Čt 06. 05. 2010 v 09:58 -0400: > >> Ladislav Lhotka writes: >> >>> So how about moving the "basic-mode" announcement to RFC 4741bis and >>> dealing with "also-supported" and the modifications to the existing >>> operations in a separate document? >>> >> I don't see this as fitting in the "bugs and clarifications" charter. >> > > But what's the alternative? Will an implementation be considered > 4741bis-compliant if it entirely ignores with-defaults without stating a > compelling reason? > > It means that the server vendor does not think its customers need that functionality. The current solution is already decoupled to allow what you want. Only normative text stands in the way. If the server does not advertise the YANG module, then a client won't use that module. Since the :with-defaults capability is separate, a server could advertise just that URI to announce its basic-mode. Summary of changes: - change RFC conformance from SHOULD to MUST implement - make advertisement of :with-defaults basic-mode MUST implement - make implementation of report-all SHOULD implement - make implementation of the YANG module SHOULD implement IMO, this addresses your concerns without rearranging any drafts, and without changing the SHOULD conformance we already had in place for everything but basic-mode. > Lada > > Andy From kwatsen@juniper.net Thu May 6 10:25: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 67C553A67F6 for ; Thu, 6 May 2010 10:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[AWL=0.882, 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 eT8tBv3DQzcy for ; Thu, 6 May 2010 10:25:28 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 9A32D28C1C1 for ; Thu, 6 May 2010 10:22:25 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKS+L6wvuSwktV12NkFDlxYdeehUqfsH3X@postini.com; Thu, 06 May 2010 10:22:13 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 6 May 2010 10:19:59 -0700 From: Kent Watsen To: "'andyb@iwl.com'" , Phil Shafer , Ladislav Lhotka , "netconf@ietf.org" Date: Thu, 6 May 2010 10:19:58 -0700 Thread-Topic: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.txt Thread-Index: AcrtNzqznevZVIOyQFmZhqfwy/8AKgACE3Ew Message-ID: <84600D05C20FF943918238042D7670FD36C7D7636A@EMBX01-HQ.jnpr.net> References: <201005061358.o46Dwri2051236@idle.juniper.net> <20100506153843.GA1824@elstar.local> <4BE2EA25.8030501@iwl.com> In-Reply-To: <4BE2EA25.8030501@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 17:25:29 -0000 > IMO, report-all needs to be mandatory because every server > can support it. No matter what defaults mode is used, > every implementation of every NETCONF server > knows the difference between its own default and a non-default, > and knows its own total set of leafs. I'm OK with a mandatory report-all if, and only if, tagging defaults is all= owed K. From andyb@iwl.com Thu May 6 10:40: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 05F503A6912 for ; Thu, 6 May 2010 10:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=-0.541, 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 PYJSDupsGjkT for ; Thu, 6 May 2010 10:40:28 -0700 (PDT) Received: from smtp124.dfw.emailsrvr.com (smtp124.dfw.emailsrvr.com [67.192.241.124]) by core3.amsl.com (Postfix) with ESMTP id D42983A6A35 for ; Thu, 6 May 2010 10:40:23 -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 C6A552080CC8; Thu, 6 May 2010 13:40:10 -0400 (EDT) Received: by relay12.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 7BC142081421; Thu, 6 May 2010 13:40:10 -0400 (EDT) Message-ID: <4BE2FF01.7010400@iwl.com> Date: Thu, 06 May 2010 10:40:17 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <201005061358.o46Dwri2051236@idle.juniper.net> <20100506153843.GA1824@elstar.local> <4BE2EA25.8030501@iwl.com> <84600D05C20FF943918238042D7670FD36C7D7636A@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D7636A@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.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, 06 May 2010 17:40:29 -0000 Kent Watsen wrote: > >> IMO, report-all needs to be mandatory because every server >> can support it. No matter what defaults mode is used, >> every implementation of every NETCONF server >> knows the difference between its own default and a non-default, >> and knows its own total set of leafs. >> > > I'm OK with a mandatory report-all if, and only if, tagging defaults is allowed > > You haven't explained why operators need this meta-data added to the payload and lowering the bandwidth utilization. It seems to me an operator would rather have other meta-data from the YANG module, such as the description-stmt. I understand the dumb MIB walker / thin client argument. These have utility and have existed in SNMP for decades. These tools display the identity and value of each object. I don't understand the problem that the wd:default="true" data solves. My proposal was addressing Lada's legitimate concern, which has nothing to do with tagging the defaults. It is not hard for the server to advertise its default basic-mode, and this could help clients optimize code and better utilize the results of get/copy operations. > K. > > > Andy From j.schoenwaelder@jacobs-university.de Thu May 6 10:58: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 051873A6B9D for ; Thu, 6 May 2010 10:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.067 X-Spam-Level: X-Spam-Status: No, score=-0.067 tagged_above=-999 required=5 tests=[AWL=-0.232, 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 dWFgMVWahM6D for ; Thu, 6 May 2010 10:58:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 11B6E3A6A15 for ; Thu, 6 May 2010 10:58:39 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0C8C8C0144; Thu, 6 May 2010 19:58:26 +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 AFBjckZByRvr; Thu, 6 May 2010 19:58:25 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BEC1DC0167; Thu, 6 May 2010 19:58:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 190BD11F40B6; Thu, 6 May 2010 19:58:22 +0200 (CEST) Date: Thu, 6 May 2010 19:58:22 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100506175822.GA2657@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , "netconf@ietf.org" References: <201005061358.o46Dwri2051236@idle.juniper.net> <1273156213.26014.183.camel@missotis> <4BE2F496.8010704@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BE2F496.8010704@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.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: Thu, 06 May 2010 17:58:40 -0000 On Thu, May 06, 2010 at 06:55:50PM +0200, Andy Bierman wrote: > Ladislav Lhotka wrote: > > Phil Shafer p????e v ??t 06. 05. 2010 v 09:58 -0400: > > > >> Ladislav Lhotka writes: > >> > >>> So how about moving the "basic-mode" announcement to RFC 4741bis and > >>> dealing with "also-supported" and the modifications to the existing > >>> operations in a separate document? > >>> > >> I don't see this as fitting in the "bugs and clarifications" charter. > >> > > > > But what's the alternative? Will an implementation be considered > > 4741bis-compliant if it entirely ignores with-defaults without stating a > > compelling reason? > > > > > > It means that the server vendor does not think its > customers need that functionality. > > The current solution is already decoupled to allow what you want. > Only normative text stands in the way. > > If the server does not advertise the YANG module, > then a client won't use that module. Since the :with-defaults capability > is separate, a server could advertise just that URI to announce > its basic-mode. > > Summary of changes: > - change RFC conformance from SHOULD to MUST implement > - make advertisement of :with-defaults basic-mode MUST implement > - make implementation of report-all SHOULD implement > - make implementation of the YANG module SHOULD implement > > IMO, this addresses your concerns without rearranging any drafts, > and without changing the SHOULD conformance we already had > in place for everything but basic-mode. For what it is worth, I believe the announcement how defaults are handled should be part of 4741bis. Knowing how defaults are handled by a server is crucial for using NETCONF and the announcement itself really is not a big deal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Thu May 6 10:59: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 417BE3A6BF4 for ; Thu, 6 May 2010 10:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.091 X-Spam-Level: X-Spam-Status: No, score=-6.091 tagged_above=-999 required=5 tests=[AWL=0.508, 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 cGjmrgkwmWyG for ; Thu, 6 May 2010 10:59:56 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id E80D43A6AE2 for ; Thu, 6 May 2010 10:59:51 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKS+MDiF4Vixa+WzyHitoPGvjumV0GGdM2@postini.com; Thu, 06 May 2010 10:59:41 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Thu, 6 May 2010 10:58:42 -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); Thu, 6 May 2010 10:58:41 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 10:58:41 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 May 2010 10:58:41 -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 o46HweD22398; Thu, 6 May 2010 10:58:40 -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 o46HfW1E059783; Thu, 6 May 2010 17:41:32 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005061741.o46HfW1E059783@idle.juniper.net> To: In-Reply-To: <4BE2E3E1.4050201@iwl.com> Date: Thu, 6 May 2010 13:41:32 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2010 17:58:41.0300 (UTC) FILETIME=[C2F76540:01CAED45] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 17:59:57 -0000 Andy Bierman writes: >What operator problem is solved by this solution proposal? Here are some of the ones previously mentioned: -an app loads a config fetched with report-all and ends up with a horribly bloated config - an archived config is found but there's no indication what is "real" config and what is report-all'd defaults - a thin client wants to should the configured values, including defaults, but wants to flag default values to make it plain to the user they are not part of the config. Thanks, Phil From phil@juniper.net Thu May 6 11:04: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 344D33A6C01 for ; Thu, 6 May 2010 11:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.123 X-Spam-Level: X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=0.476, 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 0xxWAmAAX7Uw for ; Thu, 6 May 2010 11:04:08 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 137793A6A3F for ; Thu, 6 May 2010 11:04:07 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKS+MEiTcD8sZ4SZMaT/mKICVZ9EeXcep1@postini.com; Thu, 06 May 2010 11:03:55 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Thu, 6 May 2010 11:02:05 -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); Thu, 6 May 2010 11:02:05 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 11:02:05 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 May 2010 11:02:04 -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 o46I23D24725; Thu, 6 May 2010 11:02:03 -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 o46HitQJ060093; Thu, 6 May 2010 17:44:55 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005061744.o46HitQJ060093@idle.juniper.net> To: In-Reply-To: <4BE2FF01.7010400@iwl.com> Date: Thu, 6 May 2010 13:44:55 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2010 18:02:04.0594 (UTC) FILETIME=[3C239920:01CAED46] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 18:04:10 -0000 Andy Bierman writes: >You haven't explained why operators need this meta-data >added to the payload and lowering the bandwidth utilization. Bandwidth utilization is hardly a key issue for report-all. >It seems to me an operator would rather have other meta-data >from the YANG module, such as the description-stmt. The description statement is for implementors. I don't see this as vital meta-data. Thanks, Phil From phil@juniper.net Thu May 6 11:20: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 E36133A6A10 for ; Thu, 6 May 2010 11:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.151 X-Spam-Level: X-Spam-Status: No, score=-6.151 tagged_above=-999 required=5 tests=[AWL=0.448, 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 Cvj6Pd7VZ-rI for ; Thu, 6 May 2010 11:20:38 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 63B1A3A69A0 for ; Thu, 6 May 2010 11:19:46 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKS+MIM+2hbfuaRaiIQu2nE3aTo+CafjHv@postini.com; Thu, 06 May 2010 11:19:34 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Thu, 6 May 2010 11:17:58 -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); Thu, 6 May 2010 11:17:58 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 11:17:58 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 May 2010 11:17:57 -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 o46IHuD31059; Thu, 6 May 2010 11:17:57 -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 o46I0nEr061498; Thu, 6 May 2010 18:00:49 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005061800.o46I0nEr061498@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20100506175822.GA2657@elstar.local> Date: Thu, 6 May 2010 14:00:49 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2010 18:17:57.0738 (UTC) FILETIME=[7441D4A0:01CAED48] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 18:20:40 -0000 Juergen Schoenwaelder writes: >For what it is worth, I believe the announcement how defaults are >handled should be part of 4741bis. Knowing how defaults are handled by >a server is crucial for using NETCONF and the announcement itself >really is not a big deal. I disagree, since I don't want my app to even care about how the server is handling defaults. If I have to special case this in my app-side code, something is very wrong. Thanks, Phil From andyb@iwl.com Thu May 6 11:29: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 D07273A6835 for ; Thu, 6 May 2010 11:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[AWL=-0.896, 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 KvpaPEt9yGHG for ; Thu, 6 May 2010 11:29:09 -0700 (PDT) Received: from smtp114.dfw.emailsrvr.com (smtp114.dfw.emailsrvr.com [67.192.241.114]) by core3.amsl.com (Postfix) with ESMTP id D21883A6929 for ; Thu, 6 May 2010 11:29:09 -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 EF7962E40456; Thu, 6 May 2010 14:28:56 -0400 (EDT) Received: by relay21.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id B58122E403D2; Thu, 6 May 2010 14:28:56 -0400 (EDT) Message-ID: <4BE30A70.6070500@iwl.com> Date: Thu, 06 May 2010 11:29:04 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201005061741.o46HfW1E059783@idle.juniper.net> In-Reply-To: <201005061741.o46HfW1E059783@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 06 May 2010 18:29:10 -0000 Phil Shafer wrote: > Andy Bierman writes: > >> What operator problem is solved by this solution proposal? >> > > Here are some of the ones previously mentioned: > > -an app loads a config fetched with report-all and ends up with a > horribly bloated config > So how does adding more text to the payload solve this problem? > - an archived config is found but there's no indication what is "real" config and > what is report-all'd defaults > This is an operator usage detail. The operator can select which with-defaults mode to use. The protocol does not need to add this specific meta-data. SNMP never added any SMIv2 contents to the payload. I don't see why NETCONF needs to do this. > - a thin client wants to should the configured values, including defaults, but wants > to flag default values to make it plain to the user they are not > part of the config. > The current draft allows the client to do this by selecting different modes and comparing the results. IMO it is unacceptable to force all clients to deal with meta-data in the reply because there is no compelling need to know which leafs happen to equal the default value, but the client does not want to use any sort of schema file. That is what will happen if servers MAY add XML attributes to the payload. This breaks existing clients, which (IMO) is unacceptable. BTW, description-stmts are not just for implementors. An operator needs to know the purpose of the config data. This is always part of the description-stmt. If we were ranking meta-data: 1) is leaf a list key/naming nodes 2) description/purpose 3) mandatory vs. optional 4) min/max constraints 5) needs to be unique 6) must/when constraints 7) value is the schema default But of course I think the client should somehow learn this information off-line (or w/ ). Use YANG or DSDL or Acme Miracle DML or whatever. > Thanks, > Phil > > Andy From j.schoenwaelder@jacobs-university.de Thu May 6 11:31:01 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32BC03A692B for ; Thu, 6 May 2010 11:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.063 X-Spam-Level: X-Spam-Status: No, score=-0.063 tagged_above=-999 required=5 tests=[AWL=-0.228, 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 H6A1B2WUfx1r for ; Thu, 6 May 2010 11:31:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D6B803A67FF for ; Thu, 6 May 2010 11:30:59 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D8BBCC014E; Thu, 6 May 2010 20:30:46 +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 FAkLeOqXVLKw; Thu, 6 May 2010 20:30:45 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CFE87C0141; Thu, 6 May 2010 20:30:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 191F311F423A; Thu, 6 May 2010 20:30:43 +0200 (CEST) Date: Thu, 6 May 2010 20:30:43 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20100506183043.GA2767@elstar.local> Mail-Followup-To: Phil Shafer , Andy Bierman , "netconf@ietf.org" References: <20100506175822.GA2657@elstar.local> <201005061800.o46I0nEr061498@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005061800.o46I0nEr061498@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.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: Thu, 06 May 2010 18:31:01 -0000 On Thu, May 06, 2010 at 08:00:49PM +0200, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >For what it is worth, I believe the announcement how defaults are > >handled should be part of 4741bis. Knowing how defaults are handled by > >a server is crucial for using NETCONF and the announcement itself > >really is not a big deal. > > I disagree, since I don't want my app to even care about how the > server is handling defaults. If I have to special case this in my > app-side code, something is very wrong. I just do not know how to write an app that deals in a sensible way with servers that deal with defaults differently. Perhaps I am just dumb. Then I vote for an appendix that explains how that can be done to be added to 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 andyb@iwl.com Thu May 6 11:35: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 A34883A6A42 for ; Thu, 6 May 2010 11:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=-0.423, 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 BVp3-Lq9y0RL for ; Thu, 6 May 2010 11:35:56 -0700 (PDT) Received: from smtp164.iad.emailsrvr.com (smtp164.iad.emailsrvr.com [207.97.245.164]) by core3.amsl.com (Postfix) with ESMTP id 7845A3A6A61 for ; Thu, 6 May 2010 11:35:55 -0700 (PDT) Received: from relay26.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay26.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 72FAD1B4025; Thu, 6 May 2010 14:35:42 -0400 (EDT) Received: by relay26.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 2A7EE1B4044; Thu, 6 May 2010 14:35:42 -0400 (EDT) Message-ID: <4BE30C06.1030704@iwl.com> Date: Thu, 06 May 2010 11:35:50 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer , "netconf@ietf.org" References: <20100506175822.GA2657@elstar.local> <201005061800.o46I0nEr061498@idle.juniper.net> <20100506183043.GA2767@elstar.local> In-Reply-To: <20100506183043.GA2767@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.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, 06 May 2010 18:35:57 -0000 Juergen Schoenwaelder wrote: > On Thu, May 06, 2010 at 08:00:49PM +0200, Phil Shafer wrote: > >> Juergen Schoenwaelder writes: >> >>> For what it is worth, I believe the announcement how defaults are >>> handled should be part of 4741bis. Knowing how defaults are handled by >>> a server is crucial for using NETCONF and the announcement itself >>> really is not a big deal. >>> >> I disagree, since I don't want my app to even care about how the >> server is handling defaults. If I have to special case this in my >> app-side code, something is very wrong. >> > > First you argue that every client MUST be able to accept wd:default="true" attributes in RPC replies, and now you are saying you don't want a client to ever care about defaults. Which is it? > I just do not know how to write an app that deals in a sensible way > with servers that deal with defaults differently. Perhaps I am just > dumb. Then I vote for an appendix that explains how that can be done > to be added to 4741bis. > Why does it matter which document contains with-defaults? I don't want to waste any time going over text that has already been approved by the WG, and gone through 2 WGLCs. The 4741bis work is already behind schedule, and nobody seems interested in resolving the open issues already holding up that draft. > /js > > Andy From phil@juniper.net Thu May 6 11:51: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 C9D2428C129 for ; Thu, 6 May 2010 11:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.176 X-Spam-Level: X-Spam-Status: No, score=-6.176 tagged_above=-999 required=5 tests=[AWL=0.423, 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 ex2tV0trQDKF for ; Thu, 6 May 2010 11:51:11 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 9C5953A69D5 for ; Thu, 6 May 2010 11:51:09 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKS+MPkDWBBKThK5V1U5e6t+nOZQJZmoS/@postini.com; Thu, 06 May 2010 11:50:58 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Thu, 6 May 2010 11:48:26 -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); Thu, 6 May 2010 11:48:25 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 11:48:25 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 May 2010 11:48:24 -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 o46ImOD45256; Thu, 6 May 2010 11:48:24 -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 o46IVGOB064113; Thu, 6 May 2010 18:31:16 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005061831.o46IVGOB064113@idle.juniper.net> To: In-Reply-To: <4BE30C06.1030704@iwl.com> Date: Thu, 6 May 2010 14:31:16 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2010 18:48:24.0996 (UTC) FILETIME=[B5634640:01CAED4C] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 18:51:11 -0000 Andy Bierman writes: >First you argue that every client MUST be able to accept >wd:default="true" attributes in RPC replies, and now you are saying >you don't want a client to ever care about defaults. >Which is it? I'm arguing Kent's point, that if you add this default stuff into normal config you need a way to flag it both so the client knows that it is, and so the server can safely discard it. My personal take is that w-d is misguided, but if you are going to do it, make it work in a safe way that won't turn normal config on the box into a bloated, default-laden mess. Thanks, Phil From phil@juniper.net Thu May 6 11:55: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 0DCA33A69A0 for ; Thu, 6 May 2010 11:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=0.401, 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 WHUVD0X24Uf1 for ; Thu, 6 May 2010 11:55:46 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 5A6773A6A28 for ; Thu, 6 May 2010 11:55:45 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKS+MQoqVY3tqMxvt2ZAjIVqq3cWWUNG5m@postini.com; Thu, 06 May 2010 11:55:33 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Thu, 6 May 2010 11:54:32 -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); Thu, 6 May 2010 11:54:32 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 11:54:32 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 May 2010 11:54:31 -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 o46IsUD48498; Thu, 6 May 2010 11:54:31 -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 o46IbNKd064651; Thu, 6 May 2010 18:37:23 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005061837.o46IbNKd064651@idle.juniper.net> To: In-Reply-To: <4BE30A70.6070500@iwl.com> Date: Thu, 6 May 2010 14:37:23 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2010 18:54:31.0616 (UTC) FILETIME=[8FE90C00:01CAED4D] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 18:55:47 -0000 Andy Bierman writes: >> -an app loads a config fetched with report-all and ends up with a >> horribly bloated config >So how does adding more text to the payload solve this problem? If the report-all config flags default values with a new attribute, then when that config is loaded, the server will see that they are defaults and can process them as such (typically by discarding those leafs and letting the normal default logic engage). Thanks, Phil From phil@juniper.net Thu May 6 12:01: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 96C263A6B9B for ; Thu, 6 May 2010 12:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.218 X-Spam-Level: X-Spam-Status: No, score=-6.218 tagged_above=-999 required=5 tests=[AWL=0.381, 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 cNfAXyIqdDwB for ; Thu, 6 May 2010 12:01:27 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 079523A6A5E for ; Thu, 6 May 2010 12:01:26 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKS+MR+EgDpJmWMgimMrwnjeuyewa9mNQY@postini.com; Thu, 06 May 2010 12:01:15 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Thu, 6 May 2010 12:00:44 -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); Thu, 6 May 2010 12:00:44 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 12:00:43 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 May 2010 12:00: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 o46J0gD51346; Thu, 6 May 2010 12:00: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 o46IhXJP065238; Thu, 6 May 2010 18:43:34 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005061843.o46IhXJP065238@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20100506183043.GA2767@elstar.local> Date: Thu, 6 May 2010 14:43:33 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2010 19:00:43.0314 (UTC) FILETIME=[6D75A920:01CAED4E] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 19:01:28 -0000 Juergen Schoenwaelder writes: >I just do not know how to write an app that deals in a sensible way >with servers that deal with defaults differently. I think the sensible way is also the easy way. The YANG module lists the default value; if your app is happy with those values, then it need not send that leaf; if your app wants another value, then it sends that leaf with the value. If you send the leaf containing the default value, that's perfectly fine. When you fetch the leaf, be aware that if the leaf's value is the default, it may not be present in the returned data. Server's know enough to be well behaved if a client attempts to delete or create a leaf that has a default value, and clients know enough to be well behaved when default values are not returned. I'd be happy to see a section that defines these as rules of the road. Thanks, Phil From andyb@iwl.com Thu May 6 12:01: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 4ADC63A6BC5 for ; Thu, 6 May 2010 12:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=0.429, 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 Mme+OC2UI+Fp for ; Thu, 6 May 2010 12:01: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 4F9353A6A58 for ; Thu, 6 May 2010 12:01: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 4BB5430B0392; Thu, 6 May 2010 15:01:21 -0400 (EDT) Received: by relay15.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 0E8B130B0148; Thu, 6 May 2010 15:01:20 -0400 (EDT) Message-ID: <4BE31209.3060507@iwl.com> Date: Thu, 06 May 2010 12:01:29 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201005061837.o46IbNKd064651@idle.juniper.net> In-Reply-To: <201005061837.o46IbNKd064651@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 06 May 2010 19:01:35 -0000 Phil Shafer wrote: > Andy Bierman writes: > >>> -an app loads a config fetched with report-all and ends up with a >>> horribly bloated config >>> >> So how does adding more text to the payload solve this problem? >> > > If the report-all config flags default values with a new attribute, > then when that config is loaded, the server will see that they are > defaults and can process them as such (typically by discarding > those leafs and letting the normal default logic engage). > > The server needs to be able to support 'trim' mode in order to create the wd:default="true" attribute. So the client can just use with-defaults=trim for the get-config operation. The server will to this discarding work for the client. > Thanks, > Phil > > Andy From phil@juniper.net Thu May 6 12:10: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 3D5003A6A51 for ; Thu, 6 May 2010 12:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.236 X-Spam-Level: X-Spam-Status: No, score=-6.236 tagged_above=-999 required=5 tests=[AWL=0.363, 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 WP9VTNVxdwWf for ; Thu, 6 May 2010 12:10:29 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 74A763A6A59 for ; Thu, 6 May 2010 12:10:27 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKS+MUExdBZDbZNnfMvlvSNw9wMboBxooS@postini.com; Thu, 06 May 2010 12:10:16 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Thu, 6 May 2010 12:09:58 -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); Thu, 6 May 2010 12:09:58 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 12:09:58 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 May 2010 12:09:58 -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 o46J9vD54673; Thu, 6 May 2010 12:09:57 -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 o46Iqn6F066070; Thu, 6 May 2010 18:52:49 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005061852.o46Iqn6F066070@idle.juniper.net> To: In-Reply-To: <4BE31209.3060507@iwl.com> Date: Thu, 6 May 2010 14:52:49 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2010 19:09:58.0105 (UTC) FILETIME=[B8240C90:01CAED4F] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 19:10:30 -0000 Andy Bierman writes: >> If the report-all config flags default values with a new attribute, >> then when that config is loaded, the server will see that they are >> defaults and can process them as such (typically by discarding >> those leafs and letting the normal default logic engage). > >The server needs to be able to support 'trim' mode >in order to create the wd:default="true" attribute. >So the client can just use with-defaults=trim for >the get-config operation. The server will to this discarding >work for the client. I think we're talking past each other, but I'm not sure why. If a client app requests get-config(report-all) from a server, that server may intermix default values with real values. The fetched config will have no indication which values are real and which are defaults that are only reported because of the "report-all". If the app archives this data and next week wants to restore it, then the server will see a ton of defaults and (if the server is explicit) they will add these defaults to the real config. This will cause evil config bloating. The attribute addresses this as mentioned above (allowing the server to detect defaults). Thanks, Phil From j.schoenwaelder@jacobs-university.de Thu May 6 12:23: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 6E45E3A68A0 for ; Thu, 6 May 2010 12:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.034 X-Spam-Level: X-Spam-Status: No, score=0.034 tagged_above=-999 required=5 tests=[AWL=-0.317, 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 A2XueEif6R8i for ; Thu, 6 May 2010 12:23:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E93363A66B4 for ; Thu, 6 May 2010 12:23:33 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0B21C006E; Thu, 6 May 2010 21:23:20 +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 DD+eWitLYysq; Thu, 6 May 2010 21:23:19 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 83900C0054; Thu, 6 May 2010 21:23:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C348F11F443A; Thu, 6 May 2010 21:23:18 +0200 (CEST) Date: Thu, 6 May 2010 21:23:17 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20100506192317.GA2854@elstar.local> Mail-Followup-To: Phil Shafer , Andy Bierman , "netconf@ietf.org" References: <20100506183043.GA2767@elstar.local> <201005061843.o46IhXJP065238@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005061843.o46IhXJP065238@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST ***CALL for draft-ietf-netconf-with-defaults-07.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: Thu, 06 May 2010 19:23:36 -0000 On Thu, May 06, 2010 at 08:43:33PM +0200, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >I just do not know how to write an app that deals in a sensible way > >with servers that deal with defaults differently. > > I think the sensible way is also the easy way. The YANG module > lists the default value; if your app is happy with those values, > then it need not send that leaf; if your app wants another value, > then it sends that leaf with the value. If you send the leaf > containing the default value, that's perfectly fine. When you fetch > the leaf, be aware that if the leaf's value is the default, it may > not be present in the returned data. Server's know enough to > be well behaved if a client attempts to delete or create a leaf > that has a default value, and clients know enough to be well behaved > when default values are not returned. > > I'd be happy to see a section that defines these as rules of the road. So this means you can't simply diff/compare configs without an application that first grabs all relevant YANG modules and normalizes the defaults by triming them? And you are fine that well behaved clients remove explicitely set defaults from config? I also note that default statements may be added to YANG definitions - so that client needs to be aware of all relevant revisions of the YANG definitions involved. If clients at the end have to trim in any case to be well-behaved, why do we then allow servers to behave in different ways in the first place? If there is a reason for servers to have differnet behaviour when it comes to defaults, what is wrong with telling the client what a server actually does? /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 May 6 12:24: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 4FA783A6A55 for ; Thu, 6 May 2010 12:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.641 X-Spam-Level: X-Spam-Status: No, score=-0.641 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_40=-0.185, 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 jQ8ufB0DKOV7 for ; Thu, 6 May 2010 12:24:48 -0700 (PDT) Received: from smtp184.dfw.emailsrvr.com (smtp184.dfw.emailsrvr.com [67.192.241.184]) by core3.amsl.com (Postfix) with ESMTP id 910AD3A6B13 for ; Thu, 6 May 2010 12:24:20 -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 B5986402F5; Thu, 6 May 2010 15:24:07 -0400 (EDT) Received: by relay8.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 695234020A; Thu, 6 May 2010 15:24:07 -0400 (EDT) Message-ID: <4BE3175F.2090508@iwl.com> Date: Thu, 06 May 2010 12:24:15 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201005061852.o46Iqn6F066070@idle.juniper.net> In-Reply-To: <201005061852.o46Iqn6F066070@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 06 May 2010 19:24:49 -0000 Phil Shafer wrote: > Andy Bierman writes: > >>> If the report-all config flags default values with a new attribute, >>> then when that config is loaded, the server will see that they are >>> defaults and can process them as such (typically by discarding >>> those leafs and letting the normal default logic engage). >>> >> The server needs to be able to support 'trim' mode >> in order to create the wd:default="true" attribute. >> So the client can just use with-defaults=trim for >> the get-config operation. The server will to this discarding >> work for the client. >> > > I think we're talking past each other, but I'm not sure why. > > If a client app requests get-config(report-all) from a server, that > server may intermix default values with real values. The fetched > config will have no indication which values are real and which are > defaults that are only reported because of the "report-all". If > the app archives this data and next week wants to restore it, then > the server will see a ton of defaults and (if the server is explicit) > they will add these defaults to the real config. This will cause > evil config bloating. > > The attribute addresses this as mentioned above (allowing the server > to detect defaults). > > No we are not talking past each other. If the client wants to keep the real values, it should use 'trim', not 'report-all'. We don't need to add XML attributes to NETCONF so a client can use the wrong mode. Martin also made an important point, which is the meaning of basic-mode: report-all: the server does not have to keep track of any sort of default so it cannot be forced to return wd:default=true trim: the server prunes schema default values explicit: the server trims server schema default values but keeps client schema default values. (An explicit server can always do trim because of this server-created-default rule. So Kent's premise that every server that supports :with-defaults can support report-all and can also tag all the schema-defaults, is not correct. Any server that can tag the defaults can also support the 'trim' mode, so the client can compare 2 XML trees and get this information, without changing the NETCONF protocol. > Thanks, > Phil > > Andy From kwatsen@juniper.net Thu May 6 15:06: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 93D823A6BE1 for ; Thu, 6 May 2010 15:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.593 X-Spam-Level: X-Spam-Status: No, score=-4.593 tagged_above=-999 required=5 tests=[AWL=-0.594, 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 BIEud+vfG64L for ; Thu, 6 May 2010 15:06:17 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 014AB3A6BC6 for ; Thu, 6 May 2010 15:06:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKS+M9SoInARpwDB/DNnmQJpASgIVi21FX@postini.com; Thu, 06 May 2010 15:06:03 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 6 May 2010 15:05:02 -0700 From: Kent Watsen To: "'andyb@iwl.com'" , Phil Shafer Date: Thu, 6 May 2010 15:05:02 -0700 Thread-Topic: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt Thread-Index: AcrtSgX15gy16FaLS6qVkIw3ud0FlgAEdJog Message-ID: <84600D05C20FF943918238042D7670FD36C7D7636E@EMBX01-HQ.jnpr.net> References: <201005061741.o46HfW1E059783@idle.juniper.net> <4BE30A70.6070500@iwl.com> In-Reply-To: <4BE30A70.6070500@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 22:06:18 -0000 > If we were ranking meta-data: > 1) is leaf a list key/naming nodes > 2) description/purpose > 3) mandatory vs. optional > 4) min/max constraints > 5) needs to be unique > 6) must/when constraints > 7) value is the schema default Tagging defaults isn't about duplicating everything that can be described i= n a data model; it's about data-sourcing, which is typically desired when a= server is asked to flatten/expand some aspect of its configuration. Here are a couple more data-sourcing examples: 1. a device supporting the notion templates (i.e. config-groups) is asked t= o return configuration with all templates flattened. Client wants the comp= lete config, but would like to know which parts came from a template and, i= f so, which one. Server again wants to insure that it doesn't create a bun= ch of local config objects when the config is sent back to it 2. a device supporting a cluster may have some cluster-global config (value= s shared by all members of the cluster) and cluster-local config (member-sp= ecific values). Client wants the complete config from one cluster-member, = annotated with which parts are inherited from the cluster-global definition= . I'm not suggesting that NETCONF support either of these things; I'm only u= sing these examples to illustrate why tagging default values is different t= han any other tag mentioned in the list above. Thanks, Kent > But of course I think the client should somehow learn > this information off-line (or w/ ). > Use YANG or DSDL or Acme Miracle DML or whatever. From j.schoenwaelder@jacobs-university.de Thu May 6 15:36: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 AD9593A6852 for ; Thu, 6 May 2010 15:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.045 X-Spam-Level: X-Spam-Status: No, score=0.045 tagged_above=-999 required=5 tests=[AWL=-0.306, 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 q7+8yDavlYiM for ; Thu, 6 May 2010 15:36:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B374D3A679C for ; Thu, 6 May 2010 15:36:10 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C941EC0051; Fri, 7 May 2010 00:35:57 +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 vtQ7ovpgaGJJ; Fri, 7 May 2010 00:35: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 4CF86C002E; Fri, 7 May 2010 00:35:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1E3CB11F49F8; Fri, 7 May 2010 00:35:51 +0200 (CEST) Date: Fri, 7 May 2010 00:35:51 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20100506223550.GB3137@elstar.local> Mail-Followup-To: Kent Watsen , "'andyb@iwl.com'" , Phil Shafer , "netconf@ietf.org" References: <201005061741.o46HfW1E059783@idle.juniper.net> <4BE30A70.6070500@iwl.com> <84600D05C20FF943918238042D7670FD36C7D7636E@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D7636E@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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: Thu, 06 May 2010 22:36:12 -0000 On Fri, May 07, 2010 at 12:05:02AM +0200, Kent Watsen wrote: > Tagging defaults isn't about duplicating everything that can be described in a data model; it's about data-sourcing, which is typically desired when a server is asked to flatten/expand some aspect of its configuration. > > Here are a couple more data-sourcing examples: > > 1. a device supporting the notion templates (i.e. config-groups) is asked to return configuration with all templates flattened. Client wants the complete config, but would like to know which parts came from a template and, if so, which one. Server again wants to insure that it doesn't create a bunch of local config objects when the config is sent back to it > > 2. a device supporting a cluster may have some cluster-global config (values shared by all members of the cluster) and cluster-local config (member-specific values). Client wants the complete config from one cluster-member, annotated with which parts are inherited from the cluster-global definition. > > I'm not suggesting that NETCONF support either of these things; I'm only using these examples to illustrate why tagging default values is different than any other tag mentioned in the list above. Tagging might be a workable solution for the representation of operational state, something we like to skip over because we do not have a good and agreed upon solution. Perhaps another way of looking at YANG defaults is that they represent well-known hard-wired static operational state. By answering the more general dynamic operational state representation question, YANG defaults might just fall out naturally... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Thu May 6 15:43:05 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 1DE003A6982 for ; Thu, 6 May 2010 15:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.865 X-Spam-Level: X-Spam-Status: No, score=-4.865 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_20=-0.74, 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 CrJQg5EAREi5 for ; Thu, 6 May 2010 15:43:04 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 801A23A6852 for ; Thu, 6 May 2010 15:43:01 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKS+NF57LyyfaRo0ZnWsVUKfDh4tY8N30U@postini.com; Thu, 06 May 2010 15:42:49 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 6 May 2010 15:42:18 -0700 From: Kent Watsen To: "'andyb@iwl.com'" , Phil Shafer Date: Thu, 6 May 2010 15:42:18 -0700 Thread-Topic: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt Thread-Index: AcrtTofO+trW679eRKuWUunw02DI7AAGfA3A Message-ID: <84600D05C20FF943918238042D7670FD36C7D76372@EMBX01-HQ.jnpr.net> References: <201005061837.o46IbNKd064651@idle.juniper.net> <4BE31209.3060507@iwl.com> In-Reply-To: <4BE31209.3060507@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 22:43:05 -0000 > The server needs to be able to support 'trim' mode > in order to create the wd:default=3D"true" attribute. Explicit servers do not need to support trim and yet can still tag their de= faults. Also, I doubt an explicit server, which has gone thru the trouble = to support explicit, would even support trim, as that would dilute its core= value proposition. Consider this: Basic-Mode report-all trim explicit ------------------------ ---------- ---- -------- Can Support Report-All? yes yes yes=20 Can Support Trim? no yes yes Can support Explicit? no no yes Can Tag Defaults? no yes yes=20 Problem if untagged config returned? n/a no yes = =20 BTW, the example in the I-D: "with-defaults?basic-mode=3Dreport-all&also-supported=3Dtrim,explicit" doesn't make sense to me. A server capable of supporting 'explicit' will h= ave basic-mode=3Dexplicit, else if it supports trim, it will have basic-mod= e=3Dtrim, else it can only have basic-mode=3Dreport-all. > So the client can just use with-defaults=3Dtrim for > the get-config operation. The server will to this discarding > work for the client. This is a red herring; the goal, for explicit servers, is to either make re= port-all safe or remove it as a requirement Thanks, Kent From andyb@iwl.com Thu May 6 15:55: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 4D31A3A6A28 for ; Thu, 6 May 2010 15:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[AWL=-0.492, 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 S5KXKU6kYgzG for ; Thu, 6 May 2010 15:55:01 -0700 (PDT) Received: from smtp124.dfw.emailsrvr.com (smtp124.dfw.emailsrvr.com [67.192.241.124]) by core3.amsl.com (Postfix) with ESMTP id 949753A694A for ; Thu, 6 May 2010 15:55:01 -0700 (PDT) Received: from relay2.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay2.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 9F708E22038; Thu, 6 May 2010 18:54:48 -0400 (EDT) Received: by relay2.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 59C83E21FD3; Thu, 6 May 2010 18:54:48 -0400 (EDT) Message-ID: <4BE348C0.2050307@iwl.com> Date: Thu, 06 May 2010 15:54:56 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <201005061741.o46HfW1E059783@idle.juniper.net> <4BE30A70.6070500@iwl.com> <84600D05C20FF943918238042D7670FD36C7D7636E@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D7636E@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 06 May 2010 22:55:02 -0000 Kent Watsen wrote: >> If we were ranking meta-data: >> 1) is leaf a list key/naming nodes >> 2) description/purpose >> 3) mandatory vs. optional >> 4) min/max constraints >> 5) needs to be unique >> 6) must/when constraints >> 7) value is the schema default >> > > Tagging defaults isn't about duplicating everything that can be described in a data model; it's about data-sourcing, which is typically desired when a server is asked to flatten/expand some aspect of its configuration. > > Here are a couple more data-sourcing examples: > > 1. a device supporting the notion templates (i.e. config-groups) is asked to return configuration with all templates flattened. Client wants the complete config, but would like to know which parts came from a template and, if so, which one. Server again wants to insure that it doesn't create a bunch of local config objects when the config is sent back to it > > 2. a device supporting a cluster may have some cluster-global config (values shared by all members of the cluster) and cluster-local config (member-specific values). Client wants the complete config from one cluster-member, annotated with which parts are inherited from the cluster-global definition. > > I'm not suggesting that NETCONF support either of these things; I'm only using these examples to illustrate why tagging default values is different than any other tag mentioned in the list above. > > The application developer can do whatever it wants with the data it retrieves. Just refer to the data model or hardwire the code to do what the data model says. > Thanks, > Kent > Andy From andyb@iwl.com Thu May 6 16:58: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 617E03A69E5 for ; Thu, 6 May 2010 16:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_05=-1.11, 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 Gr6rQur1mMBk for ; Thu, 6 May 2010 16:58:52 -0700 (PDT) Received: from smtp184.iad.emailsrvr.com (smtp184.iad.emailsrvr.com [207.97.245.184]) by core3.amsl.com (Postfix) with ESMTP id A69823A694E for ; Thu, 6 May 2010 16:58:52 -0700 (PDT) Received: from relay28.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay28.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id CA1E21B47E3 for ; Thu, 6 May 2010 19:58:39 -0400 (EDT) Received: by relay28.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 9DB291B40A4 for ; Thu, 6 May 2010 19:58:39 -0400 (EDT) Message-ID: <4BE357B7.9020109@iwl.com> Date: Thu, 06 May 2010 16:58:47 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] delete-config on candidate? 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, 06 May 2010 23:58:53 -0000 Hi, What is the resolution to this 4741bis issue? Currently the YANG module says the allowed sources to delete are 'startup' or an file. The text section does not say candidate is disallowed. The discard-changes operation seems easier to use than delete-config with a parameter. The draft needs to be updated one way or the other. Andy From phil@juniper.net Thu May 6 17:06: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 397923A68C8 for ; Thu, 6 May 2010 17:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.253 X-Spam-Level: X-Spam-Status: No, score=-6.253 tagged_above=-999 required=5 tests=[AWL=0.346, 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 hfP7K6YjcnoI for ; Thu, 6 May 2010 17:06:44 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 18D023A688E for ; Thu, 6 May 2010 17:06:43 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKS+NZhsVn6G1aylECpXXuIWho10FZblU+@postini.com; Thu, 06 May 2010 17:06:31 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Thu, 6 May 2010 17:05:32 -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); Thu, 6 May 2010 17:05:32 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 17:05:31 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 May 2010 17:05:31 -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 o4705UD75187; Thu, 6 May 2010 17:05:30 -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 o46NmMpo089074; Thu, 6 May 2010 23:48:22 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005062348.o46NmMpo089074@idle.juniper.net> To: In-Reply-To: <4BE357B7.9020109@iwl.com> Date: Thu, 6 May 2010 19:48:22 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 May 2010 00:05:31.0080 (UTC) FILETIME=[01D14C80:01CAED79] MIME-Version: 1.0 Content-Type: text/plain Cc: NETCONF Subject: Re: [Netconf] delete-config on candidate? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 07 May 2010 00:06:45 -0000 Andy Bierman writes: >Currently the YANG module says the allowed >sources to delete are 'startup' or an file. >The text section does not say candidate is disallowed. The definition need not list all disallowed options. But the section on :candidate does not like as a modified operation. This means delete-config is not allowed. Thanks, Phil From andyb@iwl.com Fri May 7 13:18: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 65A863A67FF for ; Fri, 7 May 2010 13:18:23 -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.089, 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 A4P+MlkDHLJi for ; Fri, 7 May 2010 13:18:22 -0700 (PDT) Received: from smtp184.dfw.emailsrvr.com (smtp184.dfw.emailsrvr.com [67.192.241.184]) by core3.amsl.com (Postfix) with ESMTP id BBD423A684A for ; Fri, 7 May 2010 13:18:15 -0700 (PDT) Received: from relay18.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay18.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 0E01816F20E7; Fri, 7 May 2010 16:18:03 -0400 (EDT) Received: by relay18.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 8170116F1F23; Fri, 7 May 2010 16:18:02 -0400 (EDT) Message-ID: <4BE4757F.7050909@iwl.com> Date: Fri, 07 May 2010 13:18:07 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <201005061837.o46IbNKd064651@idle.juniper.net> <4BE31209.3060507@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76372@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D76372@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 07 May 2010 20:18:24 -0000 Kent Watsen wrote: >> The server needs to be able to support 'trim' mode >> in order to create the wd:default="true" attribute. >> > > Explicit servers do not need to support trim and yet can still tag their defaults. Also, I doubt an explicit server, which has gone thru the trouble to support explicit, would even support trim, as that would dilute its core value proposition. > > > Consider this: > > Basic-Mode report-all trim explicit > ------------------------ ---------- ---- -------- > Can Support Report-All? yes yes yes > Can Support Trim? no yes yes > Can support Explicit? no no yes > Can Tag Defaults? no yes yes > Problem if untagged config returned? n/a no yes > > > I don't really understand this chart, or why it is a problem if untagged nodes are returned in explicit mode. In explicit mode, if the server returns a value it is because the client set it. In explicit mode, if the client sets the node to any value at all, it is part of the config. The fact that the client-set value equals the schema-default is irrelevant in explicit mode. My strong objections to this work remain: 1) no need to encode YANG properties into the protocol. There is no standards need for this extra complexity and verbosity. 2) not client-initiated The client must somehow select (in the ) "I want wd:default attributes in the reply". It cannot be an arbitrary decision up to the server. 3) there is nothing special about default-stmt. I prefer to see a coherent I-D that proposes how the client can request any meta-data in the reply, and wd:default is just 1 data node within that framework. The current proposal is short-sighted, especially when we already know about other meta-data that would be useful. > BTW, the example in the I-D: > > "with-defaults?basic-mode=report-all&also-supported=trim,explicit" > > doesn't make sense to me. A server capable of supporting 'explicit' will have basic-mode=explicit, else if it supports trim, it will have basic-mode=trim, else it can only have basic-mode=report-all. > > > probably true, although that is a server vendor decision. It may even be an operator-configurable setting. > >> So the client can just use with-defaults=trim for >> the get-config operation. The server will to this discarding >> work for the client. >> > > This is a red herring; the goal, for explicit servers, is to either make report-all safe or remove it as a requirement > > > > Thanks, > Kent > > > > Andy From kwatsen@juniper.net Fri May 7 14: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 E15933A69F5 for ; Fri, 7 May 2010 14:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.876 X-Spam-Level: X-Spam-Status: No, score=-3.876 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_50=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60kywbgzIXbL for ; Fri, 7 May 2010 14:07:26 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 9F80D3A68F0 for ; Fri, 7 May 2010 14:07:26 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKS+SBAcee5KEo6gW8WYAYSPCK+CDHFn8b@postini.com; Fri, 07 May 2010 14:07:14 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 7 May 2010 14:06:08 -0700 From: Kent Watsen To: "'andyb@iwl.com'" Date: Fri, 7 May 2010 14:06:09 -0700 Thread-Topic: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt Thread-Index: AcruImaDWbs8lpasRpG4/ODnxjniPAAAo4oQ Message-ID: <84600D05C20FF943918238042D7670FD36C7D76376@EMBX01-HQ.jnpr.net> References: <201005061837.o46IbNKd064651@idle.juniper.net> <4BE31209.3060507@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76372@EMBX01-HQ.jnpr.net> <4BE4757F.7050909@iwl.com> In-Reply-To: <4BE4757F.7050909@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 21:07:28 -0000 > I don't really understand this chart, or why it is a > problem if untagged nodes are returned in explicit mode. > In explicit mode, if the server returns a value it is because > the client set it. In explicit mode, if the client sets the node > to any value at all, it is part of the config. The fact that > the client-set value equals the schema-default is irrelevant in > explicit mode. Perhaps "returned" is ambiguous, but I was referring to , where= by the server will create a bunch of local config values for defaults, beca= use they weren't tagged. That is the "problem" that we're trying to solve = by tagging the defaults. What's interesting is that it is NOT a problem fo= r a trim server, because it'll just trim the default values again. While b= oth trim and explicit servers can tags defaults, only explicit servers have= the "problem". > 1) no need to encode YANG properties into the protocol. > There is no standards need for this extra complexity > and verbosity. I sure there is a "need", as otherwise we wouldn't be discussing it. Compl= ex/verbose? - I don't think so, so long as it remains focused to just a wd:= defaults attribute; expanding the scope to be for other YANG tags would be = more involved... > 2) not client-initiated > The client must somehow select (in the ) > "I want wd:default attributes in the reply". > It cannot be an arbitrary decision up to the server. If we allow tagging defaults, I think we should let trim/explicit servers a= dvertise if the tagging is: - not supported by the server - supported, but must be asked for - default, may be disabled - always on, no way to disable > 3) there is nothing special about default-stmt. > I prefer to see a coherent I-D that proposes how the > client can request any meta-data in the reply, > and wd:default is just 1 data node within that framework. > The current proposal is short-sighted, especially when > we already know about other meta-data that would be useful. I don't think they're comparable; my experience is that data-sourcing is im= portant, even for a fully schema-aware server. We've never been able to ge= t around needing the device to tag where data came from after a config flat= tening/expanding (via proprietary Juniper capabilities) Thanks, Kent From andyb@iwl.com Fri May 7 15:16: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 3BBB03A6869 for ; Fri, 7 May 2010 15:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_05=-1.11, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=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 lMc5pDpSo0dc for ; Fri, 7 May 2010 15:16:34 -0700 (PDT) Received: from smtp114.iad.emailsrvr.com (smtp114.iad.emailsrvr.com [207.97.245.114]) by core3.amsl.com (Postfix) with ESMTP id 09AE43A6812 for ; Fri, 7 May 2010 15:16:33 -0700 (PDT) Received: from relay21.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay21.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id BECF51B40B0; Fri, 7 May 2010 18:16:20 -0400 (EDT) Received: by relay21.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 458911B40A3; Fri, 7 May 2010 18:16:20 -0400 (EDT) Message-ID: <4BE49139.7050607@iwl.com> Date: Fri, 07 May 2010 15:16:25 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <201005061837.o46IbNKd064651@idle.juniper.net> <4BE31209.3060507@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76372@EMBX01-HQ.jnpr.net> <4BE4757F.7050909@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76376@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D76376@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 07 May 2010 22:16:35 -0000 Kent Watsen wrote: >> I don't really understand this chart, or why it is a >> problem if untagged nodes are returned in explicit mode. >> In explicit mode, if the server returns a value it is because >> the client set it. In explicit mode, if the client sets the node >> to any value at all, it is part of the config. The fact that >> the client-set value equals the schema-default is irrelevant in >> explicit mode. >> > > Perhaps "returned" is ambiguous, but I was referring to , whereby the server will create a bunch of local config values for defaults, because they weren't tagged. That is the "problem" that we're trying to solve by tagging the defaults. What's interesting is that it is NOT a problem for a trim server, because it'll just trim the default values again. While both trim and explicit servers can tags defaults, only explicit servers have the "problem". > Do you mean client instead of server? The server implementation knows the data model somehow, beyond the scope of the NETCONF standard. The server has to generate the tags, so it sure can't use them. By definition, a basic-mode=explicit server will only create nodes that do not have the schema default value. 1) basic-mode=report-all schema defaults may not be available 2) basic-mode=trim schema defaults == get-config(report-all) - get-config(trim) 3) basic-mode=explicit I was led to believe the schema default is not important in this mode. server schema defaults == get-config(report-all) - get-config(explicit) You cannot detect the client created nodes that happen to be the schema default value, but the explicit mode doesn't care about that. A client set node cannot be a default in this mode. > > >> 1) no need to encode YANG properties into the protocol. >> There is no standards need for this extra complexity >> and verbosity. >> > > I sure there is a "need", as otherwise we wouldn't be discussing it. Complex/verbose? - I don't think so, so long as it remains focused to just a wd:defaults attribute; expanding the scope to be for other YANG tags would be more involved... > > > >> 2) not client-initiated >> The client must somehow select (in the ) >> "I want wd:default attributes in the reply". >> It cannot be an arbitrary decision up to the server. >> > > If we allow tagging defaults, I think we should let trim/explicit servers advertise if the tagging is: > - not supported by the server > - supported, but must be asked for > - default, may be disabled > - always on, no way to disable > > > >> 3) there is nothing special about default-stmt. >> I prefer to see a coherent I-D that proposes how the >> client can request any meta-data in the reply, >> and wd:default is just 1 data node within that framework. >> The current proposal is short-sighted, especially when >> we already know about other meta-data that would be useful. >> > > I don't think they're comparable; my experience is that data-sourcing is important, even for a fully schema-aware server. We've never been able to get around needing the device to tag where data came from after a config flattening/expanding (via proprietary Juniper capabilities) > > IMO, there is not WG consensus to expand the scope of the with-defaults document to support meta-data tagging. I think if you want this to be a standard, you should write a draft that addresses all the issues, and specifies all the extensions you want to add to the NETCONF protocol. > Thanks, > Kent > > > Andy From andyb@iwl.com Fri May 7 15:50: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 C657C3A68A0 for ; Fri, 7 May 2010 15:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.428 X-Spam-Level: X-Spam-Status: No, score=-0.428 tagged_above=-999 required=5 tests=[AWL=-0.763, 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 0eOT0Bam9+gS for ; Fri, 7 May 2010 15:50:58 -0700 (PDT) Received: from smtp184.dfw.emailsrvr.com (smtp184.dfw.emailsrvr.com [67.192.241.184]) by core3.amsl.com (Postfix) with ESMTP id C992D3A6869 for ; Fri, 7 May 2010 15:50:58 -0700 (PDT) Received: from relay18.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay18.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 7C19C16F2249 for ; Fri, 7 May 2010 18:50:46 -0400 (EDT) Received: by relay18.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 5C62A16F1E29 for ; Fri, 7 May 2010 18:50:46 -0400 (EDT) Message-ID: <4BE4994B.5030406@iwl.com> Date: Fri, 07 May 2010 15:50:51 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] the real problem 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: Fri, 07 May 2010 22:50:59 -0000 Hi, There is a real problem to be solved, and it isn't GUI rendering tags for thin clients. (Use YANG or read the module and hard-code the GUI.) The problem with defaults is that they are defined in YANG to NOT exist in the conceptual database. This has a major impact on the create and delete operations, because they are only allowed if the data does not exist or exist (respectively). What does that mean for the client developer? basic-mode problem exists? report-all yes explicit no trim yes The problem is that report-all and trim do not distinguish between nodes that exist and do not exist in their filtering algorithm. The information that is needed is really the 'explicit' mode reply. If you receive a node in an 'explicit' reply, you know it can be deleted with nc:operation='delete'. If the node does not exist in the reply, you know that it can be created with nc:operation='create'. The information that is needed is not whether the node equals the schema default, but rather whether it was set explicitly, or whether it is a conceptual default that only exists in the reply, not in the database. Only a basic-mode=explicit server is required to save that information. Maybe explicit mode should be mandatory instead of report-all. Andy From lhotka@cesnet.cz Sat May 8 01:00: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 D721D3A6816 for ; Sat, 8 May 2010 01:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[AWL=-0.331, 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 AkiyRbyFHfuH for ; Sat, 8 May 2010 01:00:37 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 0A8BE3A67D2 for ; Sat, 8 May 2010 01:00:36 -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 EF6242CDE058; Sat, 8 May 2010 10:00:23 +0200 (CEST) From: Ladislav Lhotka To: andyb@iwl.com In-Reply-To: <4BE4994B.5030406@iwl.com> References: <4BE4994B.5030406@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sat, 08 May 2010 10:00:23 +0200 Message-ID: <1273305623.7078.35.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: NETCONF Subject: Re: [Netconf] the real problem 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, 08 May 2010 08:00:37 -0000 Andy Bierman píše v Pá 07. 05. 2010 v 15:50 -0700: > Hi, > > There is a real problem to be solved, and it isn't GUI rendering tags > for thin clients. (Use YANG or read the module and hard-code the GUI.) > > The problem with defaults is that they are defined in YANG > to NOT exist in the conceptual database. This has a major Where does the draft say so? On the contrary, section 7.6.1 states: When the default value is in use, the server MUST operationally behave as is if the leaf was present in the data tree with the default value as its value. Also, in XPath evaluations the missing leaves with default values are conceptually added. If it walks like a duck and quacks like a duck, then it's a "conceptual duck". Lada > impact on the create and delete operations, because they > are only allowed if the data does not exist or exist (respectively). > > What does that mean for the client developer? > > basic-mode problem exists? > report-all yes > explicit no > trim yes > > The problem is that report-all and trim do not distinguish between > nodes that exist and do not exist in their filtering algorithm. > > The information that is needed is really the 'explicit' mode reply. > If you receive a node in an 'explicit' reply, you know > it can be deleted with nc:operation='delete'. If the node does not exist > in the reply, you know that it can be created with nc:operation='create'. > > The information that is needed is not whether the node equals > the schema default, but rather whether it was set explicitly, > or whether it is a conceptual default that only exists in the > reply, not in the database. > > Only a basic-mode=explicit server is required to save that information. > Maybe explicit mode should be mandatory instead of report-all. > > > Andy > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Sat May 8 01:42: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 4774E3A691C for ; Sat, 8 May 2010 01:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[AWL=-0.253, 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 r0UxgNN1Q7Sf for ; Sat, 8 May 2010 01:42:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4363E3A6889 for ; Sat, 8 May 2010 01:42:58 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F41CEC0036; Sat, 8 May 2010 10:42:45 +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 EVsCitGAlxuO; Sat, 8 May 2010 10:42:45 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 82E53C0002; Sat, 8 May 2010 10:42:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DCA6611FEBA2; Sat, 8 May 2010 10:42:43 +0200 (CEST) Date: Sat, 8 May 2010 10:42:43 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20100508084243.GA92644@elstar.local> Mail-Followup-To: Ladislav Lhotka , "andyb@iwl.com" , NETCONF References: <4BE4994B.5030406@iwl.com> <1273305623.7078.35.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1273305623.7078.35.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETCONF Subject: Re: [Netconf] the real problem 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: Sat, 08 May 2010 08:42:59 -0000 On Sat, May 08, 2010 at 10:00:23AM +0200, Ladislav Lhotka wrote: > Andy Bierman p????e v P?? 07. 05. 2010 v 15:50 -0700: > > Hi, > > > > There is a real problem to be solved, and it isn't GUI rendering tags > > for thin clients. (Use YANG or read the module and hard-code the GUI.) > > > > The problem with defaults is that they are defined in YANG > > to NOT exist in the conceptual database. This has a major > > Where does the draft say so? On the contrary, section 7.6.1 states: > > When the default value is in use, the server MUST operationally > behave as is if the leaf was present in the data tree with > the default value as its value. "MUST operationally be have as if the leaf was present" is not the same as the leaf exists in the configuration datastore. > Also, in XPath evaluations the missing leaves with default values > are conceptually added. Yes, conceptionally. The wording was not choosen randomly. /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 Sat May 8 02:22: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 59BC93A69D0 for ; Sat, 8 May 2010 02:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.048 X-Spam-Level: * X-Spam-Status: No, score=1.048 tagged_above=-999 required=5 tests=[AWL=-0.302, 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 aWrLxO2RhGLT for ; Sat, 8 May 2010 02:22:34 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3C69A3A6A0C for ; Sat, 8 May 2010 02:20:25 -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 726712CDE057; Sat, 8 May 2010 11:19:58 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20100508084243.GA92644@elstar.local> References: <4BE4994B.5030406@iwl.com> <1273305623.7078.35.camel@missotis> <20100508084243.GA92644@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sat, 08 May 2010 11:19:57 +0200 Message-ID: <1273310397.7078.61.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: NETCONF Subject: Re: [Netconf] the real problem 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, 08 May 2010 09:22:40 -0000 X-List-Received-Date: Sat, 08 May 2010 09:22:40 -0000 Juergen Schoenwaelder píše v So 08. 05. 2010 v 10:42 +0200: > On Sat, May 08, 2010 at 10:00:23AM +0200, Ladislav Lhotka wrote: > > Andy Bierman p????e v P?? 07. 05. 2010 v 15:50 -0700: > > > Hi, > > > > > > There is a real problem to be solved, and it isn't GUI rendering tags > > > for thin clients. (Use YANG or read the module and hard-code the GUI.) > > > > > > The problem with defaults is that they are defined in YANG > > > to NOT exist in the conceptual database. This has a major > > > > Where does the draft say so? On the contrary, section 7.6.1 states: > > > > When the default value is in use, the server MUST operationally > > behave as is if the leaf was present in the data tree with > > the default value as its value. > > "MUST operationally be have as if the leaf was present" is not the > same as the leaf exists in the configuration datastore. Andy wrote about *conceptual* datastore. I think we agreed in a Jabber conference some time ago that the conceptual datastore does contain the default values. Lada > > > Also, in XPath evaluations the missing leaves with default values > > are conceptually added. > > Yes, conceptionally. The wording was not choosen randomly. > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Sat May 8 02:52: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 18B223A68D3 for ; Sat, 8 May 2010 02:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[AWL=-0.246, 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 yGY5FYYlThrm for ; Sat, 8 May 2010 02:52:44 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EF1AF3A68E3 for ; Sat, 8 May 2010 02:52:43 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB64FC0036; Sat, 8 May 2010 11:52:30 +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 IT-viHrWR56P; Sat, 8 May 2010 11:52:29 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 51CBBC0002; Sat, 8 May 2010 11:52:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A867811FEDCE; Sat, 8 May 2010 11:52:28 +0200 (CEST) Date: Sat, 8 May 2010 11:52:28 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20100508095228.GA92838@elstar.local> Mail-Followup-To: Ladislav Lhotka , "andyb@iwl.com" , NETCONF References: <4BE4994B.5030406@iwl.com> <1273305623.7078.35.camel@missotis> <20100508084243.GA92644@elstar.local> <1273310397.7078.61.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1273310397.7078.61.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETCONF Subject: Re: [Netconf] the real problem 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: Sat, 08 May 2010 09:52:45 -0000 On Sat, May 08, 2010 at 11:19:57AM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder p????e v So 08. 05. 2010 v 10:42 +0200: > > On Sat, May 08, 2010 at 10:00:23AM +0200, Ladislav Lhotka wrote: > > > Andy Bierman p????e v P?? 07. 05. 2010 v 15:50 -0700: > > > > Hi, > > > > > > > > There is a real problem to be solved, and it isn't GUI rendering tags > > > > for thin clients. (Use YANG or read the module and hard-code the GUI.) > > > > > > > > The problem with defaults is that they are defined in YANG > > > > to NOT exist in the conceptual database. This has a major > > > > > > Where does the draft say so? On the contrary, section 7.6.1 states: > > > > > > When the default value is in use, the server MUST operationally > > > behave as is if the leaf was present in the data tree with > > > the default value as its value. > > > > "MUST operationally be have as if the leaf was present" is not the > > same as the leaf exists in the configuration datastore. > > Andy wrote about *conceptual* datastore. I think we agreed in a Jabber > conference some time ago that the conceptual datastore does contain the > default values. If you want to make an argument that explicit mode contradicts NETCONF, then you have to argue based on what is written down in the specs; there have been careful wording exercises to deal with this. And if you were successful, you will of course declare deployed implementations non-compliant. Good luck with that. /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 Sat May 8 04:08: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 7BC8E3A6A2D for ; Sat, 8 May 2010 04:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.083 X-Spam-Level: * X-Spam-Status: No, score=1.083 tagged_above=-999 required=5 tests=[AWL=-0.267, 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 TVWc3-mbQZ9i for ; Sat, 8 May 2010 04:08:26 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A13BD3A6965 for ; Sat, 8 May 2010 04:08:26 -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 46EE12CDE057; Sat, 8 May 2010 13:08:14 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20100508095228.GA92838@elstar.local> References: <4BE4994B.5030406@iwl.com> <1273305623.7078.35.camel@missotis> <20100508084243.GA92644@elstar.local> <1273310397.7078.61.camel@missotis> <20100508095228.GA92838@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sat, 08 May 2010 13:08:13 +0200 Message-ID: <1273316893.7078.101.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: NETCONF Subject: Re: [Netconf] the real problem 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, 08 May 2010 11:08:27 -0000 Juergen Schoenwaelder píše v So 08. 05. 2010 v 11:52 +0200: > On Sat, May 08, 2010 at 11:19:57AM +0200, Ladislav Lhotka wrote: > > Juergen Schoenwaelder p????e v So 08. 05. 2010 v 10:42 +0200: > > > On Sat, May 08, 2010 at 10:00:23AM +0200, Ladislav Lhotka wrote: > > > > Andy Bierman p????e v P?? 07. 05. 2010 v 15:50 -0700: > > > > > Hi, > > > > > > > > > > There is a real problem to be solved, and it isn't GUI rendering tags > > > > > for thin clients. (Use YANG or read the module and hard-code the GUI.) > > > > > > > > > > The problem with defaults is that they are defined in YANG > > > > > to NOT exist in the conceptual database. This has a major > > > > > > > > Where does the draft say so? On the contrary, section 7.6.1 states: > > > > > > > > When the default value is in use, the server MUST operationally > > > > behave as is if the leaf was present in the data tree with > > > > the default value as its value. > > > > > > "MUST operationally be have as if the leaf was present" is not the > > > same as the leaf exists in the configuration datastore. > > > > Andy wrote about *conceptual* datastore. I think we agreed in a Jabber > > conference some time ago that the conceptual datastore does contain the > > default values. > > If you want to make an argument that explicit mode contradicts > NETCONF, then you have to argue based on what is written down in the Please have a look at the text above: did I say anything in this sense? I only have hoped that we agreed on what the *conceptual* datastore contains. If it is not the case, I give up. Lada > specs; there have been careful wording exercises to deal with > this. And if you were successful, you will of course declare deployed > implementations non-compliant. Good luck with that. > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Sat May 8 05:07: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 283353A69C6 for ; Sat, 8 May 2010 05:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=-0.734, 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 KIdOTjEjKKxP for ; Sat, 8 May 2010 05:07:05 -0700 (PDT) Received: from smtp124.iad.emailsrvr.com (smtp124.iad.emailsrvr.com [207.97.245.124]) by core3.amsl.com (Postfix) with ESMTP id 206593A693D for ; Sat, 8 May 2010 05:07:05 -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 B34C844C069; Sat, 8 May 2010 08:06:52 -0400 (EDT) Received: by relay2.r2.iad.emailsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 2FE7444C043; Sat, 8 May 2010 08:06:52 -0400 (EDT) Message-ID: <4BE553E5.4000906@iwl.com> Date: Sat, 08 May 2010 05:07:01 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Ladislav Lhotka References: <4BE4994B.5030406@iwl.com> <1273305623.7078.35.camel@missotis> <20100508084243.GA92644@elstar.local> <1273310397.7078.61.camel@missotis> <20100508095228.GA92838@elstar.local> <1273316893.7078.101.camel@missotis> In-Reply-To: <1273316893.7078.101.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETCONF Subject: Re: [Netconf] the real problem 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: Sat, 08 May 2010 12:07:06 -0000 Ladislav Lhotka wrote: > Juergen Schoenwaelder píše v So 08. 05. 2010 v 11:52 +0200: > >> On Sat, May 08, 2010 at 11:19:57AM +0200, Ladislav Lhotka wrote: >> >>> Juergen Schoenwaelder p????e v So 08. 05. 2010 v 10:42 +0200: >>> >>>> On Sat, May 08, 2010 at 10:00:23AM +0200, Ladislav Lhotka wrote: >>>> >>>>> Andy Bierman p????e v P?? 07. 05. 2010 v 15:50 -0700: >>>>> >>>>>> Hi, >>>>>> >>>>>> There is a real problem to be solved, and it isn't GUI rendering tags >>>>>> for thin clients. (Use YANG or read the module and hard-code the GUI.) >>>>>> >>>>>> The problem with defaults is that they are defined in YANG >>>>>> to NOT exist in the conceptual database. This has a major >>>>>> >>>>> Where does the draft say so? On the contrary, section 7.6.1 states: >>>>> >>>>> When the default value is in use, the server MUST operationally >>>>> behave as is if the leaf was present in the data tree with >>>>> the default value as its value. >>>>> >>>> "MUST operationally be have as if the leaf was present" is not the >>>> same as the leaf exists in the configuration datastore. >>>> >>> Andy wrote about *conceptual* datastore. I think we agreed in a Jabber >>> conference some time ago that the conceptual datastore does contain the >>> default values. >>> >> If you want to make an argument that explicit mode contradicts >> NETCONF, then you have to argue based on what is written down in the >> > > Please have a look at the text above: did I say anything in this sense? > I only have hoped that we agreed on what the *conceptual* datastore > contains. If it is not the case, I give up. > > Nobody has answered the relevant question. What is the correct standard response that every NETCONF server will give the same response: leaf foo { type int32; default 42; } 42 If 'conceptually exists' means the same as 'exists', then this MUST fail with a data-exists error. If it doesn't fail, and the 'create' works instead, then what happens the 2nd time the client sends this create PDU? Does it fail this time? It must, if the server OKed the first create PDU. But it can't exist, because defaults don't exist in the database. Yet when the server reboots, the default is in the database in an explicit-mode server. The same paradox exists for the 'delete' operation. Can you delete a leaf set to its default value? What happens when you delete a leaf with a default, but it is not set to its default value? Does the server send or send a 'data-missing' error? Does every type of defaults-handling server implement create/delete operations the exact same way so a client can use NETCONF, or is NETCONF an unusable mess because we can't even decide that the create/delete operations work the same way on all nodes? If there is a difference between client-set-to-default and server-set-to-default, then how does a client know which values were set by some client, and which were set by the server? > Lada > > >> specs; there have been careful wording exercises to deal with >> this. And if you were successful, you will of course declare deployed >> implementations non-compliant. Good luck with that. >> >> >> /js >> >> > > > Andy From lhotka@cesnet.cz Sat May 8 05:47:01 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58CA63A6A18 for ; Sat, 8 May 2010 05:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.093 X-Spam-Level: * X-Spam-Status: No, score=1.093 tagged_above=-999 required=5 tests=[AWL=-0.257, 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 Gvleym4zkbcl for ; Sat, 8 May 2010 05:47:00 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 71FF43A69BF for ; Sat, 8 May 2010 05:47:00 -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 55E132CDE057 for ; Sat, 8 May 2010 14:46:45 +0200 (CEST) From: Ladislav Lhotka To: NETCONF WG In-Reply-To: <4BE553E5.4000906@iwl.com> References: <4BE4994B.5030406@iwl.com> <1273305623.7078.35.camel@missotis> <20100508084243.GA92644@elstar.local> <1273310397.7078.61.camel@missotis> <20100508095228.GA92838@elstar.local> <1273316893.7078.101.camel@missotis> <4BE553E5.4000906@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sat, 08 May 2010 14:46:44 +0200 Message-ID: <1273322804.7078.110.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [Netconf] the real problem 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, 08 May 2010 12:47:01 -0000 Andy Bierman píše v So 08. 05. 2010 v 05:07 -0700: > Nobody has answered the relevant question. > What is the correct standard response that every > NETCONF server will give the same response: > > leaf foo { > type int32; > default 42; > } > > > > > > 42 > > > > > > If 'conceptually exists' means the same as 'exists', > then this MUST fail with a data-exists error. Yes, "the server MUST operationally behave as if the leaf was present". Of course, we have this weasel word "operationally" here, but it should include replies to operations, shouldn't it? Lada > > If it doesn't fail, and the 'create' works instead, then > what happens the 2nd time the client sends this create PDU? > Does it fail this time? It must, if the server OKed the first create PDU. > > But it can't exist, because defaults don't exist in the database. > Yet when the server reboots, the default is in the database > in an explicit-mode server. > > The same paradox exists for the 'delete' operation. > Can you delete a leaf set to its default value? > What happens when you delete a leaf with a default, but it > is not set to its default value? Does the server send > or send a 'data-missing' error? > > Does every type of defaults-handling server implement create/delete > operations the exact same way so a client can use NETCONF, > or is NETCONF an unusable mess because we can't even decide > that the create/delete operations work the same way on all nodes? > > If there is a difference between client-set-to-default > and server-set-to-default, then how does a client know > which values were set by some client, and which were set > by the server? > > > > Lada > > > > > >> specs; there have been careful wording exercises to deal with > >> this. And if you were successful, you will of course declare deployed > >> implementations non-compliant. Good luck with that. > >> > >> > >> /js > >> > >> > > > > > > > Andy > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Sat May 8 09:14: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 9F5CE3A6887 for ; Sat, 8 May 2010 09:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=-0.335, 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 DKDY1ScFm8jF for ; Sat, 8 May 2010 09:14:10 -0700 (PDT) Received: from smtp244.iad.emailsrvr.com (smtp244.iad.emailsrvr.com [207.97.245.244]) by core3.amsl.com (Postfix) with ESMTP id DA8AA3A6A3E for ; Sat, 8 May 2010 09:14:07 -0700 (PDT) Received: from relay14.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay14.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 1127B23A7AC; Sat, 8 May 2010 12:13:55 -0400 (EDT) Received: by relay14.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id BCEDD220472; Sat, 8 May 2010 12:13:54 -0400 (EDT) Message-ID: <4BE58DCC.6090406@iwl.com> Date: Sat, 08 May 2010 09:14:04 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Ladislav Lhotka References: <4BE4994B.5030406@iwl.com> <1273305623.7078.35.camel@missotis> <20100508084243.GA92644@elstar.local> <1273310397.7078.61.camel@missotis> <20100508095228.GA92838@elstar.local> <1273316893.7078.101.camel@missotis> <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> In-Reply-To: <1273322804.7078.110.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETCONF WG Subject: Re: [Netconf] the real problem 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: Sat, 08 May 2010 16:14:12 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v So 08. 05. 2010 v 05:07 -0700: > > >> Nobody has answered the relevant question. >> What is the correct standard response that every >> NETCONF server will give the same response: >> >> leaf foo { >> type int32; >> default 42; >> } >> >> >> >> >> >> 42 >> >> >> >> >> >> If 'conceptually exists' means the same as 'exists', >> then this MUST fail with a data-exists error. >> > > Yes, "the server MUST operationally behave as if the leaf was present". > Of course, we have this weasel word "operationally" here, but it should > include replies to operations, shouldn't it? > > Do the edit-config operations apply to the conceptual database or to the YANG notion of a database + defaults off to the side. I agree with you, but I am not sure the standard is clear or the entire WG agrees. So any create operation at all (doesn't have to be the schema default) on a leaf with a YANG default MUST fail with a data-exists error. If the data exists, does that imply that deleting a leaf with a YANG default MUST succeed (except for other constraint violations), even though the server will create that leaf immediately with the YANG default value? > Lada > Andy > >> If it doesn't fail, and the 'create' works instead, then >> what happens the 2nd time the client sends this create PDU? >> Does it fail this time? It must, if the server OKed the first create PDU. >> >> But it can't exist, because defaults don't exist in the database. >> Yet when the server reboots, the default is in the database >> in an explicit-mode server. >> >> The same paradox exists for the 'delete' operation. >> Can you delete a leaf set to its default value? >> What happens when you delete a leaf with a default, but it >> is not set to its default value? Does the server send >> or send a 'data-missing' error? >> >> Does every type of defaults-handling server implement create/delete >> operations the exact same way so a client can use NETCONF, >> or is NETCONF an unusable mess because we can't even decide >> that the create/delete operations work the same way on all nodes? >> >> If there is a difference between client-set-to-default >> and server-set-to-default, then how does a client know >> which values were set by some client, and which were set >> by the server? >> >> >> >>> Lada >>> >>> >>> >>>> specs; there have been careful wording exercises to deal with >>>> this. And if you were successful, you will of course declare deployed >>>> implementations non-compliant. Good luck with that. >>>> >>>> >>>> /js >>>> >>>> >>>> >>> >>> >> Andy >> >> > > > From andyb@iwl.com Sat May 8 11:49: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 6F9343A68D0 for ; Sat, 8 May 2010 11:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.992 X-Spam-Level: X-Spam-Status: No, score=-2.992 tagged_above=-999 required=5 tests=[AWL=0.607, 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 0AB9Y6W5G3Qp for ; Sat, 8 May 2010 11:49:48 -0700 (PDT) Received: from smtp124.iad.emailsrvr.com (smtp124.iad.emailsrvr.com [207.97.245.124]) by core3.amsl.com (Postfix) with ESMTP id EE8B53A68E9 for ; Sat, 8 May 2010 11:49:42 -0700 (PDT) Received: from relay32.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay32.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id E952F1B4008; Sat, 8 May 2010 14:49:30 -0400 (EDT) Received: by relay32.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 9F55B1B4003; Sat, 8 May 2010 14:49:30 -0400 (EDT) Message-ID: <4BE5B243.5070006@iwl.com> Date: Sat, 08 May 2010 11:49:39 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Ladislav Lhotka References: <4BE4994B.5030406@iwl.com> <1273305623.7078.35.camel@missotis> <20100508084243.GA92644@elstar.local> <1273310397.7078.61.camel@missotis> <20100508095228.GA92838@elstar.local> <1273316893.7078.101.camel@missotis> <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> In-Reply-To: <1273322804.7078.110.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: NETCONF WG Subject: Re: [Netconf] the real problem 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: Sat, 08 May 2010 18:49:49 -0000 Ladislav Lhotka wrote: > ... > Yes, "the server MUST operationally behave as if the leaf was present". > Of course, we have this weasel word "operationally" here, but it should > include replies to operations, shouldn't it? > > The important thing is that every NETCONF operation work the same on every server implementation. Since every server with a writable database must implement edit-config, it is important that create and delete work the same every time. There are 2 choices: 1) a default leaf is NEVER in the database (for edit purposes) 2) a default leaf is ALWAYS in the database (for edit purposes) The problem with (1) is that a basic-mode=report-all server is not required to maintain any notion of a default leaf. We already use (2) for XPath (must/when) validation purposes, so it seems consistent to do the same for editing purposes. If (1), a create on a leaf==default will work. If (2), a on a leaf==default will fail. > Lada > Andy From mbj@tail-f.com Sat May 8 13:51:22 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80D243A684A for ; Sat, 8 May 2010 13:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.368 X-Spam-Level: X-Spam-Status: No, score=0.368 tagged_above=-999 required=5 tests=[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 2F7+KM0UuPJb for ; Sat, 8 May 2010 13:51:21 -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 A9E723A67F6 for ; Sat, 8 May 2010 13:51:21 -0700 (PDT) Received: from localhost (213-65-184-138-no181.tbcn.telia.com [213.65.184.138]) by mail.tail-f.com (Postfix) with ESMTPSA id BB86E616001; Sat, 8 May 2010 22:51:08 +0200 (CEST) Date: Sat, 08 May 2010 22:51:08 +0200 (CEST) Message-Id: <20100508.225108.214646842.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4BE5B243.5070006@iwl.com> References: <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@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] the real problem 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, 08 May 2010 20:51:22 -0000 Andy Bierman wrote: > The important thing is that every NETCONF operation > work the same on every server implementation. > Since every server with a writable database > must implement edit-config, it is important that > create and delete work the same every time. Don't they work the same? If you do a get-config on the leaf and it is there, then create will fail. If it is not there, create will succeed (*). The difference is that if you create the parent node, the result of a following get-config will be different, but that is expected. A client can adapt by checking the basic-mode. (*) the weird thing is that in trim mode, create with a value that matches the default value is a noop, and in report-all mode delete on a leaf with default is a noop. Remember that we're trying to support 3 modes that we know that existing devices use today. /martin From andyb@iwl.com Sat May 8 14:21: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 23F803A6890 for ; Sat, 8 May 2010 14:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.782 X-Spam-Level: X-Spam-Status: No, score=-0.782 tagged_above=-999 required=5 tests=[AWL=-0.376, 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 jqGXIlNMkZtO for ; Sat, 8 May 2010 14:21:56 -0700 (PDT) Received: from smtp174.dfw.emailsrvr.com (smtp174.dfw.emailsrvr.com [67.192.241.174]) by core3.amsl.com (Postfix) with ESMTP id B423B3A6853 for ; Sat, 8 May 2010 14:21:44 -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 79506CE5E60; Sat, 8 May 2010 17:21:32 -0400 (EDT) Received: by relay7.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 37FC3CE5E4C; Sat, 8 May 2010 17:21:32 -0400 (EDT) Message-ID: <4BE5D5E7.3040708@iwl.com> Date: Sat, 08 May 2010 14:21:43 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Bjorklund References: <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> In-Reply-To: <20100508.225108.214646842.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] the real problem 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: Sat, 08 May 2010 21:21:57 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: > >> The important thing is that every NETCONF operation >> work the same on every server implementation. >> Since every server with a writable database >> must implement edit-config, it is important that >> create and delete work the same every time. >> > > Don't they work the same? If you do a get-config on the leaf and it > is there, then create will fail. If it is not there, create will > succeed (*). The difference is that if you create the parent node, > the result of a following get-config will be different, but that is > expected. A client can adapt by checking the basic-mode. > > So now you have to do a get-config first to know if a top-level leaf is there or not? The YANG draft did not make this clear. Also, unless the server implements the :with-defaults capability, it does not have to adhere to any particular basic-mode for defaults handling. > (*) the weird thing is that in trim mode, create with a value that > matches the default value is a noop, and in report-all mode delete on > a leaf with default is a noop. > > > Remember that we're trying to support 3 modes that we know that > existing devices use today. > I don't see how a client-set-default can exist in the database according to the YANG spec. It clearly says that defaults do not exist in any database. That clearly means that the create operation MUST always succeed on a leaf that contains the default value, since it cannot be a default and also be included in a YANG defined NETCONF database. Either that, or the edit-config works on a conceptual database (like must-stmt) so the create operation does not change if the leaf happens to contain a default, or happens to be implemented as a place-holder instead of a real leaf. > > /martin > > Andy From mbj@tail-f.com Sat May 8 14:39:32 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 8F92E3A68CD for ; Sat, 8 May 2010 14:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.461 X-Spam-Level: X-Spam-Status: No, score=0.461 tagged_above=-999 required=5 tests=[AWL=-0.093, 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 I9VeTR3OOKK1 for ; Sat, 8 May 2010 14:39:31 -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 6A8913A688C for ; Sat, 8 May 2010 14:39:31 -0700 (PDT) Received: from localhost (213-65-184-138-no181.tbcn.telia.com [213.65.184.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 339FC616001; Sat, 8 May 2010 23:39:19 +0200 (CEST) Date: Sat, 08 May 2010 23:39:18 +0200 (CEST) Message-Id: <20100508.233918.107180567.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4BE5D5E7.3040708@iwl.com> References: <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <4BE5D5E7.3040708@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] the real problem 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, 08 May 2010 21:39:32 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > > > >> The important thing is that every NETCONF operation > >> work the same on every server implementation. > >> Since every server with a writable database > >> must implement edit-config, it is important that > >> create and delete work the same every time. > >> > > > > Don't they work the same? If you do a get-config on the leaf and it > > is there, then create will fail. If it is not there, create will > > succeed (*). The difference is that if you create the parent node, > > the result of a following get-config will be different, but that is > > expected. A client can adapt by checking the basic-mode. > > > > > > So now you have to do a get-config first to know > if a top-level leaf is there or not? The YANG draft > did not make this clear. This has nothing to do with YANG; this is what we get from trying to support the three modes in the with-defaults spec. > Also, unless the server implements the :with-defaults > capability, it does not have to adhere to any particular > basic-mode for defaults handling. Right, and that problem is what with-defaults is trying to solve, and this is why we recommend that implementations support with-defaults. > > (*) the weird thing is that in trim mode, create with a value that > > matches the default value is a noop, and in report-all mode delete on > > a leaf with default is a noop. > > > > > > Remember that we're trying to support 3 modes that we know that > > existing devices use today. > > > > I don't see how a client-set-default can exist in the database > according to the YANG spec. It clearly says that defaults > do not exist in any database. It says: The default value of a leaf is the value that the server uses if the leaf does not exist in the data tree. But it does not prohibit a report-all server to *create* the leaf, with the default value found in the YANG module as the value. But after that the leaf exists in the data tree, just as any other leaf. And it does not prohibit a client to set the leaf with a value that happens to be the default value found in the YANG module. > That clearly means that > the create operation MUST always succeed on a leaf that > contains the default value, since it cannot be a default > and also be included in a YANG defined NETCONF database. How do you know if a leaf contains the deafault value -- you do a get-config. In all modes, if the reply contains the default value you cannot create it (of course in trim mode it will enever contain the default value...) /martin From andyb@iwl.com Sat May 8 14:56: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 27B5B3A6990 for ; Sat, 8 May 2010 14:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[AWL=-0.715, 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 4xT50rvyHu+7 for ; Sat, 8 May 2010 14:56:30 -0700 (PDT) Received: from smtp184.iad.emailsrvr.com (smtp184.iad.emailsrvr.com [207.97.245.184]) by core3.amsl.com (Postfix) with ESMTP id 2F6203A68D0 for ; Sat, 8 May 2010 14:56:30 -0700 (PDT) Received: from relay18.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay18.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 7E5C91B402A; Sat, 8 May 2010 17:56:17 -0400 (EDT) Received: by relay18.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id F03821B4010; Sat, 8 May 2010 17:56:16 -0400 (EDT) Message-ID: <4BE5DE0C.5090901@iwl.com> Date: Sat, 08 May 2010 14:56:28 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Bjorklund References: <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <4BE5D5E7.3040708@iwl.com> <20100508.233918.107180567.mbj@tail-f.com> In-Reply-To: <20100508.233918.107180567.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] the real problem 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: Sat, 08 May 2010 21:56:31 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: > >> Martin Bjorklund wrote: >> >>> Andy Bierman wrote: >>> >>> >>>> The important thing is that every NETCONF operation >>>> work the same on every server implementation. >>>> Since every server with a writable database >>>> must implement edit-config, it is important that >>>> create and delete work the same every time. >>>> >>>> >>> Don't they work the same? If you do a get-config on the leaf and it >>> is there, then create will fail. If it is not there, create will >>> succeed (*). The difference is that if you create the parent node, >>> the result of a following get-config will be different, but that is >>> expected. A client can adapt by checking the basic-mode. >>> >>> >>> >> So now you have to do a get-config first to know >> if a top-level leaf is there or not? The YANG draft >> did not make this clear. >> > > This has nothing to do with YANG; this is what we get from trying to > support the three modes in the with-defaults spec. > > >> Also, unless the server implements the :with-defaults >> capability, it does not have to adhere to any particular >> basic-mode for defaults handling. >> > > Right, and that problem is what with-defaults is trying to solve, and > this is why we recommend that implementations support with-defaults. > > >>> (*) the weird thing is that in trim mode, create with a value that >>> matches the default value is a noop, and in report-all mode delete on >>> a leaf with default is a noop. >>> >>> >>> Remember that we're trying to support 3 modes that we know that >>> existing devices use today. >>> >>> >> I don't see how a client-set-default can exist in the database >> according to the YANG spec. It clearly says that defaults >> do not exist in any database. >> > > It says: > > The default value of a leaf is the value that the server uses if the > leaf does not exist in the data tree. > > It also says: When the default value is in use, the server MUST operationally behave as is if the leaf was present in the data tree with the default value as its value. This would lead people like Lada to believe that the server MUST reject a create on a default value in use. > But it does not prohibit a report-all server to *create* the leaf, > with the default value found in the YANG module as the value. But > after that the leaf exists in the data tree, just as any other leaf. > > And it does not prohibit a client to set the leaf with a value that > happens to be the default value found in the YANG module. > > >> That clearly means that >> the create operation MUST always succeed on a leaf that >> contains the default value, since it cannot be a default >> and also be included in a YANG defined NETCONF database. >> > > How do you know if a leaf contains the deafault value -- you do a > get-config. In all modes, if the reply contains the default value you > cannot create it (of course in trim mode it will enever contain the > default value...) > I can live with this solution, but I don't think the YANG text supports it. The with-defaults draft also needs to say that the server MUST NOT change its basic-mode while any sessions are active (skirt the capability-changed as optional issue). > > /martin > > Andy From mbj@tail-f.com Sat May 8 15:04: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 A1A073A68D0 for ; Sat, 8 May 2010 15:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.508 X-Spam-Level: X-Spam-Status: No, score=0.508 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 Y4ZCULzO8NgK for ; Sat, 8 May 2010 15:04: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 B01C53A693A for ; Sat, 8 May 2010 15:04:22 -0700 (PDT) Received: from localhost (213-65-184-138-no181.tbcn.telia.com [213.65.184.138]) by mail.tail-f.com (Postfix) with ESMTPSA id E564F616001; Sun, 9 May 2010 00:04:09 +0200 (CEST) Date: Sun, 09 May 2010 00:04:09 +0200 (CEST) Message-Id: <20100509.000409.257202289.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4BE5DE0C.5090901@iwl.com> References: <4BE5D5E7.3040708@iwl.com> <20100508.233918.107180567.mbj@tail-f.com> <4BE5DE0C.5090901@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] the real problem 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, 08 May 2010 22:04:23 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > > > >> Martin Bjorklund wrote: > >>> Remember that we're trying to support 3 modes that we know that > >>> existing devices use today. > >>> > >>> > >> I don't see how a client-set-default can exist in the database > >> according to the YANG spec. It clearly says that defaults > >> do not exist in any database. > >> > > > > It says: > > > > The default value of a leaf is the value that the server uses if the > > leaf does not exist in the data tree. > > > > > > It also says: > > > When the default value is in use, the server MUST operationally > behave as is if the leaf was present in the data tree with the > default value as its value. > > This would lead people like Lada to believe that the server > MUST reject a create on a default value in use. I thought we agreed on the "operationally behave" text, but if it isn't clear, what can we write instead? > > How do you know if a leaf contains the deafault value -- you do a > > get-config. In all modes, if the reply contains the default value you > > cannot create it (of course in trim mode it will enever contain the > > default value...) > > > > I can live with this solution, but I don't think the > YANG text supports it. Because of the "operationally behave" text, or something else? > The with-defaults draft also needs to say that the server MUST NOT > change its basic-mode while any sessions are active (skirt > the capability-changed as optional issue). Ok. /martin From andyb@iwl.com Sat May 8 16:29: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 1C7763A693A for ; Sat, 8 May 2010 16:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.703 X-Spam-Level: X-Spam-Status: No, score=-1.703 tagged_above=-999 required=5 tests=[AWL=0.562, 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 feO-0osFwDpY for ; Sat, 8 May 2010 16:29:42 -0700 (PDT) Received: from smtp114.dfw.emailsrvr.com (smtp114.dfw.emailsrvr.com [67.192.241.114]) by core3.amsl.com (Postfix) with ESMTP id 5593A3A67F5 for ; Sat, 8 May 2010 16:29:42 -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 3BD912E401A2; Sat, 8 May 2010 19:29:30 -0400 (EDT) Received: by relay21.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id F0D892E400C5; Sat, 8 May 2010 19:29:29 -0400 (EDT) Message-ID: <4BE5F3E6.8000904@iwl.com> Date: Sat, 08 May 2010 16:29:42 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Bjorklund References: <4BE5D5E7.3040708@iwl.com> <20100508.233918.107180567.mbj@tail-f.com> <4BE5DE0C.5090901@iwl.com> <20100509.000409.257202289.mbj@tail-f.com> In-Reply-To: <20100509.000409.257202289.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] the real problem 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: Sat, 08 May 2010 23:29:43 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: > >> Martin Bjorklund wrote: >> >>> Andy Bierman wrote: >>> >>> >>>> Martin Bjorklund wrote: >>>> >>>>> Remember that we're trying to support 3 modes that we know that >>>>> existing devices use today. >>>>> >>>>> >>>>> >>>> I don't see how a client-set-default can exist in the database >>>> according to the YANG spec. It clearly says that defaults >>>> do not exist in any database. >>>> >>>> >>> It says: >>> >>> The default value of a leaf is the value that the server uses if the >>> leaf does not exist in the data tree. >>> >>> >>> >> It also says: >> >> >> When the default value is in use, the server MUST operationally >> behave as is if the leaf was present in the data tree with the >> default value as its value. >> >> This would lead people like Lada to believe that the server >> MUST reject a create on a default value in use. >> > > I thought we agreed on the "operationally behave" text, but if it > isn't clear, what can we write instead? > > I don't know what text you thought we all agreed on. I know what the draft says now, and the text 'MUST operationally behave' sure sounds to me like it applies to all protocol operations. If it only applied to get-config, it would say that, but it doesn't. I think we need a definition of 'operational behavior' in the terminology section, and the IETF needs to agree on its meaning, if it doesn't mean all protocol operations. >>> How do you know if a leaf contains the deafault value -- you do a >>> get-config. In all modes, if the reply contains the default value you >>> cannot create it (of course in trim mode it will enever contain the >>> default value...) >>> >>> >> I can live with this solution, but I don't think the >> YANG text supports it. >> > > Because of the "operationally behave" text, or something else? > > >> The with-defaults draft also needs to say that the server MUST NOT >> change its basic-mode while any sessions are active (skirt >> the capability-changed as optional issue). >> > > Ok. > > > /martin > > Andy From j.schoenwaelder@jacobs-university.de Sun May 9 03:02: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 4B43F3A6896 for ; Sun, 9 May 2010 03:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.115 X-Spam-Level: X-Spam-Status: No, score=0.115 tagged_above=-999 required=5 tests=[AWL=-0.236, 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 nz6lG0J6gcZA for ; Sun, 9 May 2010 03:02:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3C42D3A6872 for ; Sun, 9 May 2010 03:02:44 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2E715C0036; Sun, 9 May 2010 12:02:32 +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 Ycqadc1nEGD5; Sun, 9 May 2010 12:02:30 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24475C0009; Sun, 9 May 2010 12:02:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6E3F31200871; Sun, 9 May 2010 12:02:29 +0200 (CEST) Date: Sun, 9 May 2010 12:02:28 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100509100228.GA281@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netconf@ietf.org" References: <4BE5D5E7.3040708@iwl.com> <20100508.233918.107180567.mbj@tail-f.com> <4BE5DE0C.5090901@iwl.com> <20100509.000409.257202289.mbj@tail-f.com> <4BE5F3E6.8000904@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BE5F3E6.8000904@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] the real problem 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: Sun, 09 May 2010 10:02:46 -0000 On Sun, May 09, 2010 at 01:29:42AM +0200, Andy Bierman wrote: > I don't know what text you thought we all agreed on. > I know what the draft says now, and the text > 'MUST operationally behave' sure sounds to me > like it applies to all protocol operations. > If it only applied to get-config, it would > say that, but it doesn't. > > I think we need a definition of 'operational behavior' > in the terminology section, and the IETF needs to > agree on its meaning, if it doesn't mean all > protocol operations. To me, 'operationally behave' has nothing to do with NETCONF protocol operations per se. If I have container vt220 { color { type enum { enum green; enum amber; } default green; } } and vt220/color does not exist in explicit config, then the termial will use green color. It operationally behaves as if the vt220/color data node would exist and have the value green. In other words, there is no config state, just operational state. If we would know how to deal with operational state in general, I believe defaults would fall out naturally. (And one option could be to have a get kind of operation that returns the union of config state and operational state and tagging might help to distinguish data nodes representing config and operational state. Another alternative could be separate get kind of operations that just retrieve operational state. Yet another alternative is to introduce another special datastore to access operational state. And I believe we discussed even more ideas in the past.) The question is whether people here are willing to solve the underlying problem or just defaults, postponing the other question until it pops up when people write data models that need to deal with mixtures of operational and config states, e.g. forwarding and routing tables as prominent examples. /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 Sun May 9 06:43:13 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B36D83A694E for ; Sun, 9 May 2010 06:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[AWL=-0.750, 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 OIFw5VlYTp7b for ; Sun, 9 May 2010 06:43:13 -0700 (PDT) Received: from smtp134.dfw.emailsrvr.com (smtp134.dfw.emailsrvr.com [67.192.241.134]) by core3.amsl.com (Postfix) with ESMTP id 85F803A69A1 for ; Sun, 9 May 2010 06:43:11 -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 DA28B156A50D; Sun, 9 May 2010 09:42:59 -0400 (EDT) Received: by relay23.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id A9F90156A506; Sun, 9 May 2010 09:42:59 -0400 (EDT) Message-ID: <4BE6BBF4.8030305@iwl.com> Date: Sun, 09 May 2010 06:43:16 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Bjorklund , "netconf@ietf.org" References: <4BE5D5E7.3040708@iwl.com> <20100508.233918.107180567.mbj@tail-f.com> <4BE5DE0C.5090901@iwl.com> <20100509.000409.257202289.mbj@tail-f.com> <4BE5F3E6.8000904@iwl.com> <20100509100228.GA281@elstar.local> In-Reply-To: <20100509100228.GA281@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] the real problem 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: Sun, 09 May 2010 13:43:13 -0000 Juergen Schoenwaelder wrote: > On Sun, May 09, 2010 at 01:29:42AM +0200, Andy Bierman wrote: > > >> I don't know what text you thought we all agreed on. >> I know what the draft says now, and the text >> 'MUST operationally behave' sure sounds to me >> like it applies to all protocol operations. >> If it only applied to get-config, it would >> say that, but it doesn't. >> >> I think we need a definition of 'operational behavior' >> in the terminology section, and the IETF needs to >> agree on its meaning, if it doesn't mean all >> protocol operations. >> > > To me, 'operationally behave' has nothing to do with NETCONF protocol > operations per se. If I have > > container vt220 { > color { > type enum { enum green; enum amber; } > default green; > } > } > > and vt220/color does not exist in explicit config, then the termial > will use green color. It operationally behaves as if the vt220/color > data node would exist and have the value green. In other words, there > is no config state, just operational state. > > If we would know how to deal with operational state in general, I > believe defaults would fall out naturally. (And one option could be to > have a get kind of operation that returns the union of config state > and operational state and tagging might help to distinguish data nodes > representing config and operational state. Another alternative could > be separate get kind of operations that just retrieve operational > state. Yet another alternative is to introduce another special > datastore to access operational state. And I believe we > discussed even more ideas in the past.) The question is whether people > here are willing to solve the underlying problem or just defaults, > postponing the other question until it pops up when people write data > models that need to deal with mixtures of operational and config > states, e.g. forwarding and routing tables as prominent examples. > > Why can't your example be config? I had an old monitor with an 'amber/green' switch about 20 years ago. I controlled the color. That makes it config, not operational state. The issue is the text the Lada and I pointed out in the section about default leafs. It clearly says 'operationally behave' as if the leaf exists. Rather than start all until we have a solution that happens to fit a poorly defined 'explicit' config, we need to clarify how create and delete operations are expected to work in the standard, given the normative text that exists. > /js > > Andy From mbj@tail-f.com Sun May 9 06: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 5F6553A6921 for ; Sun, 9 May 2010 06:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.237 X-Spam-Level: X-Spam-Status: No, score=0.237 tagged_above=-999 required=5 tests=[AWL=-0.317, 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 5nJM6hDjCXOb for ; Sun, 9 May 2010 06:53:30 -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 8BE603A6985 for ; Sun, 9 May 2010 06:53:30 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 154C376C06A; Sun, 9 May 2010 15:53:18 +0200 (CEST) Date: Sun, 09 May 2010 15:53:17 +0200 (CEST) Message-Id: <20100509.155317.266095199.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4BE5F3E6.8000904@iwl.com> References: <4BE5DE0C.5090901@iwl.com> <20100509.000409.257202289.mbj@tail-f.com> <4BE5F3E6.8000904@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] the real problem 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: Sun, 09 May 2010 13:53:31 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > > > >> Martin Bjorklund wrote: > >> > >>> Andy Bierman wrote: > >>> > >>> > >>>> Martin Bjorklund wrote: > >>>> > >>>>> Remember that we're trying to support 3 modes that we know that > >>>>> existing devices use today. > >>>>> > >>>>> > >>>>> > >>>> I don't see how a client-set-default can exist in the database > >>>> according to the YANG spec. It clearly says that defaults > >>>> do not exist in any database. > >>>> > >>>> > >>> It says: > >>> > >>> The default value of a leaf is the value that the server uses if the > >>> leaf does not exist in the data tree. > >>> > >>> > >>> > >> It also says: > >> > >> > >> When the default value is in use, the server MUST operationally > >> behave as is if the leaf was present in the data tree with the > >> default value as its value. > >> > >> This would lead people like Lada to believe that the server > >> MUST reject a create on a default value in use. > >> > > > > I thought we agreed on the "operationally behave" text, but if it > > isn't clear, what can we write instead? > > > > > > I don't know what text you thought we all agreed on. This was part of the looong "meaning of default" threads. > I know what the draft says now, and the text > 'MUST operationally behave' sure sounds to me > like it applies to all protocol operations. Before "operationally behave" we had "internally use" or something similar. Do we have a common term that refers to the application code / instrumentation code behind the NETCONF server on the device? The intention of the text is to say that this code (the application on the device that is being configured), MUST behave as if the leaf was explicitly set to its default value, even if it is not there in the config. /martin From andyb@iwl.com Sun May 9 08:05: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 59C9F3A691B for ; Sun, 9 May 2010 08:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.492 X-Spam-Level: X-Spam-Status: No, score=-0.492 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_40=-0.185, 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 xfpB-gbm9X7h for ; Sun, 9 May 2010 08:05:57 -0700 (PDT) Received: from smtp204.dfw.emailsrvr.com (smtp204.dfw.emailsrvr.com [67.192.241.204]) by core3.amsl.com (Postfix) with ESMTP id 8001C3A69D4 for ; Sun, 9 May 2010 08:05:57 -0700 (PDT) Received: from relay20.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay20.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id DF0F5212831B; Sun, 9 May 2010 11:05:45 -0400 (EDT) Received: by relay20.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id A1F182128250; Sun, 9 May 2010 11:05:45 -0400 (EDT) Message-ID: <4BE6CF5A.3000008@iwl.com> Date: Sun, 09 May 2010 08:06:02 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Bjorklund References: <4BE5DE0C.5090901@iwl.com> <20100509.000409.257202289.mbj@tail-f.com> <4BE5F3E6.8000904@iwl.com> <20100509.155317.266095199.mbj@tail-f.com> In-Reply-To: <20100509.155317.266095199.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] the real problem 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: Sun, 09 May 2010 15:05:58 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: > >> Martin Bjorklund wrote: >> >>> Andy Bierman wrote: >>> >>> >>>> Martin Bjorklund wrote: >>>> >>>> >>>>> Andy Bierman wrote: >>>>> >>>>> >>>>> >>>>>> Martin Bjorklund wrote: >>>>>> >>>>>> >>>>>>> Remember that we're trying to support 3 modes that we know that >>>>>>> existing devices use today. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> I don't see how a client-set-default can exist in the database >>>>>> according to the YANG spec. It clearly says that defaults >>>>>> do not exist in any database. >>>>>> >>>>>> >>>>>> >>>>> It says: >>>>> >>>>> The default value of a leaf is the value that the server uses if the >>>>> leaf does not exist in the data tree. >>>>> >>>>> >>>>> >>>>> >>>> It also says: >>>> >>>> >>>> When the default value is in use, the server MUST operationally >>>> behave as is if the leaf was present in the data tree with the >>>> default value as its value. >>>> >>>> This would lead people like Lada to believe that the server >>>> MUST reject a create on a default value in use. >>>> >>>> >>> I thought we agreed on the "operationally behave" text, but if it >>> isn't clear, what can we write instead? >>> >>> >>> >> I don't know what text you thought we all agreed on. >> > > This was part of the looong "meaning of default" threads. > > >> I know what the draft says now, and the text >> 'MUST operationally behave' sure sounds to me >> like it applies to all protocol operations. >> > > Before "operationally behave" we had "internally use" or something > similar. > > Do we have a common term that refers to the application code / > instrumentation code behind the NETCONF server on the device? The > intention of the text is to say that this code (the application on the > device that is being configured), MUST behave as if the leaf was > explicitly set to its default value, even if it is not there in the > config. > > Why doesn't it refer to the NETCONF protocol operations? I think the text should say "server instrumentation behaves", not "operationally behaves". I also think the draft does not make it clear that a server MAY choose to store a default in the database (or rather its external XML representation). I suppose the answer for all the standards fragility is "Just use merge. Create is picky. Merge isn't." > /martin > > Andy From j.schoenwaelder@jacobs-university.de Sun May 9 23:34:01 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463343A6B2C for ; Sun, 9 May 2010 23:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.618 X-Spam-Level: X-Spam-Status: No, score=0.618 tagged_above=-999 required=5 tests=[AWL=-0.732, BAYES_60=1, 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 KaifPvYFiuU3 for ; Sun, 9 May 2010 23:34:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A41E73A6B17 for ; Sun, 9 May 2010 23:33:52 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0FD62C0014; Mon, 10 May 2010 08:33:41 +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 52ZtHRJX03ax; Mon, 10 May 2010 08:33:39 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6BC73C0009; Mon, 10 May 2010 08:33:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2DF591202344; Mon, 10 May 2010 08:33:39 +0200 (CEST) Date: Mon, 10 May 2010 08:33:39 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100510063339.GB1829@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netconf@ietf.org" References: <4BE5D5E7.3040708@iwl.com> <20100508.233918.107180567.mbj@tail-f.com> <4BE5DE0C.5090901@iwl.com> <20100509.000409.257202289.mbj@tail-f.com> <4BE5F3E6.8000904@iwl.com> <20100509100228.GA281@elstar.local> <4BE6BBF4.8030305@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BE6BBF4.8030305@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] the real problem 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: Mon, 10 May 2010 06:34:01 -0000 On Sun, May 09, 2010 at 03:43:16PM +0200, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Sun, May 09, 2010 at 01:29:42AM +0200, Andy Bierman wrote: > > > > > >> I don't know what text you thought we all agreed on. > >> I know what the draft says now, and the text > >> 'MUST operationally behave' sure sounds to me > >> like it applies to all protocol operations. > >> If it only applied to get-config, it would > >> say that, but it doesn't. > >> > >> I think we need a definition of 'operational behavior' > >> in the terminology section, and the IETF needs to > >> agree on its meaning, if it doesn't mean all > >> protocol operations. > >> > > > > To me, 'operationally behave' has nothing to do with NETCONF protocol > > operations per se. If I have > > > > container vt220 { > > color { > > type enum { enum green; enum amber; } > > default green; > > } > > } > > > > and vt220/color does not exist in explicit config, then the termial > > will use green color. It operationally behaves as if the vt220/color > > data node would exist and have the value green. In other words, there > > is no config state, just operational state. > > > > If we would know how to deal with operational state in general, I > > believe defaults would fall out naturally. (And one option could be to > > have a get kind of operation that returns the union of config state > > and operational state and tagging might help to distinguish data nodes > > representing config and operational state. Another alternative could > > be separate get kind of operations that just retrieve operational > > state. Yet another alternative is to introduce another special > > datastore to access operational state. And I believe we > > discussed even more ideas in the past.) The question is whether people > > here are willing to solve the underlying problem or just defaults, > > postponing the other question until it pops up when people write data > > models that need to deal with mixtures of operational and config > > states, e.g. forwarding and routing tables as prominent examples. > > > > > Why can't your example be config? If can, but without explicit config, the system will choose green color. > I had an old monitor with an 'amber/green' switch > about 20 years ago. I controlled the color. > That makes it config, not operational state. Sorry for picking an example that does not match your old monitor. > The issue is the text the Lada and I pointed out > in the section about default leafs. It clearly > says 'operationally behave' as if the leaf exists. I tried to explain what "operationally behave" means, look like I failed. > Rather than start all until we have a solution > that happens to fit a poorly defined 'explicit' config, > we need to clarify how create and delete operations > are expected to work in the standard, given the normative > text that exists. Look at your favourite server software and chances are good that if you leave out explicit config in the config file, it will pick a default value. Explicit config models this config file approach which has worked for 20+ years. You may call this 'poorly designed' - thats your choice. /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 Sun May 9 23:42:21 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 561723A6B32 for ; Sun, 9 May 2010 23:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.102 X-Spam-Level: * X-Spam-Status: No, score=1.102 tagged_above=-999 required=5 tests=[AWL=-0.248, 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 I3FBR+OssbUw for ; Sun, 9 May 2010 23:42:20 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7A8433A6B4F for ; Sun, 9 May 2010 23:41:38 -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 2DCC42CDE057; Mon, 10 May 2010 08:41:26 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20100508.225108.214646842.mbj@tail-f.com> References: <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 10 May 2010 08:41:25 +0200 Message-ID: <1273473685.1752.62.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] the real problem 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: Mon, 10 May 2010 06:42:21 -0000 Martin Bjorklund píše v So 08. 05. 2010 v 22:51 +0200: > Andy Bierman wrote: > > The important thing is that every NETCONF operation > > work the same on every server implementation. > > Since every server with a writable database > > must implement edit-config, it is important that > > create and delete work the same every time. > > Don't they work the same? If you do a get-config on the leaf and it No, there are subtle differences in their behaviour. > is there, then create will fail. If it is not there, create will > succeed (*). The difference is that if you create the parent node, But as you write in (*) below, *repeated* creation of the same leaf with the default value will succeed for the trim mode and fail for the explicit mode. > the result of a following get-config will be different, but that is > expected. A client can adapt by checking the basic-mode. > > (*) the weird thing is that in trim mode, create with a value that > matches the default value is a noop, and in report-all mode delete on > a leaf with default is a noop. > > Remember that we're trying to support 3 modes that we know that > existing devices use today. My understanding so far was that we agreed the conceptual data tree contains all "active" configuration data (that are also used in XPath evaluations), i.e., including default values. The sentence When the default value is in use, the server MUST operationally behave as if the leaf was present in the data tree with the default value as its value. then makes perfect sense to me. I believe servers operating in all three default-handling modes could easily accommodate to this "mental" model and behave identically while keeping the internal representation of their database. The trim- and explicit-mode servers would have to keep an eye on the data model though, so it may require adjustments to the behaviour of *existing* server implementations. This is, I guess, the reason that we are not able to come to a real consensus after all the long discussions. However, allowing server implementors to work with different contents of the *conceptual* data tree really means that the behaviour will differ, too. If it was allowed, the servers MUST report their basic-mode of defaults handling and this should be stated in 4741bis. The client cannot learn about the server's mode simply by getting the configuration (once), it would have to perform some experiments. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From bertietf@bwijnen.net Mon May 10 04:57: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 865FD28C189 for ; Mon, 10 May 2010 04:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[AWL=-0.798, 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 HpG7oMwIe4Bw for ; Mon, 10 May 2010 04:57:57 -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 E15B63A68E7 for ; Mon, 10 May 2010 04:57:56 -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 1OBRcA-0002wK-O2 for netconf@ietf.org; Mon, 10 May 2010 13:57:44 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-93.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OBRcA-0002Jc-Gn for netconf@ietf.org; Mon, 10 May 2010 13:57:38 +0200 Message-ID: <4BE7F4B2.5060602@bwijnen.net> Date: Mon, 10 May 2010 13:57:38 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: netconf@ietf.org References: <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <1273473685.1752.62.camel@missotis> In-Reply-To: <1273473685.1752.62.camel@missotis> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd42d37d78a267474a3ce93cd09035753b9 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd42d37d78a267474a3ce93cd09035753b9 Subject: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 11:57:58 -0000 WG participants, I have now read the postings of the last week twice. I can't say that I am reading any consensus. I also can't say that all the arguments that have seen used are 100% clear to me (but that is because I am far less versed in this material than the implementers). In fact, it seems to me, that we clearly interpret the text related to "defaults" and with-defaults" differently. And that is... the people who actually developed the text and have implemented most (if not all of it). If even those people have different interpretations, what does that mean for someone new who must implement this? Or someone new who needs to write a data model using YANG? --- There was also discussion on merging all (or part of) with-defaults with 4741bis. Again no clear consensus, although there I would be ready to conclude (WG chair reading of the discussions) that I think that there is enough support to stick to our charter and deliver the documents as described there. Or better, that I do not see enough support to actually deviate from hat weagreed upon in the charter. So no merging. --- But I am reluctant to declare we have clarity and consensus on the whole defaults/with-defaults story at this point in time. --- As was stated a few times, we thought we reached consensus on this quite a while ago. It seems that the way we documented it is not clear enough. Is anyone ready to do a comprehensive proposal as to what text should be changed or added in order to try to see if we can agree on such changes? Bert From lhotka@cesnet.cz Mon May 10 05:35: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 66A063A6BB8 for ; Mon, 10 May 2010 05:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.11 X-Spam-Level: * X-Spam-Status: No, score=1.11 tagged_above=-999 required=5 tests=[AWL=-0.240, 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 6tBIsxF6s1X0 for ; Mon, 10 May 2010 05:35:49 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4F58C28C1E0 for ; Mon, 10 May 2010 05:27:51 -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 95B092CDE058; Mon, 10 May 2010 14:27:39 +0200 (CEST) From: Ladislav Lhotka To: "Bert (IETF) Wijnen" In-Reply-To: <4BE7F4B2.5060602@bwijnen.net> References: <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <1273473685.1752.62.camel@missotis> <4BE7F4B2.5060602@bwijnen.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 10 May 2010 14:27:38 +0200 Message-ID: <1273494458.1752.157.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 12:35:50 -0000 Bert (IETF) Wijnen píše v Po 10. 05. 2010 v 13:57 +0200: > WG participants, I have now read the postings of the last week twice. > > I can't say that I am reading any consensus. I also can't say that all > the arguments > that have seen used are 100% clear to me (but that is because I am far > less versed > in this material than the implementers). > > In fact, it seems to me, that we clearly interpret the text related to > "defaults" and with-defaults" > differently. And that is... the people who actually developed the text > and have implemented > most (if not all of it). If even those people have different > interpretations, what does that mean > for someone new who must implement this? Or someone new who needs to > write a > data model using YANG? It may help to think of it in terms of the model-view-controller paradigm. The conceptual data tree is the model and "trim", "explicit" and "report-all" styles are different views of the model. The "controller" part are then the NETCONF operations. In my view, the operations can work consistently for all implementations only if the model is the same for everybody, so an agreement on a common model is IMO badly needed but has never happened. It needn't be the "report-all" style, but since this style is already used in YANG for XPath evaluations, it seems to be a good candidate. Lada > > --- > > There was also discussion on merging all (or part of) with-defaults with > 4741bis. > Again no clear consensus, although there I would be ready to conclude > (WG chair > reading of the discussions) that I think that there is enough support to > stick to our charter > and deliver the documents as described there. Or better, that I do not > see enough support > to actually deviate from hat weagreed upon in the charter. So no merging. > > --- > > But I am reluctant to declare we have clarity and consensus on the whole > defaults/with-defaults > story at this point in time. > > --- > > As was stated a few times, we thought we reached consensus on this quite > a while ago. > It seems that the way we documented it is not clear enough. > > Is anyone ready to do a comprehensive proposal as to what text should be > changed or added > in order to try to see if we can agree on such changes? > > Bert > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon May 10 07:08: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 5D6C33A69A1 for ; Mon, 10 May 2010 07:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.131 X-Spam-Level: X-Spam-Status: No, score=0.131 tagged_above=-999 required=5 tests=[AWL=-0.220, 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 PXYgOR8HaZjt for ; Mon, 10 May 2010 07:08: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 460243A6963 for ; Mon, 10 May 2010 07:08:56 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9AA98C0018; Mon, 10 May 2010 16:08:44 +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 nIB5uQ1bMdQl; Mon, 10 May 2010 16:08: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 4B0B2C0015; Mon, 10 May 2010 16:08:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5C6E412038DF; Mon, 10 May 2010 16:08:41 +0200 (CEST) Date: Mon, 10 May 2010 16:08:40 +0200 From: Juergen Schoenwaelder To: "Bert (IETF) Wijnen" Message-ID: <20100510140840.GA3760@elstar.local> Mail-Followup-To: "Bert (IETF) Wijnen" , "netconf@ietf.org" References: <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <1273473685.1752.62.camel@missotis> <4BE7F4B2.5060602@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BE7F4B2.5060602@bwijnen.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 14:08:57 -0000 On Mon, May 10, 2010 at 01:57:38PM +0200, Bert (IETF) Wijnen wrote: > --- > > There was also discussion on merging all (or part of) with-defaults > with 4741bis. Again no clear consensus, although there I would be > ready to conclude (WG chair reading of the discussions) that I think > that there is enough support to stick to our charter and deliver the > documents as described there. Or better, that I do not see enough > support to actually deviate from hat weagreed upon in the > charter. So no merging. I continue to believe that it is a bug that 4741 does not tell a client what it does wrt defaults and I would prefer that if we can avoid that with 4741bis clients. The current with-defaults ID as such might not be implemented because it does more than just announcing the behaviour and thus does not solve the problem. > --- > > But I am reluctant to declare we have clarity and consensus on the > whole defaults/with-defaults story at this point in time. And this is why a decision to stick to the charter is IMHO premature. Lada, for example, made a proposal to move the with-defaults behaviour announcement to 4741bis while keeping the additional argument for operations in the with-defaults document. We should not rule out this option. (But perhaps this also was not your intention, but this is unclear.) > --- > > As was stated a few times, we thought we reached consensus on this > quite a while ago. It seems that the way we documented it is not > clear enough. > > Is anyone ready to do a comprehensive proposal as to what text > should be changed or added in order to try to see if we can agree on > such changes? Perhaps the concensus was not clear or it was only clear up to the point where some implementors decided what is in the extra document does not need to be implemented - so they can have concensus by ignoring it. Not sure this is what we want at the end. /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 Mon May 10 07:18: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 2DACA3A6916 for ; Mon, 10 May 2010 07:18:32 -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 nt+fpE8dSMDt for ; Mon, 10 May 2010 07:18:31 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 1CA5C3A68F9 for ; Mon, 10 May 2010 07:18:26 -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 870CE2CDE04B; Mon, 10 May 2010 16:18:11 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20100510140840.GA3760@elstar.local> References: <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <1273473685.1752.62.camel@missotis> <4BE7F4B2.5060602@bwijnen.net> <20100510140840.GA3760@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 10 May 2010 16:18:10 +0200 Message-ID: <1273501090.1752.231.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 14:18:33 -0000 Juergen Schoenwaelder píše v Po 10. 05. 2010 v 16:08 +0200: > On Mon, May 10, 2010 at 01:57:38PM +0200, Bert (IETF) Wijnen wrote: > > > --- > > > > There was also discussion on merging all (or part of) with-defaults > > with 4741bis. Again no clear consensus, although there I would be > > ready to conclude (WG chair reading of the discussions) that I think > > that there is enough support to stick to our charter and deliver the > > documents as described there. Or better, that I do not see enough > > support to actually deviate from hat weagreed upon in the > > charter. So no merging. > > I continue to believe that it is a bug that 4741 does not tell a > client what it does wrt defaults and I would prefer that if we can > avoid that with 4741bis clients. The current with-defaults ID as such > might not be implemented because it does more than just announcing the > behaviour and thus does not solve the problem. +1. If the server behaviour was allowed to depend on the strategy of handling the defaults, it certainly is a bug not to report the strategy. Lada > > > --- > > > > But I am reluctant to declare we have clarity and consensus on the > > whole defaults/with-defaults story at this point in time. > > And this is why a decision to stick to the charter is IMHO premature. > Lada, for example, made a proposal to move the with-defaults behaviour > announcement to 4741bis while keeping the additional argument for > operations in the with-defaults document. We should not rule out this > option. (But perhaps this also was not your intention, but this is > unclear.) > > > --- > > > > As was stated a few times, we thought we reached consensus on this > > quite a while ago. It seems that the way we documented it is not > > clear enough. > > > > Is anyone ready to do a comprehensive proposal as to what text > > should be changed or added in order to try to see if we can agree on > > such changes? > > Perhaps the concensus was not clear or it was only clear up to the > point where some implementors decided what is in the extra document > does not need to be implemented - so they can have concensus by > ignoring it. Not sure this is what we want at the end. > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Mon May 10 08:29: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 B0BB53A6A25 for ; Mon, 10 May 2010 08:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[AWL=-0.721, 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 uLY+4gG4iIdH for ; Mon, 10 May 2010 08:29:45 -0700 (PDT) Received: from smtp124.dfw.emailsrvr.com (smtp124.dfw.emailsrvr.com [67.192.241.124]) by core3.amsl.com (Postfix) with ESMTP id 9608A3A6BEA for ; Mon, 10 May 2010 08:28:06 -0700 (PDT) Received: from relay2.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay2.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 0150BE214A5; Mon, 10 May 2010 11:27:54 -0400 (EDT) Received: by relay2.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id A2BBDE212C4; Mon, 10 May 2010 11:27:54 -0400 (EDT) Message-ID: <4BE82612.5010309@iwl.com> Date: Mon, 10 May 2010 08:28:18 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Bert (IETF) Wijnen" References: <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <1273473685.1752.62.camel@missotis> <4BE7F4B2.5060602@bwijnen.net> In-Reply-To: <4BE7F4B2.5060602@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 15:29:46 -0000 Bert (IETF) Wijnen wrote: > WG participants, I have now read the postings of the last week twice. > > I can't say that I am reading any consensus. I also can't say that all > the arguments > that have seen used are 100% clear to me (but that is because I am far > less versed > in this material than the implementers). > > In fact, it seems to me, that we clearly interpret the text related to > "defaults" and with-defaults" > differently. And that is... the people who actually developed the text > and have implemented > most (if not all of it). If even those people have different > interpretations, what does that mean > for someone new who must implement this? Or someone new who needs to > write a > data model using YANG? > > --- > > There was also discussion on merging all (or part of) with-defaults > with 4741bis. > Again no clear consensus, although there I would be ready to conclude > (WG chair > reading of the discussions) that I think that there is enough support > to stick to our charter > and deliver the documents as described there. Or better, that I do not > see enough support > to actually deviate from hat weagreed upon in the charter. So no merging. > > --- > > But I am reluctant to declare we have clarity and consensus on the > whole defaults/with-defaults > story at this point in time. > > --- > > As was stated a few times, we thought we reached consensus on this > quite a while ago. > It seems that the way we documented it is not clear enough. > > Is anyone ready to do a comprehensive proposal as to what text should > be changed or added > in order to try to see if we can agree on such changes? This debate is really over how standard the NETCONF protocol is going to be. Should the create and delete operations behave the same way on all NETCONF servers, going forward? We know pre-standard that everybody does 'defaults' differently. That doesn't mean post-standard that we are trying to preserve this technical diversity. Sometimes we compromise (like with-defaults, candidate, startup) and we end up with a small number of acceptable solutions. Martin is arguing that is the best we can do in this case. Perhaps he is right. The heuristic he suggests seems like an acceptable compromise -- the server MUST honor its own basic-mode for create/delete. If a get-config in basic-mode contains the node, the server considers the node to be present. If the WG agrees, I can propose some new text for the with-defaults draft. I agree that a 'new' server MUST advertise its basic-mode. That doesn't mean a 4741bis server -- it just means a server that implements with-defaults. I do not want to change the RFC packaging of the NETCONF standard. > > Bert Andy From j.schoenwaelder@jacobs-university.de Mon May 10 08: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 AD2A33A6A1F for ; Mon, 10 May 2010 08:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.134 X-Spam-Level: X-Spam-Status: No, score=0.134 tagged_above=-999 required=5 tests=[AWL=-0.217, 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 bAmO5D6yKy9X for ; Mon, 10 May 2010 08:39:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8956D3A6A25 for ; Mon, 10 May 2010 08:39:08 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 17CCFC0015; Mon, 10 May 2010 17:38:57 +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 IP76VQEuGhY8; Mon, 10 May 2010 17:38: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 EC2A3C0014; Mon, 10 May 2010 17:38:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 556FB1203F83; Mon, 10 May 2010 17:38:55 +0200 (CEST) Date: Mon, 10 May 2010 17:38:54 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100510153854.GA4265@elstar.local> Mail-Followup-To: Andy Bierman , "Bert (IETF) Wijnen" , "netconf@ietf.org" References: <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <1273473685.1752.62.camel@missotis> <4BE7F4B2.5060602@bwijnen.net> <4BE82612.5010309@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BE82612.5010309@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 15:39:09 -0000 On Mon, May 10, 2010 at 05:28:18PM +0200, Andy Bierman wrote: > I agree that a 'new' server MUST advertise its basic-mode. > That doesn't mean a 4741bis server -- it just means a server > that implements with-defaults. I do not want to change the > RFC packaging of the NETCONF standard. But this won't fly if people do not implement with-defaults because it also adds additional parameters to operations they do not want to support. /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 Mon May 10 08:53: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 8ACCB3A6A33 for ; Mon, 10 May 2010 08:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.06 X-Spam-Level: X-Spam-Status: No, score=-2.06 tagged_above=-999 required=5 tests=[AWL=-0.320, 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 MoRVwrrnmxsM for ; Mon, 10 May 2010 08:53:16 -0700 (PDT) Received: from smtp134.iad.emailsrvr.com (smtp134.iad.emailsrvr.com [207.97.245.134]) by core3.amsl.com (Postfix) with ESMTP id 77E6F3A69B6 for ; Mon, 10 May 2010 08:53: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 2745744C0F7; Mon, 10 May 2010 11:52:54 -0400 (EDT) Received: by relay3.r3.iad.emailsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id A335644C0AA; Mon, 10 May 2010 11:52:47 -0400 (EDT) Message-ID: <4BE82BE7.9010903@iwl.com> Date: Mon, 10 May 2010 08:53:11 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Bert (IETF) Wijnen" , "netconf@ietf.org" References: <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <1273473685.1752.62.camel@missotis> <4BE7F4B2.5060602@bwijnen.net> <4BE82612.5010309@iwl.com> <20100510153854.GA4265@elstar.local> In-Reply-To: <20100510153854.GA4265@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 15:53:17 -0000 Juergen Schoenwaelder wrote: > On Mon, May 10, 2010 at 05:28:18PM +0200, Andy Bierman wrote: > > >> I agree that a 'new' server MUST advertise its basic-mode. >> That doesn't mean a 4741bis server -- it just means a server >> that implements with-defaults. I do not want to change the >> RFC packaging of the NETCONF standard. >> > > But this won't fly if people do not implement with-defaults because it > also adds additional parameters to operations they do not want to > support. > > Too bad -- the WG already agreed that a server SHOULD support report-all. If the vendor ignores the standard and says to its customers "You already know how to look that info up on our WEB site, so you don't need that info from the server." Every NETCONF server knows its own total set of supported leafs, so every server can implement report-all. The diversity we are maintaining is the ability for the server to choose its basic mode, not the ability to decide that report-all is never needed. The client will decide whether to use report-all or not. > /js > > Andy From lhotka@cesnet.cz Mon May 10 09:01: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 79ABE3A69FB for ; Mon, 10 May 2010 09:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.174 X-Spam-Level: X-Spam-Status: No, score=-0.174 tagged_above=-999 required=5 tests=[AWL=1.076, 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 pxz4FzAlJt1z for ; Mon, 10 May 2010 09:01:43 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6E95C3A69E2 for ; Mon, 10 May 2010 09:01:36 -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 0B91B2CDE058; Mon, 10 May 2010 18:01:24 +0200 (CEST) From: Ladislav Lhotka To: andyb@iwl.com In-Reply-To: <4BE82612.5010309@iwl.com> References: <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <1273473685.1752.62.camel@missotis> <4BE7F4B2.5060602@bwijnen.net> <4BE82612.5010309@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 10 May 2010 18:01:22 +0200 Message-ID: <1273507282.1752.252.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 16:01:44 -0000 Andy Bierman píše v Po 10. 05. 2010 v 08:28 -0700: > I agree that a 'new' server MUST advertise its basic-mode. > That doesn't mean a 4741bis server -- it just means a server > that implements with-defaults. I do not want to change the > RFC packaging of the NETCONF standard. > What will then be the value of 4741bis conformance, if a configuration script that works for server A (using "trim") fails for server B (using "explicit"), both servers fully supporting 4741bis and the same set of YANG modules? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Mon May 10 09:17: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 58BBE3A69A0 for ; Mon, 10 May 2010 09:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.926 X-Spam-Level: X-Spam-Status: No, score=-0.926 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 FD0tw4j4HuR0 for ; Mon, 10 May 2010 09:17:34 -0700 (PDT) Received: from smtp194.dfw.emailsrvr.com (smtp194.dfw.emailsrvr.com [67.192.241.194]) by core3.amsl.com (Postfix) with ESMTP id 792103A69D6 for ; Mon, 10 May 2010 09:17:18 -0700 (PDT) Received: from relay9.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id E9DAA13D33EC; Mon, 10 May 2010 12:17:01 -0400 (EDT) Received: by relay9.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 52EA113D368F; Mon, 10 May 2010 12:11:21 -0400 (EDT) Message-ID: <4BE8303E.2040004@iwl.com> Date: Mon, 10 May 2010 09:11:42 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Ladislav Lhotka References: <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <1273473685.1752.62.camel@missotis> <4BE7F4B2.5060602@bwijnen.net> <4BE82612.5010309@iwl.com> <1273507282.1752.252.camel@missotis> In-Reply-To: <1273507282.1752.252.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 16:17:35 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Po 10. 05. 2010 v 08:28 -0700: > >> I agree that a 'new' server MUST advertise its basic-mode. >> That doesn't mean a 4741bis server -- it just means a server >> that implements with-defaults. I do not want to change the >> RFC packaging of the NETCONF standard. >> >> > > What will then be the value of 4741bis conformance, if a configuration > script that works for server A (using "trim") fails for server B (using > "explicit"), both servers fully supporting 4741bis and the same set of > YANG modules? > > I do not see how the particular RFC numbers affect protocol conformance. An implementer has to deal with SSH details in RFC 4742 that are even more critical to interoperability. The theoretical problem is that a server will change its basic-mode and a client will get confused. In reality, this is not going to happen. There are some code optimizations a client can use if it knows the basic-mode, but certainly not critical to the protocol. In standards-think, of course a server MUST advertise its basic-mode. But as long as the server sticks to just 1 basic-mode, the client can get by. In standards-think, of course the server MUST stick to 1 basic-mode at a time. This is a CLR that vendors already follow. So (in summary) I take back 'server MUST advertise its basic-mode'. I think the WG already made the right decision with 'SHOULD implement with-defaults'. > Lada > > Andy From phil@juniper.net Mon May 10 09:26: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 A89FA3A6888 for ; Mon, 10 May 2010 09:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.935 X-Spam-Level: X-Spam-Status: No, score=-4.935 tagged_above=-999 required=5 tests=[AWL=-0.936, 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 HiZde0y40nUB for ; Mon, 10 May 2010 09:26:42 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 452083A6933 for ; Mon, 10 May 2010 09:25:46 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKS+gzfU7MZq8VMJSJ8d2Tn0W1Nf5AAvL/@postini.com; Mon, 10 May 2010 09:25:36 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Mon, 10 May 2010 09:20:46 -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); Mon, 10 May 2010 09:20:46 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 May 2010 09:20:46 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 May 2010 09:20:45 -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 o4AGKjD55269; Mon, 10 May 2010 09:20:45 -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 o4AG3X8I048769; Mon, 10 May 2010 16:03:33 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005101603.o4AG3X8I048769@idle.juniper.net> To: "Bert (IETF) Wijnen" In-Reply-To: <4BE7F4B2.5060602@bwijnen.net> Date: Mon, 10 May 2010 12:03:33 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 May 2010 16:20:45.0914 (UTC) FILETIME=[BE9DA3A0:01CAF05C] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 16:26:43 -0000 "Bert (IETF) Wijnen" writes: >Is anyone ready to do a comprehensive proposal as to what text should be >changed or added in order to try to see if we can agree on such changes? Perhaps the best path would be to turn the various issues raised by our endless discussions on defaults into content in the with-defaults draft, which seems like a place where it should be covered. The current coverage in the draft is fairly brief and does not give the reader any sense of the joy we've been having on this and the netmod mailing lists. I think our discussions on the issue of defaults get very complex very quickly, but the root issues are both minor and straight forward: (a) what happens when you "create" a leaf that has as default value? (b) what happens when you "merge" that leaf to the default value? (c) what happens when you "delete" a leaf that has been set to the default value? (d) what happens when you "delete" that freshly deleted leaf a second time? What happens if you perform these operations in sequence on the same leaf? Which of these are errors? The "natural" answer depends on how your database represents default values. I use the "explicit" model in JUNOS and strongly distinquish between default values and human- (or client-) provided data. The database holds "real" data, and default values are provided to internal software components that query the database (and even that API will tell the software if the value is explicitly set or a default). This is a very natural way for CLIs to work and seems to match customer, user, and programmer expectations. So the "explicit" answers to the above questions are: (a) create succeeds; the leaf now exists in the database (b) merge succeeds; the leaf still exists in the database (c) delete succeeds; the leaf is no longer in the database (d) delete fails; the leaf cannot be deleted since it does not exist The "trim" model is drawn from IOS CLI (and similar clones) where leafs that are set to their default values are discarded from the configuration database. So the "trim" answers to the above questions are: (a) create succeeds; the leaf now exists in the database (b) merge succeeds; the leaf is removed from the database (c) delete fails; the leaf cannot be deleted since it does not exist (d) delete fails; the leaf cannot be deleted since it does not exist The "report-all" model treats default values identically to "real" data. So default values appear automatically and removing a leaf with a default value causes that leaf to reappear with the default value. The "report-all" answers to the above questions are: (a) create fails; the leaf already exists (b) merge succeeds; the leaf is unchanged (still has the default) (c) the delete succeeds; the leaf is recreated with the default (d) the delete succeeds; the leaf is recreated with the default I would find it confusing to see a leaf that I just deleted reappear, or to have a create fail for a list member that I just created. If I make a list member and populate it with 2 leafs, I don't want to see 20 leafs when I fetch it. I want to see the data that I explicitly set and nothing more. I can find default values in the appropriate YANG module, if my client even needs them. IMHO this way of mixing defaults into configuration data is similar to the SNMP world, where there was no way to distinquish between config data and operational data. Maybe this approach to defaults is also tied to SNMP MIBs, where default values were suggestions, not part of the contract both sides were expected to follow. In any case, there is are three distinct camps and no side is willing to live by the rules that would be enforced if one model were chosen. We have marched through this ground repeatedly and I don't see much value to crawling back into these trenches. Let's try to live by the rules of the last treaty and give each other the flexibility to support our specific model. Thanks, Phil P.s.: With any luck, the following YANG module and NETCONF opeation will fill in some details about (a)-(d) above. P.p.s: Please don't worry about namespace/etc issues, as this is really more for discussion than for real testing. module test { container test { list peer { key name; leaf name { type string; } leaf version { type uint8; default 1; } } } } fred 2 fred 1 fred fred From lhotka@cesnet.cz Mon May 10 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 2E6F23A691E for ; Mon, 10 May 2010 09:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.999 X-Spam-Level: X-Spam-Status: No, score=0.999 tagged_above=-999 required=5 tests=[AWL=-0.165, 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 O476oKHiBYB9 for ; Mon, 10 May 2010 09:31:06 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 28F983A6857 for ; Mon, 10 May 2010 09:31: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 A6A9A2CDE058; Mon, 10 May 2010 18:30:54 +0200 (CEST) From: Ladislav Lhotka To: andyb@iwl.com In-Reply-To: <4BE8303E.2040004@iwl.com> References: <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <1273473685.1752.62.camel@missotis> <4BE7F4B2.5060602@bwijnen.net> <4BE82612.5010309@iwl.com> <1273507282.1752.252.camel@missotis> <4BE8303E.2040004@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 10 May 2010 18:30:52 +0200 Message-ID: <1273509052.1752.254.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 16:31:07 -0000 Andy Bierman píše v Po 10. 05. 2010 v 09:11 -0700: > Ladislav Lhotka wrote: > > Andy Bierman píše v Po 10. 05. 2010 v 08:28 -0700: > > > >> I agree that a 'new' server MUST advertise its basic-mode. > >> That doesn't mean a 4741bis server -- it just means a server > >> that implements with-defaults. I do not want to change the > >> RFC packaging of the NETCONF standard. > >> > >> > > > > What will then be the value of 4741bis conformance, if a configuration > > script that works for server A (using "trim") fails for server B (using > > "explicit"), both servers fully supporting 4741bis and the same set of > > YANG modules? > > > > > > I do not see how the particular RFC numbers affect > protocol conformance. An implementer has to > deal with SSH details in RFC 4742 that are even > more critical to interoperability. RFC4741bis says: "A NETCONF implementation MUST support the SSH transport protocol mapping [4]." Will it also say that a NETCONF implementation SHOULD implement with-defaults? Lada > > The theoretical problem is that a server will change > its basic-mode and a client will get confused. > In reality, this is not going to happen. There are some > code optimizations a client can use if it knows > the basic-mode, but certainly not critical to the protocol. > > In standards-think, of course a server MUST advertise > its basic-mode. But as long as the server sticks to > just 1 basic-mode, the client can get by. In standards-think, > of course the server MUST stick to 1 basic-mode > at a time. This is a CLR that vendors already follow. > > So (in summary) I take back 'server MUST advertise > its basic-mode'. I think the WG already made the right > decision with 'SHOULD implement with-defaults'. > > > > Lada > > > > > Andy > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Mon May 10 09:53: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 18E3A3A6982 for ; Mon, 10 May 2010 09:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=0.597, 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 VQDxnyWTGkRF for ; Mon, 10 May 2010 09:53:06 -0700 (PDT) Received: from smtp114.dfw.emailsrvr.com (smtp114.dfw.emailsrvr.com [67.192.241.114]) by core3.amsl.com (Postfix) with ESMTP id D850B3A6A44 for ; Mon, 10 May 2010 09:52:36 -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 7CD862E40035; Mon, 10 May 2010 12:52:25 -0400 (EDT) Received: by relay21.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id F1B712E40176; Mon, 10 May 2010 12:52:24 -0400 (EDT) Message-ID: <4BE839E1.2090007@iwl.com> Date: Mon, 10 May 2010 09:52:49 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Ladislav Lhotka References: <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <1273473685.1752.62.camel@missotis> <4BE7F4B2.5060602@bwijnen.net> <4BE82612.5010309@iwl.com> <1273507282.1752.252.camel@missotis> <4BE8303E.2040004@iwl.com> <1273509052.1752.254.camel@missotis> In-Reply-To: <1273509052.1752.254.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 16:53:07 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Po 10. 05. 2010 v 09:11 -0700: > >> Ladislav Lhotka wrote: >> >>> Andy Bierman píše v Po 10. 05. 2010 v 08:28 -0700: >>> >>> >>>> I agree that a 'new' server MUST advertise its basic-mode. >>>> That doesn't mean a 4741bis server -- it just means a server >>>> that implements with-defaults. I do not want to change the >>>> RFC packaging of the NETCONF standard. >>>> >>>> >>>> >>> What will then be the value of 4741bis conformance, if a configuration >>> script that works for server A (using "trim") fails for server B (using >>> "explicit"), both servers fully supporting 4741bis and the same set of >>> YANG modules? >>> >>> >>> >> I do not see how the particular RFC numbers affect >> protocol conformance. An implementer has to >> deal with SSH details in RFC 4742 that are even >> more critical to interoperability. >> > > RFC4741bis says: "A NETCONF implementation MUST support the SSH > transport protocol mapping [4]." Will it also say that a NETCONF > implementation SHOULD implement with-defaults? > > IMO, there is no need for a normative reference from 4741bis to with-defaults. That is for the IESG to decide. I think it could be argued that with-defaults provides additional monitoring functionality to a NETCONF server. We don't say that a server SHOULD implement NETCONF Monitoring in 4741bis. I don't think circular normative references exist here either. > Lada > > Andy From andyb@iwl.com Mon May 10 10:08: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 012643A6A30 for ; Mon, 10 May 2010 10:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[AWL=-0.680, 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 QJoi0w3CP62v for ; Mon, 10 May 2010 10:08:20 -0700 (PDT) Received: from smtp214.iad.emailsrvr.com (smtp214.iad.emailsrvr.com [207.97.245.214]) by core3.amsl.com (Postfix) with ESMTP id 59A783A69ED for ; Mon, 10 May 2010 10:08:04 -0700 (PDT) Received: from relay11.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay11.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id B390A1B537C; Mon, 10 May 2010 13:07:52 -0400 (EDT) Received: by relay11.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 3B4D41B40CB; Mon, 10 May 2010 13:07:52 -0400 (EDT) Message-ID: <4BE83D7D.2000709@iwl.com> Date: Mon, 10 May 2010 10:08:13 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201005101603.o4AG3X8I048769@idle.juniper.net> In-Reply-To: <201005101603.o4AG3X8I048769@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 17:08:22 -0000 Phil Shafer wrote: > "Bert (IETF) Wijnen" writes: > >> Is anyone ready to do a comprehensive proposal as to what text should be >> changed or added in order to try to see if we can agree on such changes? >> > > This is a nice summary of the details. I would just change 'merge' to 'merge or replace'. Clearly we are using to report the configured value and/or the operational value in use. Depending on your use-cases, this is either a problem or completely irrelevant. I do not find report-all confusing. If a YANG leaf has a default value, then deleting it is where the confusion lies. It is requires to operationally exist after the deletion. The confusion is that different vendors do not agree on the meaning of configuration. The 'explicit' camp calls it anything set by the client. The 'trim' camp calls it anything the server would not normally do on its own. The 'report-all' camp calls it any node that is currently in use, whether the client or the server provided the value. I don't think any 1 of them is right or better for every possible use case. Andy > Perhaps the best path would be to turn the various issues raised > by our endless discussions on defaults into content in the with-defaults > draft, which seems like a place where it should be covered. The > current coverage in the draft is fairly brief and does not give > the reader any sense of the joy we've been having on this and the > netmod mailing lists. > > I think our discussions on the issue of defaults get very complex > very quickly, but the root issues are both minor and straight > forward: > > (a) what happens when you "create" a leaf that has as default value? > (b) what happens when you "merge" that leaf to the default value? > (c) what happens when you "delete" a leaf that has been set to the default value? > (d) what happens when you "delete" that freshly deleted leaf a second time? > > What happens if you perform these operations in sequence on the > same leaf? Which of these are errors? The "natural" answer depends > on how your database represents default values. > > I use the "explicit" model in JUNOS and strongly distinquish between > default values and human- (or client-) provided data. The database > holds "real" data, and default values are provided to internal > software components that query the database (and even that API will > tell the software if the value is explicitly set or a default). > This is a very natural way for CLIs to work and seems to match > customer, user, and programmer expectations. So the "explicit" > answers to the above questions are: > (a) create succeeds; the leaf now exists in the database > (b) merge succeeds; the leaf still exists in the database > (c) delete succeeds; the leaf is no longer in the database > (d) delete fails; the leaf cannot be deleted since it does not exist > > The "trim" model is drawn from IOS CLI (and similar clones) where > leafs that are set to their default values are discarded from the > configuration database. So the "trim" answers to the above questions > are: > (a) create succeeds; the leaf now exists in the database > (b) merge succeeds; the leaf is removed from the database > (c) delete fails; the leaf cannot be deleted since it does not exist > (d) delete fails; the leaf cannot be deleted since it does not exist > > The "report-all" model treats default values identically to "real" > data. So default values appear automatically and removing a leaf > with a default value causes that leaf to reappear with the default > value. The "report-all" answers to the above questions are: > (a) create fails; the leaf already exists > (b) merge succeeds; the leaf is unchanged (still has the default) > (c) the delete succeeds; the leaf is recreated with the default > (d) the delete succeeds; the leaf is recreated with the default > > I would find it confusing to see a leaf that I just deleted reappear, > or to have a create fail for a list member that I just created. > If I make a list member and populate it with 2 leafs, I don't > want to see 20 leafs when I fetch it. I want to see the data > that I explicitly set and nothing more. I can find default values > in the appropriate YANG module, if my client even needs them. > > IMHO this way of mixing defaults into configuration data is similar > to the SNMP world, where there was no way to distinquish between > config data and operational data. Maybe this approach to defaults > is also tied to SNMP MIBs, where default values were suggestions, > not part of the contract both sides were expected to follow. > > In any case, there is are three distinct camps and no side is willing > to live by the rules that would be enforced if one model were chosen. > We have marched through this ground repeatedly and I don't see much > value to crawling back into these trenches. Let's try to live by > the rules of the last treaty and give each other the flexibility > to support our specific model. > > Thanks, > Phil > > P.s.: With any luck, the following YANG module and NETCONF opeation > will fill in some details about (a)-(d) above. > P.p.s: Please don't worry about namespace/etc issues, as this is > really more for discussion than for real testing. > > module test { > container test { > list peer { > key name; > leaf name { > type string; > } > leaf version { > type uint8; > default 1; > } > } > } > } > > > > > > > > > > fred > 2 > > > > > > fred > 1 > > > > > fred > > > > > > > fred > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From j.schoenwaelder@jacobs-university.de Mon May 10 10:31: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 D026C28C1C7 for ; Mon, 10 May 2010 10:31:25 -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.214, 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 QmQtZ7RJuQii for ; Mon, 10 May 2010 10:31: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 ADC943A6A50 for ; Mon, 10 May 2010 10:25:59 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 76CCDC0015; Mon, 10 May 2010 19:25:48 +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 DFrZE-lsM-lm; Mon, 10 May 2010 19:25:47 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E1D8CC0008; Mon, 10 May 2010 19:25:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C31C41204403; Mon, 10 May 2010 19:25:46 +0200 (CEST) Date: Mon, 10 May 2010 19:25:46 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100510172546.GA4816@elstar.local> Mail-Followup-To: Andy Bierman , "Bert (IETF) Wijnen" , "netconf@ietf.org" References: <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <1273473685.1752.62.camel@missotis> <4BE7F4B2.5060602@bwijnen.net> <4BE82612.5010309@iwl.com> <20100510153854.GA4265@elstar.local> <4BE82BE7.9010903@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BE82BE7.9010903@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 17:31:25 -0000 On Mon, May 10, 2010 at 05:53:11PM +0200, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Mon, May 10, 2010 at 05:28:18PM +0200, Andy Bierman wrote: > > > > > >> I agree that a 'new' server MUST advertise its basic-mode. > >> That doesn't mean a 4741bis server -- it just means a server > >> that implements with-defaults. I do not want to change the > >> RFC packaging of the NETCONF standard. > >> > > > > But this won't fly if people do not implement with-defaults because it > > also adds additional parameters to operations they do not want to > > support. > > Too bad -- the WG already agreed that a server SHOULD > support report-all. I want a "MUST announce" as part of 4741bis such that my client can learn how a server will react to basic edit-config operations. Knowing how a server handles defaults clarifies how NETCONF works. The additional with-defaults parameter can happily proceed in a separate document. /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 Mon May 10 10:34: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 35DB03A6BFB for ; Mon, 10 May 2010 10:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.139 X-Spam-Level: X-Spam-Status: No, score=0.139 tagged_above=-999 required=5 tests=[AWL=-0.212, 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 R+NkrPaU2GQ9 for ; Mon, 10 May 2010 10:34:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6EFFA28C1E3 for ; Mon, 10 May 2010 10:29:41 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 38775C0009; Mon, 10 May 2010 19:29:30 +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 TUGuTN9sWJE7; Mon, 10 May 2010 19:29:29 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B43ECC0008; Mon, 10 May 2010 19:29:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A3C2C120446C; Mon, 10 May 2010 19:29:28 +0200 (CEST) Date: Mon, 10 May 2010 19:29:28 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20100510172928.GB4816@elstar.local> Mail-Followup-To: Phil Shafer , "Bert (IETF) Wijnen" , "netconf@ietf.org" References: <4BE7F4B2.5060602@bwijnen.net> <201005101603.o4AG3X8I048769@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005101603.o4AG3X8I048769@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 17:34:34 -0000 On Mon, May 10, 2010 at 06:03:33PM +0200, Phil Shafer wrote: > (a) what happens when you "create" a leaf that has as default value? > (b) what happens when you "merge" that leaf to the default value? > (c) what happens when you "delete" a leaf that has been set to the default value? > (d) what happens when you "delete" that freshly deleted leaf a second time? [...] > The "trim" model is drawn from IOS CLI (and similar clones) where > leafs that are set to their default values are discarded from the > configuration database. So the "trim" answers to the above questions > are: > (a) create succeeds; the leaf now exists in the database > (b) merge succeeds; the leaf is removed from the database > (c) delete fails; the leaf cannot be deleted since it does not exist > (d) delete fails; the leaf cannot be deleted since it does not exist I do not understand (a) and (b) in the trim model - please explain. > IMHO this way of mixing defaults into configuration data is similar > to the SNMP world, where there was no way to distinquish between > config data and operational data. I agree - we need to look at the larger operational state problem. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Mon May 10 10:39: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 37C023A6C3E for ; Mon, 10 May 2010 10:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 kx2Njk3ELQ0A for ; Mon, 10 May 2010 10:39:07 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 9F7B928C1EF for ; Mon, 10 May 2010 10:36:22 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKS+hD/yekh+9t0lFstfGioKJFiAm3hFBo@postini.com; Mon, 10 May 2010 10:36:12 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Mon, 10 May 2010 10:34:54 -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); Mon, 10 May 2010 10:34:54 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 May 2010 10:34:54 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 May 2010 10:34:53 -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 o4AHYrD89837; Mon, 10 May 2010 10:34:53 -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 o4AHHfjI049464; Mon, 10 May 2010 17:17:41 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005101717.o4AHHfjI049464@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20100510172928.GB4816@elstar.local> Date: Mon, 10 May 2010 13:17:41 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 May 2010 17:34:53.0961 (UTC) FILETIME=[19DBBF90:01CAF067] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 17:39:08 -0000 Juergen Schoenwaelder writes: >On Mon, May 10, 2010 at 06:03:33PM +0200, Phil Shafer wrote: > >> (a) what happens when you "create" a leaf that has as default value? >> (b) what happens when you "merge" that leaf to the default value? >> (c) what happens when you "delete" a leaf that has been set to the default value? >> (d) what happens when you "delete" that freshly deleted leaf a second time? > >[...] > >> The "trim" model is drawn from IOS CLI (and similar clones) where >> leafs that are set to their default values are discarded from the >> configuration database. So the "trim" answers to the above questions >> are: >> (a) create succeeds; the leaf now exists in the database >> (b) merge succeeds; the leaf is removed from the database >> (c) delete fails; the leaf cannot be deleted since it does not exist >> (d) delete fails; the leaf cannot be deleted since it does not exist > >I do not understand (a) and (b) in the trim model - please explain. In the "trim" model, setting a leaf to the non-default value creates the leaf. I guess I should have been clear that (a) is referring to the non-default value: - (a) what happens when you "create" a leaf that has as default value but give it a value that is not equal to the default value? + (a) what happens when you "create" a leaf that has as default value? Setting a leaf to the default value removes it from the configuration database. So when I set "version" to "1", is disappears. Thanks, Phil From phil@juniper.net Mon May 10 10:46: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 5120028C1FF for ; Mon, 10 May 2010 10:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.214 X-Spam-Level: X-Spam-Status: No, score=-6.214 tagged_above=-999 required=5 tests=[AWL=0.385, 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 Q8Z1o3USblBS for ; Mon, 10 May 2010 10:46:58 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 98B723A6C17 for ; Mon, 10 May 2010 10:43:31 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKS+hFt0eruPcEA3tYlCiZmJUDWZJwLl4e@postini.com; Mon, 10 May 2010 10:43:21 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Mon, 10 May 2010 10:42:35 -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); Mon, 10 May 2010 10:42:35 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 May 2010 10:42:34 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 May 2010 10:42:34 -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 o4AHgXD93787; Mon, 10 May 2010 10:42:33 -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 o4AHPMvk049653; Mon, 10 May 2010 17:25:22 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005101725.o4AHPMvk049653@idle.juniper.net> To: In-Reply-To: <4BE83D7D.2000709@iwl.com> Date: Mon, 10 May 2010 13:25:22 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 May 2010 17:42:34.0190 (UTC) FILETIME=[2C2D1EE0:01CAF068] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 17:46:59 -0000 Andy Bierman writes: >Clearly we are using to report >the configured value and/or the operational value in use. Given that one of our goals was "to clearly distinguish between configuration data and operational data" [rfc3535], this is mixing is clearly a bad thing. >I do not find report-all confusing. >If a YANG leaf has a default value, >then deleting it is where the confusion lies. >It is requires to operationally exist after the deletion. I delete it but it's still there. That seems to be an obvious source of confusion. (Here I'm not referring to reporting all when getting config (which is uninteresting) but to servers that treat defaults as part of the configuration (in a not conceptual way)). >I don't think any 1 of them is right or better >for every possible use case. Agreed. So can we stick with the agreement we made the last time we walked through this subject? Thanks, Phil From kwatsen@juniper.net Mon May 10 10:54: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 03EEF28C1DD for ; Mon, 10 May 2010 10:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.642 X-Spam-Level: X-Spam-Status: No, score=-5.642 tagged_above=-999 required=5 tests=[AWL=0.957, 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 7tX4ZpC3NuYN for ; Mon, 10 May 2010 10:54:29 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id E65353A6A82 for ; Mon, 10 May 2010 10:52:38 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKS+hH2stBwd7/vMuq+SRjU24RHyNDotU8@postini.com; Mon, 10 May 2010 10:52:28 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 10 May 2010 10:50:01 -0700 From: Kent Watsen To: "'andyb@iwl.com'" Date: Mon, 10 May 2010 10:50:00 -0700 Thread-Topic: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt Thread-Index: AcruMuzQd8BWS/6rREaluhANJyofjACM6T3Q Message-ID: <84600D05C20FF943918238042D7670FD36C7D76380@EMBX01-HQ.jnpr.net> References: <201005061837.o46IbNKd064651@idle.juniper.net> <4BE31209.3060507@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76372@EMBX01-HQ.jnpr.net> <4BE4757F.7050909@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76376@EMBX01-HQ.jnpr.net> <4BE49139.7050607@iwl.com> In-Reply-To: <4BE49139.7050607@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 17:54:30 -0000 > I think if you want this to be a standard, you should write > a draft that addresses all the issues, and specifies > all the extensions you want to add to the NETCONF protocol. I'm willing to write up some text, but would like to see it in the with-def= aults I-D. Would it be OK for me to send out an edit of v7? - just as a pr= oposal to see how it would read? Thanks, Kent From andyb@iwl.com Mon May 10 10:55: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 A1ECA3A6979 for ; Mon, 10 May 2010 10:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.935 X-Spam-Level: X-Spam-Status: No, score=-0.935 tagged_above=-999 required=5 tests=[AWL=-0.159, 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 cHzl9ukUL5Pn for ; Mon, 10 May 2010 10:55:11 -0700 (PDT) Received: from smtp114.dfw.emailsrvr.com (smtp114.dfw.emailsrvr.com [67.192.241.114]) by core3.amsl.com (Postfix) with ESMTP id 603183A6C00 for ; Mon, 10 May 2010 10:53:43 -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 7688D2E403EC; Mon, 10 May 2010 13:53:32 -0400 (EDT) Received: by relay21.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 45FEE2E40197; Mon, 10 May 2010 13:53:32 -0400 (EDT) Message-ID: <4BE84834.40603@iwl.com> Date: Mon, 10 May 2010 10:53:56 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Bert (IETF) Wijnen" , "netconf@ietf.org" References: <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <1273473685.1752.62.camel@missotis> <4BE7F4B2.5060602@bwijnen.net> <4BE82612.5010309@iwl.com> <20100510153854.GA4265@elstar.local> <4BE82BE7.9010903@iwl.com> <20100510172546.GA4816@elstar.local> In-Reply-To: <20100510172546.GA4816@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 17:55:12 -0000 Juergen Schoenwaelder wrote: > On Mon, May 10, 2010 at 05:53:11PM +0200, Andy Bierman wrote: > >> Juergen Schoenwaelder wrote: >> >>> On Mon, May 10, 2010 at 05:28:18PM +0200, Andy Bierman wrote: >>> >>> >>> >>>> I agree that a 'new' server MUST advertise its basic-mode. >>>> That doesn't mean a 4741bis server -- it just means a server >>>> that implements with-defaults. I do not want to change the >>>> RFC packaging of the NETCONF standard. >>>> >>>> >>> But this won't fly if people do not implement with-defaults because it >>> also adds additional parameters to operations they do not want to >>> support. >>> >> Too bad -- the WG already agreed that a server SHOULD >> support report-all. >> > > I want a "MUST announce" as part of 4741bis such that my client can > learn how a server will react to basic edit-config operations. Knowing > how a server handles defaults clarifies how NETCONF works. The > additional with-defaults parameter can happily proceed in a separate > document. > > I do not agree at all that 4741bis has to be the document that contains this capability. I do not even agree that MUST announce is needed. A simple will answer this question, and simply using 'merge' instead of 'create' avoids most the problems completely. The with-defaults capability cannot simply be moved to another document. That will require a massive rewrite an re-reviewing everything. The 4741bis document already has a long list of open issues, and adding new ones is not going to help. I think Phil's argument about the client ignoring defaults is valid. If the server sticks to 1 basic-mode, the contents of the reply indicate how to server will treat edits to its database. There are so many constraints possible in YANG, that requiring a first to make precise editing decisions is not unreasonable. > /js > > Andy From andyb@iwl.com Mon May 10 10:57: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 64A6E28C133 for ; Mon, 10 May 2010 10:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.957 X-Spam-Level: X-Spam-Status: No, score=-2.957 tagged_above=-999 required=5 tests=[AWL=0.642, 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 BG4WXS2i88-9 for ; Mon, 10 May 2010 10:57:44 -0700 (PDT) Received: from smtp174.iad.emailsrvr.com (smtp174.iad.emailsrvr.com [207.97.245.174]) by core3.amsl.com (Postfix) with ESMTP id 8DE773A6A55 for ; Mon, 10 May 2010 10:57:00 -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 E7F8D1B9663; Mon, 10 May 2010 13:56:48 -0400 (EDT) Received: by relay17.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 852791B965D; Mon, 10 May 2010 13:56:48 -0400 (EDT) Message-ID: <4BE848F8.3090809@iwl.com> Date: Mon, 10 May 2010 10:57:12 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <201005061837.o46IbNKd064651@idle.juniper.net> <4BE31209.3060507@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76372@EMBX01-HQ.jnpr.net> <4BE4757F.7050909@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76376@EMBX01-HQ.jnpr.net> <4BE49139.7050607@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76380@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D76380@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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: Mon, 10 May 2010 17:57:45 -0000 Kent Watsen wrote: > >> I think if you want this to be a standard, you should write a draft >> that addresses all the issues, and specifies all the extensions you >> want to add to the NETCONF protocol. > > I'm willing to write up some text, but would like to see it in the > with-defaults I-D. Would it be OK for me to send out an edit of v7? > - just as a proposal to see how it would read? > A charter expansion of the with-defaults draft is not an option. IMO -- you should publish an I-D and propose a new work item for the WG to consider. The WG can decide what they want to do after we read the draft. > > Thanks, Kent > > > Andy From j.schoenwaelder@jacobs-university.de Mon May 10 11:43: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 2A2E73A6CC1 for ; Mon, 10 May 2010 11:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.142 X-Spam-Level: X-Spam-Status: No, score=0.142 tagged_above=-999 required=5 tests=[AWL=-0.209, 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 zQCDhfPMZl6F for ; Mon, 10 May 2010 11:43:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 19F4C28C285 for ; Mon, 10 May 2010 11:34:54 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB4AFC0008; Mon, 10 May 2010 20:34:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id v2635MOQQ9PI; Mon, 10 May 2010 20:34:41 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 32ADDC0009; Mon, 10 May 2010 20:34:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0E8761204746; Mon, 10 May 2010 20:34:41 +0200 (CEST) Date: Mon, 10 May 2010 20:34:40 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100510183440.GA5080@elstar.local> Mail-Followup-To: Andy Bierman , "Bert (IETF) Wijnen" , "netconf@ietf.org" References: <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <1273473685.1752.62.camel@missotis> <4BE7F4B2.5060602@bwijnen.net> <4BE82612.5010309@iwl.com> <20100510153854.GA4265@elstar.local> <4BE82BE7.9010903@iwl.com> <20100510172546.GA4816@elstar.local> <4BE84834.40603@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BE84834.40603@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 18:43:06 -0000 On Mon, May 10, 2010 at 07:53:56PM +0200, Andy Bierman wrote: > > I want a "MUST announce" as part of 4741bis such that my client can > > learn how a server will react to basic edit-config operations. Knowing > > how a server handles defaults clarifies how NETCONF works. The > > additional with-defaults parameter can happily proceed in a separate > > document. > > I do not agree at all that 4741bis has to be the document > that contains this capability. I do not even agree that MUST announce > is needed. A simple will answer this > question, and simply using 'merge' instead of 'create' > avoids most the problems completely. It is a bug if the semantics of 4741 operations are not clear from the 4741 capability announcements. I believe this needs fixing in 4741bis. I do not want to do experiments in order to probe the server's behaviour. I thought we move past SNMP where this unfortunately was common practice. > The with-defaults capability cannot simply be moved to another document. > That will require a massive rewrite an re-reviewing everything. > The 4741bis document already has a long list of open issues, > and adding new ones is not going to help. Not true. If you take out the changes to operations, then the capability announcing the server behaviour boils down to one page of text. The bigger part is probably the description what it means, which even in the current with-defaults may not be good enough, see Phil's posting. /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 Mon May 10 11:44: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 10DDA3A6CEA for ; Mon, 10 May 2010 11:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.145 X-Spam-Level: X-Spam-Status: No, score=0.145 tagged_above=-999 required=5 tests=[AWL=-0.206, 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 FCXvh0hwFHoJ for ; Mon, 10 May 2010 11:44:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7B67028C299 for ; Mon, 10 May 2010 11:35:42 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 48FC5C0009; Mon, 10 May 2010 20:35:31 +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 8iWlGR5DH+Pt; Mon, 10 May 2010 20:35:30 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DEBDAC0008; Mon, 10 May 2010 20:35:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D42A51204779; Mon, 10 May 2010 20:35:29 +0200 (CEST) Date: Mon, 10 May 2010 20:35:29 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20100510183529.GB5080@elstar.local> Mail-Followup-To: Phil Shafer , "Bert (IETF) Wijnen" , "netconf@ietf.org" References: <20100510172928.GB4816@elstar.local> <201005101717.o4AHHfjI049464@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005101717.o4AHHfjI049464@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 18:44:17 -0000 On Mon, May 10, 2010 at 07:17:41PM +0200, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >On Mon, May 10, 2010 at 06:03:33PM +0200, Phil Shafer wrote: > > > >> (a) what happens when you "create" a leaf that has as default value? > >> (b) what happens when you "merge" that leaf to the default value? > >> (c) what happens when you "delete" a leaf that has been set to the default value? > >> (d) what happens when you "delete" that freshly deleted leaf a second time? > > > >[...] > > > >> The "trim" model is drawn from IOS CLI (and similar clones) where > >> leafs that are set to their default values are discarded from the > >> configuration database. So the "trim" answers to the above questions > >> are: > >> (a) create succeeds; the leaf now exists in the database > >> (b) merge succeeds; the leaf is removed from the database > >> (c) delete fails; the leaf cannot be deleted since it does not exist > >> (d) delete fails; the leaf cannot be deleted since it does not exist > > > >I do not understand (a) and (b) in the trim model - please explain. > > In the "trim" model, setting a leaf to the non-default value creates > the leaf. I guess I should have been clear that (a) is referring to > the non-default value: > > - (a) what happens when you "create" a leaf that has as default value but > give it a value that is not equal to the default value? > + (a) what happens when you "create" a leaf that has as default value? > > Setting a leaf to the default value removes it from the configuration > database. So when I set "version" to "1", is disappears. OK, this makes it clear. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Mon May 10 12:07: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 8355828C309 for ; Mon, 10 May 2010 12:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.541 X-Spam-Level: X-Spam-Status: No, score=-4.541 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_40=-0.185, 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 KZN9EvJCANR2 for ; Mon, 10 May 2010 12:07:49 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id B0FB128C311 for ; Mon, 10 May 2010 12:00:11 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKS+hXrfz9CPTWUj4AuWs4mNwPCXe54FhH@postini.com; Mon, 10 May 2010 12:00:01 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Mon, 10 May 2010 11:58:11 -0700 From: Kent Watsen To: 'Ladislav Lhotka' , Juergen Schoenwaelder Date: Mon, 10 May 2010 11:58:10 -0700 Thread-Topic: [Netconf] WG Chair question: where are we with defaults Thread-Index: AcrwS6iVksJbK8n4QYWc28OFJwo2UwAIAL1A Message-ID: <84600D05C20FF943918238042D7670FD36C7D76381@EMBX01-HQ.jnpr.net> References: <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <1273473685.1752.62.camel@missotis> <4BE7F4B2.5060602@bwijnen.net> <20100510140840.GA3760@elstar.local> <1273501090.1752.231.camel@missotis> In-Reply-To: <1273501090.1752.231.camel@missotis> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 19:07:50 -0000 > > I continue to believe that it is a bug that 4741 does not tell a > > client what it does wrt defaults and I would prefer that if we can > > avoid that with 4741bis clients. The current with-defaults ID as such > > might not be implemented because it does more than just announcing the > > behaviour and thus does not solve the problem. >=20 > +1. If the server behaviour was allowed to depend on the strategy of > handling the defaults, it certainly is a bug not to report the strategy. +2 - I think 4741 should be updated to 1) define the three basic-modes and = 2) advise how NETCONF operations on defaults can vary for each (i.e. Phil's= examples). I'm on the fence as to if 4741 should go so far as to define a way for a se= rver to publish its basic-mode, since 4741 says this: 5.2. Data Modeling Data modeling and content issues are outside the scope of the NETCONF protocol. An assumption is made that the device's data model is well-known to the application and that both parties are aware of issues such as the layout, containment, keying, lookup, replacement, and management of the data, as well as any other constraints imposed by the data model. It seems incorrect for 4741 to define a mechanism for publishing a server's= basic-mode for default-handling without also providing a means to discover= what the server's defaults are... Would it make more sense for YANG to define a field for the server to publi= sh its basic-mode? - instead of putting it into a capability string? Thanks, Kent From randy_presuhn@mindspring.com Mon May 10 12:23:05 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 D07E528C362 for ; Mon, 10 May 2010 12:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.168 X-Spam-Level: X-Spam-Status: No, score=0.168 tagged_above=-999 required=5 tests=[AWL=0.167, 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 gkvA4zuv3vuk for ; Mon, 10 May 2010 12:23:02 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 0065928C0E0 for ; Mon, 10 May 2010 12:08:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=UTziQuYD32QIJofDFUB65VyrQ5PprzRfKruMtaX8AIP5dpJ/sfO1LjnwpYZx6nTM; 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.55.167] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OBYLM-0008Gc-Qj for netconf@ietf.org; Mon, 10 May 2010 15:08:45 -0400 Message-ID: <006b01caf074$5aef8680$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <201005101603.o4AG3X8I048769@idle.juniper.net> Date: Mon, 10 May 2010 12:09:45 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc7205327803520cdff33081c6fcc8b5303ed8e2cde0d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.55.167 Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 19:23:05 -0000 Hi - > From: "Phil Shafer" > To: "Bert (IETF) Wijnen" > Cc: > Sent: Monday, May 10, 2010 9:03 AM > Subject: Re: [Netconf] WG Chair question: where are we with defaults ... > (a) what happens when you "create" a leaf that has as default value? > (b) what happens when you "merge" that leaf to the default value? > (c) what happens when you "delete" a leaf that has been set to the default value? > (d) what happens when you "delete" that freshly deleted leaf a second time? ... > The "report-all" model treats default values identically to "real" > data. So default values appear automatically and removing a leaf > with a default value causes that leaf to reappear with the default > value. The "report-all" answers to the above questions are: > (a) create fails; the leaf already exists > (b) merge succeeds; the leaf is unchanged (still has the default) > (c) the delete succeeds; the leaf is recreated with the default > (d) the delete succeeds; the leaf is recreated with the default I don't see how you arrived at the conclusion that the leaf would reappear. There are *two* pieces of information: whether or not something exists, and its value if it does exist. Perhaps this is because I'm coming at this with a CMIP / SNMP / SQL mindset, but I think of "default" as being used to supply a value when something is created, *not* bound up in the circumstances under which something is created. Netconf extends "default" to apply to user interface / bandwidth optimizations, and potentially to a data storage optimizations. However, in this discussion these optimizations have become like the tail wagging the dog, and, in the analysis of "report-all" (if that analysis is indeed correct) seem to have really diverged from what "default" means anywhere else. > I would find it confusing to see a leaf that I just deleted reappear, > or to have a create fail for a list member that I just created. Totally agreed. > If I make a list member and populate it with 2 leafs, I don't > want to see 20 leafs when I fetch it. I want to see the data > that I explicitly set and nothing more. I can find default values > in the appropriate YANG module, if my client even needs them. This is the use-case for using knowledge of defaults to eliminate on-the-wire redundancy. HOWEVER, this is also where a conflict arises. *If* it is possible to delete a leaf with a default value it is not possible for the client to distinguish between the case where the leaf has been deleted and the leaf has been suppressed from the response. If the server instantly re-creates a deleted defaulted leaf, then it means that the model implementation cannot represent whatever semantic was supposed to be represented by the absence of that leaf. Randy From kwatsen@juniper.net Mon May 10 12:27: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 271883A69EB for ; Mon, 10 May 2010 12:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.712 X-Spam-Level: X-Spam-Status: No, score=-5.712 tagged_above=-999 required=5 tests=[AWL=0.887, 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 xgzTWy9dppVQ for ; Mon, 10 May 2010 12:27:28 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 0C0BF28C1F8 for ; Mon, 10 May 2010 12:11:55 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKS+haYYhqVLtWSR10tyB1qRQWL8rdI6VI@postini.com; Mon, 10 May 2010 12:11:45 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Mon, 10 May 2010 12:10:00 -0700 From: Kent Watsen To: 'Ladislav Lhotka' , Juergen Schoenwaelder Date: Mon, 10 May 2010 12:09:59 -0700 Thread-Topic: [Netconf] WG Chair question: where are we with defaults Thread-Index: AcrwS6iVksJbK8n4QYWc28OFJwo2UwAIAL1AAAIfc0A= Message-ID: <84600D05C20FF943918238042D7670FD36C7D76382@EMBX01-HQ.jnpr.net> References: <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <1273473685.1752.62.camel@missotis> <4BE7F4B2.5060602@bwijnen.net> <20100510140840.GA3760@elstar.local> <1273501090.1752.231.camel@missotis> <84600D05C20FF943918238042D7670FD36C7D76381@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D76381@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 19:27:29 -0000 > Would it make more sense for YANG to define a field for the server to > publish its basic-mode? - instead of putting it into a capability string= ? ...or maybe add it to the "netconf-state" subtree defined by the netconf-mo= nitoring I-D? Thanks, Kent From j.schoenwaelder@jacobs-university.de Mon May 10 12:49: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 0718E28C1AC for ; Mon, 10 May 2010 12:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.147 X-Spam-Level: X-Spam-Status: No, score=0.147 tagged_above=-999 required=5 tests=[AWL=-0.204, 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 kOvN+ZQVQIk4 for ; Mon, 10 May 2010 12:49:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C3E0628C365 for ; Mon, 10 May 2010 12:37:20 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 96F19C0009; Mon, 10 May 2010 21:37: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 QLsgk8h6c9Fw; Mon, 10 May 2010 21:37: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 4EAEEC0008; Mon, 10 May 2010 21:37:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3D40212049A5; Mon, 10 May 2010 21:37:08 +0200 (CEST) Date: Mon, 10 May 2010 21:37:08 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20100510193708.GA5246@elstar.local> Mail-Followup-To: Kent Watsen , 'Ladislav Lhotka' , "netconf@ietf.org" References: <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <1273473685.1752.62.camel@missotis> <4BE7F4B2.5060602@bwijnen.net> <20100510140840.GA3760@elstar.local> <1273501090.1752.231.camel@missotis> <84600D05C20FF943918238042D7670FD36C7D76381@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D76381@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 19:49:09 -0000 On Mon, May 10, 2010 at 08:58:10PM +0200, Kent Watsen wrote: > > > > I continue to believe that it is a bug that 4741 does not tell a > > > client what it does wrt defaults and I would prefer that if we can > > > avoid that with 4741bis clients. The current with-defaults ID as such > > > might not be implemented because it does more than just announcing the > > > behaviour and thus does not solve the problem. > > > > +1. If the server behaviour was allowed to depend on the strategy of > > handling the defaults, it certainly is a bug not to report the strategy. > > > +2 - I think 4741 should be updated to 1) define the three basic-modes and 2) advise how NETCONF operations on defaults can vary for each (i.e. Phil's examples). > > I'm on the fence as to if 4741 should go so far as to define a way for a server to publish its basic-mode, since 4741 says this: > > 5.2. Data Modeling > > Data modeling and content issues are outside the scope of the NETCONF > protocol. An assumption is made that the device's data model is > well-known to the application and that both parties are aware of > issues such as the layout, containment, keying, lookup, replacement, > and management of the data, as well as any other constraints imposed > by the data model. > > It seems incorrect for 4741 to define a mechanism for publishing a server's basic-mode for default-handling without also providing a means to discover what the server's defaults are... > > Would it make more sense for YANG to define a field for the server to publish its basic-mode? - instead of putting it into a capability string? I do not see the issue. If you can explain the three different default modes in 4741bis, then it should be possible to announce the basic-mode in 4741bis. How defaults are discovered is out of scope, independent of whether 4741bis includes the announcement of the basic-mode or not. For understanding how protocol operations behave, you only need a description of the three modes plus the announcement. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Mon May 10 13:09: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 689083A6CDD for ; Mon, 10 May 2010 13:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.927 X-Spam-Level: X-Spam-Status: No, score=-4.927 tagged_above=-999 required=5 tests=[AWL=-0.928, 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 G8c+ngGQPmXq for ; Mon, 10 May 2010 13:09:01 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 44D1428C194 for ; Mon, 10 May 2010 13:01:04 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKS+hl9MoP6OQHkUiQMUVDo/SoTTIlbxws@postini.com; Mon, 10 May 2010 13:00:53 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Mon, 10 May 2010 12:59:52 -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); Mon, 10 May 2010 12:59:53 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 May 2010 12:59:52 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 May 2010 12:59:52 -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 o4AJxpD56221; Mon, 10 May 2010 12:59:51 -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 o4AJgdWu051278; Mon, 10 May 2010 19:42:39 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005101942.o4AJgdWu051278@idle.juniper.net> To: Randy Presuhn In-Reply-To: <006b01caf074$5aef8680$6801a8c0@oemcomputer> Date: Mon, 10 May 2010 15:42:39 -0400 From: Phil Shafer X-OriginalArrivalTime: 10 May 2010 19:59:52.0105 (UTC) FILETIME=[5A5B3190:01CAF07B] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 20:09:02 -0000 "Randy Presuhn" writes: >I don't see how you arrived at the conclusion that the leaf would >reappear. Check the mailing list archives for the proponents of this model. This is the behaviour they wanted (for the node to exist as a real node in the database). >There are *two* pieces of information: whether or not >something exists, and its value if it does exist. Perhaps this is >because I'm coming at this with a CMIP / SNMP / SQL mindset, >but I think of "default" as being used to supply a value when >something is created, *not* bound up in the circumstances under >which something is created. This is *not* the way YANG works. Defaults values are used when that leaf does not exist. >Netconf extends "default" to apply to >user interface / bandwidth optimizations, and potentially to >a data storage optimizations. No, NETCONF adopts the classic CLI definition of default values, which is something operators are very familiar with. If you don't give an explicit value in the configuration, then the system will proceed using the default value. For example, if the default ttl is 30 and you configure a peer that does not specify the ttl knob, then the system will use 30. This value will not show up in the configuration data, but is implicit by the absence of the ttl knob. If you make a peer, set the ttl knob and the delete that knob, then the system will behave as it you had never set the knob at all. This is a very different model from CMIP, SNMP, and SQL, but one that has always worked well for networking gear. >However, in this discussion these >optimizations have become like the tail wagging the dog, and, in >the analysis of "report-all" (if that analysis is indeed correct) seem >to have really diverged from what "default" means anywhere else. This is not a storage optimization. This is a combination of easy integration, matching expectations, and not polluting the configuration database that the human user needs to look at. Reducing noise in the configuration data is one of my highest priorities, so pumping in meaningless default values is IMHO a very wrong direction. >This is the use-case for using knowledge of defaults to eliminate >on-the-wire redundancy. This is built into YANG. >HOWEVER, this is also where a conflict >arises. *If* it is possible to delete a leaf with a default value >it is not possible for the client to distinguish between the case where >the leaf has been deleted and the leaf has been suppressed from the >response. If the server instantly re-creates a deleted defaulted leaf, >then it means that the model implementation cannot represent >whatever semantic was supposed to be represented by the >absence of that leaf. You've lost me here. If the absense of the leaf has a semantic meaning then there should not be a default value for that leaf. Thanks, Phil From randy_presuhn@mindspring.com Mon May 10 13:50: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 50BB13A6CC2 for ; Mon, 10 May 2010 13:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.126 X-Spam-Level: X-Spam-Status: No, score=0.126 tagged_above=-999 required=5 tests=[AWL=0.125, 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 taw7QFWXzXgc for ; Mon, 10 May 2010 13:50:10 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id F34D93A69E5 for ; Mon, 10 May 2010 13:44:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=oOyGToo9kW2tfwXe4/CnpyRFi0iFovROodZeLotnw8+QPnxliXiMqIzDL6ksluGv; 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.55.167] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OBZpu-0004la-Sd for netconf@ietf.org; Mon, 10 May 2010 16:44:23 -0400 Message-ID: <000801caf081$b698e000$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <201005101942.o4AJgdWu051278@idle.juniper.net> Date: Mon, 10 May 2010 13:45:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc720532780350ce781642ead4a02559757ff3a564d22350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.55.167 Subject: Re: [Netconf] WG Chair question: where are we 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: Mon, 10 May 2010 20:50:11 -0000 Hi - > From: "Phil Shafer" > To: "Randy Presuhn" > Cc: > Sent: Monday, May 10, 2010 12:42 PM > Subject: Re: [Netconf] WG Chair question: where are we with defaults ... > >HOWEVER, this is also where a conflict > >arises. *If* it is possible to delete a leaf with a default value > >it is not possible for the client to distinguish between the case where > >the leaf has been deleted and the leaf has been suppressed from the > >response. If the server instantly re-creates a deleted defaulted leaf, > >then it means that the model implementation cannot represent > >whatever semantic was supposed to be represented by the > >absence of that leaf. > > You've lost me here. If the absense of the leaf has a semantic > meaning then there should not be a default value for that leaf. The logical conlusion of that line of reasoning is that a leaf with a default value must not be deletable, because deleting such a leaf would have no semantic. In some metamodels, this makes perfect sense. For example, in CMIP land one cannot create or delete attributes independently of the object to which they belong, so the question of deleting a defaulted attribute never arises. My problem is that I don't see how this metamodel constraint is ever made explicit in netconf-land. Randy From kwatsen@juniper.net Mon May 10 14:25: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 F28973A6A80 for ; Mon, 10 May 2010 14:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.793 X-Spam-Level: X-Spam-Status: No, score=-5.793 tagged_above=-999 required=5 tests=[AWL=0.806, 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 9QTcL43NvyJZ for ; Mon, 10 May 2010 14:25:37 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 9B32B3A6C43 for ; Mon, 10 May 2010 14:22:31 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKS+h5CoTxLjFv8GpYY6tHtxIfZpoonhrU@postini.com; Mon, 10 May 2010 14:22:21 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 10 May 2010 14:20:38 -0700 From: Kent Watsen To: "'andyb@iwl.com'" Date: Mon, 10 May 2010 14:20:38 -0700 Thread-Topic: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt Thread-Index: Acrwak5qHr1IUdi5TwmKQrbcoZuqhwAEzZeA Message-ID: <84600D05C20FF943918238042D7670FD36C7D76387@EMBX01-HQ.jnpr.net> References: <201005061837.o46IbNKd064651@idle.juniper.net> <4BE31209.3060507@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76372@EMBX01-HQ.jnpr.net> <4BE4757F.7050909@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76376@EMBX01-HQ.jnpr.net> <4BE49139.7050607@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76380@EMBX01-HQ.jnpr.net> <4BE848F8.3090809@iwl.com> In-Reply-To: <4BE848F8.3090809@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 21:25:40 -0000 > A charter expansion of the with-defaults draft is not an option. > IMO -- you should publish an I-D and propose a new work item > for the WG to consider. The WG can decide what they want to > do after we read the draft. Fair enough, but I'll pass, as I rather move the basic-mode definitions and= announcement to 4741bis. Once this happens, the remaining bit (essentiall= y a "report-all" capability) isn't likely something Juniper would implement= . BTW, we might want to revisit this I-D's "SHOULD implement" status; I think= folks were just wanting the basic-mode announcement... Thanks, Kent From andyb@iwl.com Mon May 10 16:02:21 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 4CB003A6B86 for ; Mon, 10 May 2010 16:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.588, 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 45-maB9VlecY for ; Mon, 10 May 2010 16:02:20 -0700 (PDT) Received: from smtp154.dfw.emailsrvr.com (smtp154.dfw.emailsrvr.com [67.192.241.154]) by core3.amsl.com (Postfix) with ESMTP id 0B8A73A6C06 for ; Mon, 10 May 2010 16:02:19 -0700 (PDT) Received: from relay25.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay25.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 0454A36041C; Mon, 10 May 2010 19:02:09 -0400 (EDT) Received: by relay25.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id A681D36020D; Mon, 10 May 2010 19:02:08 -0400 (EDT) Message-ID: <4BE8908A.1040602@iwl.com> Date: Mon, 10 May 2010 16:02:34 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <201005061837.o46IbNKd064651@idle.juniper.net> <4BE31209.3060507@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76372@EMBX01-HQ.jnpr.net> <4BE4757F.7050909@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76376@EMBX01-HQ.jnpr.net> <4BE49139.7050607@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76380@EMBX01-HQ.jnpr.net> <4BE848F8.3090809@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76387@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D76387@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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: Mon, 10 May 2010 23:02:21 -0000 Kent Watsen wrote: > >> A charter expansion of the with-defaults draft is not an option. >> IMO -- you should publish an I-D and propose a new work item for >> the WG to consider. The WG can decide what they want to do after >> we read the draft. > > > Fair enough, but I'll pass, as I rather move the basic-mode > definitions and announcement to 4741bis. Once this happens, the > remaining bit (essentially a "report-all" capability) isn't likely > something Juniper would implement. > I don't see what the with-defaults draft has to do with your desire to add meta-data to NETCONF replies. This request was discussed at the last IETF and the WG decided then not to do this. I think the matter is closed wrt/ the with-defaults draft. > BTW, we might want to revisit this I-D's "SHOULD implement" status; I > think folks were just wanting the basic-mode announcement... > We are revisiting it apparently. :-( I do not see any need for MUST advertise. The use of MUST is reserved for when then protocol cannot possibly work without the MUST requirement. I do not understand why advertising the with-defaults capability needs to be coupled to the server conformance to 4741bis. If both RFCs are eventually published, what difference does it make where the URI in the came from? The is already full of URIs from different RFCs and I-Ds. I don't see any problem with that. > Thanks, Kent > > > Andy From kwatsen@juniper.net Mon May 10 17:21: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 58E393A6AAB for ; Mon, 10 May 2010 17:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.931 X-Spam-Level: X-Spam-Status: No, score=-4.931 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_20=-0.74, 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 5D6I3y1akJM3 for ; Mon, 10 May 2010 17:21:17 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id D27643A6966 for ; Mon, 10 May 2010 17:21:03 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKS+ii47sGweQacUVwzT2Ej1w4q9ATWRMy@postini.com; Mon, 10 May 2010 17:20:53 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 10 May 2010 17:18:21 -0700 From: Kent Watsen To: "'andyb@iwl.com'" Date: Mon, 10 May 2010 17:18:20 -0700 Thread-Topic: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt Thread-Index: AcrwlNebGAoWvWKcQJWrRJIuF9ARSAAAVu3Q Message-ID: <84600D05C20FF943918238042D7670FD36C7D76389@EMBX01-HQ.jnpr.net> References: <201005061837.o46IbNKd064651@idle.juniper.net> <4BE31209.3060507@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76372@EMBX01-HQ.jnpr.net> <4BE4757F.7050909@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76376@EMBX01-HQ.jnpr.net> <4BE49139.7050607@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76380@EMBX01-HQ.jnpr.net> <4BE848F8.3090809@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76387@EMBX01-HQ.jnpr.net> <4BE8908A.1040602@iwl.com> In-Reply-To: <4BE8908A.1040602@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 00:21:20 -0000 > I don't see what the with-defaults draft has to do > with your desire to add meta-data to NETCONF replies. I do desire it; I believe tagging-defaults is the right thing to do but, as= long as Juniper isn't being compelled to implement report-all (because the= announcement moves to 4741bis), I'm willing to defer adding tagging to som= e future revision of this I-D. > I do not understand why advertising the with-defaults capability > needs to be coupled to the server conformance to 4741bis. > If both RFCs are eventually published, what difference does > it make where the URI in the came from? > The is already full of URIs from different RFCs > and I-Ds. I don't see any problem with that. You're right that it doesn't matter which capability string defines a thing= ; a device MUST implement everything it advertises. But that's not the iss= ue, which is that one capability string is being used to define two MUST st= atements of unequal importance: "A NETCONF server implementing the :with-defaults capability MUST indicate its basic behavior, whether it sends default data in the absence of any specific request from the NETCONF client; and MUST support the 'report-all' handling mode and MAY support other modes." The basic-mode announcement is really important; the report-all doesn't see= m nearly so. If we break up these two things, putting the announcement int= o 4741, then the remaining bit in w-d probably wouldn't still warrant a "SH= OULD implement" conformance level. Thanks, Kent From andyb@iwl.com Mon May 10 17:37: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 4258A28C17C for ; Mon, 10 May 2010 17:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.758 X-Spam-Level: X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[AWL=-0.352, 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 3frTl-3p1TXR for ; Mon, 10 May 2010 17:37:11 -0700 (PDT) Received: from smtp124.dfw.emailsrvr.com (smtp124.dfw.emailsrvr.com [67.192.241.124]) by core3.amsl.com (Postfix) with ESMTP id AFF613A6AB1 for ; Mon, 10 May 2010 17:37:10 -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 66BFA20801D2; Mon, 10 May 2010 20:36:59 -0400 (EDT) Received: by relay12.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id CD36F2080192; Mon, 10 May 2010 20:36:58 -0400 (EDT) Message-ID: <4BE8A6C4.8070502@iwl.com> Date: Mon, 10 May 2010 17:37:24 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <201005061837.o46IbNKd064651@idle.juniper.net> <4BE31209.3060507@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76372@EMBX01-HQ.jnpr.net> <4BE4757F.7050909@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76376@EMBX01-HQ.jnpr.net> <4BE49139.7050607@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76380@EMBX01-HQ.jnpr.net> <4BE848F8.3090809@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76387@EMBX01-HQ.jnpr.net> <4BE8908A.1040602@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76389@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D76389@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 11 May 2010 00:37:12 -0000 Kent Watsen wrote: > >> I don't see what the with-defaults draft has to do >> with your desire to add meta-data to NETCONF replies. >> > > I do desire it; I believe tagging-defaults is the right thing to do but, as long as Juniper isn't being compelled to implement report-all (because the announcement moves to 4741bis), I'm willing to defer adding tagging to some future revision of this I-D. > > > > >> I do not understand why advertising the with-defaults capability >> needs to be coupled to the server conformance to 4741bis. >> If both RFCs are eventually published, what difference does >> it make where the URI in the came from? >> The is already full of URIs from different RFCs >> and I-Ds. I don't see any problem with that. >> > > You're right that it doesn't matter which capability string defines a thing; a device MUST implement everything it advertises. But that's not the issue, which is that one capability string is being used to define two MUST statements of unequal importance: > > "A NETCONF server implementing the :with-defaults capability MUST > indicate its basic behavior, whether it sends default data in the > absence of any specific request from the NETCONF client; and MUST > support the 'report-all' handling mode and MAY support other modes." > > The basic-mode announcement is really important; the report-all doesn't seem nearly so. If we break up these two things, putting the announcement into 4741, then the remaining bit in w-d probably wouldn't still warrant a "SHOULD implement" conformance level. > > I agree it is OK to change MUST support report-all to SHOULD support report-all, especially if it means we can finally stop debating defaults. If the server does not have any 'also-supported' values, then the leaf accepts only 1 value so it's pointless. The conformance for the YANG module would be: - MUST implement ietf-netconf-with-defaults.yang if the 'also-supported' parameter is used in the :with-defaults capability advertisement. > Thanks, > Kent > > > > Andy From andyb@iwl.com Tue May 11 10:05: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 9BAB53A6A09 for ; Tue, 11 May 2010 10:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.937 X-Spam-Level: X-Spam-Status: No, score=-0.937 tagged_above=-999 required=5 tests=[AWL=-0.161, 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 bkU2DDwd8swt for ; Tue, 11 May 2010 10:05:29 -0700 (PDT) Received: from smtp164.dfw.emailsrvr.com (smtp164.dfw.emailsrvr.com [67.192.241.164]) by core3.amsl.com (Postfix) with ESMTP id E01963A6A05 for ; Tue, 11 May 2010 10:05:29 -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 C5D251566A; Tue, 11 May 2010 13:05:18 -0400 (EDT) Received: by relay16.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 6438C15623; Tue, 11 May 2010 13:05:18 -0400 (EDT) Message-ID: <4BE98E6D.6020003@iwl.com> Date: Tue, 11 May 2010 10:05:49 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen , 'Ladislav Lhotka' , "netconf@ietf.org" References: <4BE553E5.4000906@iwl.com> <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <1273473685.1752.62.camel@missotis> <4BE7F4B2.5060602@bwijnen.net> <20100510140840.GA3760@elstar.local> <1273501090.1752.231.camel@missotis> <84600D05C20FF943918238042D7670FD36C7D76381@EMBX01-HQ.jnpr.net> <20100510193708.GA5246@elstar.local> In-Reply-To: <20100510193708.GA5246@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] WG Chair question: where are we 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: Tue, 11 May 2010 17:05:30 -0000 Juergen Schoenwaelder wrote: > .... > I do not see the issue. If you can explain the three different default > modes in 4741bis, then it should be possible to announce the > basic-mode in 4741bis. How defaults are discovered is out of scope, > independent of whether 4741bis includes the announcement of the > basic-mode or not. For understanding how protocol operations behave, > you only need a description of the three modes plus the announcement. > > This is not really true. The only mode in which the meta-data tells you enough is basic-mode=report-all. Do any NETCONF vendors even use report-all as their basic mode? I doubt it. The proponents of report-all (including me) want it as a client-initiated debug mode. In the explicit and trim modes, a client needs to check the current value of the leaf. What if it doesn't contain a default? Then create will fail for sure. Same for delete working for sure. Knowing the basic-mode does not tell the client anything definitive, except in the basic-mode nobody actually uses. Advertising with-defaults basic-mode doesn't really solve the create/delete ambiguity problem at all. IMO, there is no reason to make this advertisement a MUST implement for all 4741bis servers. > /js > > Andy From phil@juniper.net Tue May 11 10:36: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 95C803A6CC7 for ; Tue, 11 May 2010 10:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.404, 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 hynoN+fZEnus for ; Tue, 11 May 2010 10:36:29 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 639F03A6D42 for ; Tue, 11 May 2010 10:34:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKS+mVC3rhshavoDvI+DwX54rOUoe+ugm5@postini.com; Tue, 11 May 2010 10:34:06 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Tue, 11 May 2010 10:30:11 -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); Tue, 11 May 2010 10:30:11 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 May 2010 10:30:11 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 May 2010 10:30:10 -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 o4BHU9D89621; Tue, 11 May 2010 10:30:09 -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 o4BHCu8P058126; Tue, 11 May 2010 17:12:56 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005111712.o4BHCu8P058126@idle.juniper.net> To: In-Reply-To: <4BE98E6D.6020003@iwl.com> Date: Tue, 11 May 2010 13:12:56 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 May 2010 17:30:10.0559 (UTC) FILETIME=[9B59C8F0:01CAF12F] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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, 11 May 2010 17:36:30 -0000 Andy Bierman writes: >The proponents of report-all (including me) want it >as a client-initiated debug mode. If this true, then I don't understand your objection to Kent's request to tag leafs that aren't "real" config data with an attribute letting the client know these values aren't real. If your client wants debug mode, isn't that a real key piece of information? Thanks, Phil From phil@juniper.net Tue May 11 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 32BE23A6857 for ; Tue, 11 May 2010 10:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.390, 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 3gOYCLNzHAgg for ; Tue, 11 May 2010 10:37:05 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 6C3EA3A6A4F for ; Tue, 11 May 2010 10:36:21 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKS+mVijBPzYHhw6DHcxSeyFVHhSMURccc@postini.com; Tue, 11 May 2010 10:36:11 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Tue, 11 May 2010 10:33:17 -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); Tue, 11 May 2010 10:33:17 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 May 2010 10:33:16 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 May 2010 10:33:16 -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 o4BHXFD91257; Tue, 11 May 2010 10:33:15 -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 o4BHG2Li058158; Tue, 11 May 2010 17:16:02 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005111716.o4BHG2Li058158@idle.juniper.net> To: Randy Presuhn In-Reply-To: <000801caf081$b698e000$6801a8c0@oemcomputer> Date: Tue, 11 May 2010 13:16:02 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 May 2010 17:33:16.0213 (UTC) FILETIME=[0A025650:01CAF130] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] WG Chair question: where are we 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, 11 May 2010 17:37:06 -0000 "Randy Presuhn" writes: >My problem is that I don't see how this metamodel constraint is ever >made explicit in netconf-land. It was never explicit or even implicit. The issue only arises when you start thinking about data models, which NETCONF does not consider. With YANG, we hit this issue repeatedly and the w-d draft was intended to address it in a way that isn't YANG specific. Thanks, Phil From phil@juniper.net Tue May 11 10:38: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 7C8043A69E9 for ; Tue, 11 May 2010 10:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=0.378, 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 Yugy0alXeyEO for ; Tue, 11 May 2010 10:38:33 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 9270B3A6851 for ; Tue, 11 May 2010 10:38:33 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKS+mWB9W+mOE+K5XqFqlWvtFSMCwIYINN@postini.com; Tue, 11 May 2010 10:38:23 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Tue, 11 May 2010 10:36:26 -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); Tue, 11 May 2010 10:36:26 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 May 2010 10:36:26 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 May 2010 10:36:25 -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 o4BHaOD92886; Tue, 11 May 2010 10:36:24 -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 o4BHJBoH058183; Tue, 11 May 2010 17:19:11 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005111719.o4BHJBoH058183@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20100510183529.GB5080@elstar.local> Date: Tue, 11 May 2010 13:19:11 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 May 2010 17:36:25.0804 (UTC) FILETIME=[7B03A0C0:01CAF130] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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, 11 May 2010 17:38:34 -0000 Juergen Schoenwaelder writes: >>..... >> Setting a leaf to the default value removes it from the configuration >> database. So when I set "version" to "1", is disappears. >OK, this makes it clear. Should we add a more detailed version of this discussion to the w-d draft? Do we need to change the words "operationally behave" to something that makes it clear we are talking about how the device behaves, not how the server handles NETCONF operations? Thanks, Phil From andyb@iwl.com Tue May 11 10:48: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 829C128C225 for ; Tue, 11 May 2010 10:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.622, 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 cHA55y8pAaxj for ; Tue, 11 May 2010 10:48:05 -0700 (PDT) Received: from smtp154.iad.emailsrvr.com (smtp154.iad.emailsrvr.com [207.97.245.154]) by core3.amsl.com (Postfix) with ESMTP id 9E52828C203 for ; Tue, 11 May 2010 10:48:05 -0700 (PDT) Received: from relay25.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay25.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id CE7781B4EF1; Tue, 11 May 2010 13:47:54 -0400 (EDT) Received: by relay25.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 5A7A41B4F5A; Tue, 11 May 2010 13:47:54 -0400 (EDT) Message-ID: <4BE99869.3030603@iwl.com> Date: Tue, 11 May 2010 10:48:25 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201005111712.o4BHCu8P058126@idle.juniper.net> In-Reply-To: <201005111712.o4BHCu8P058126@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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: Tue, 11 May 2010 17:48:06 -0000 Phil Shafer wrote: > Andy Bierman writes: > >> The proponents of report-all (including me) want it >> as a client-initiated debug mode. >> > > If this true, then I don't understand your objection to > Kent's request to tag leafs that aren't "real" config > data with an attribute letting the client know these > values aren't real. If your client wants debug > mode, isn't that a real key piece of information? > > I don't want any YANG-derivable meta-data included in the NETCONF standard . An old-client will not handle it at all, and not all new clients want this meta-data. Any 'server MAY send' is also a 'client MUST accept'. That's unacceptable. The WG already rejected this proposal twice -- once on the mailing list, and once at an IETF meeting. There is no consensus or permission to expand the charter of the with-defaults draft. > Thanks, > Phil > > Andy From randy_presuhn@mindspring.com Tue May 11 10:52: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 DB36C28C192 for ; Tue, 11 May 2010 10:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.166 X-Spam-Level: X-Spam-Status: No, score=-0.166 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 vxb3asrXbXxB for ; Tue, 11 May 2010 10:52:55 -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 4D81128C1F6 for ; Tue, 11 May 2010 10:52:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=rNQ8KMVlsuUP9Fzk+jZSabUW2LbB+Ygp0n2oe52sYbB7D65Ke4NTQug2gVgyyGi5; 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.152] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OBtdL-00028Y-Cd for netconf@ietf.org; Tue, 11 May 2010 13:52:43 -0400 Message-ID: <005901caf132$c486ae20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <201005111716.o4BHG2Li058158@idle.juniper.net> Date: Tue, 11 May 2010 10:52:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc720532780356f81715b6a8184f7b7b056fdd4a3af56350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.49.152 Subject: Re: [Netconf] WG Chair question: where are we 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, 11 May 2010 17:53:00 -0000 Hi - > From: "Phil Shafer" > To: "Randy Presuhn" > Cc: > Sent: Tuesday, May 11, 2010 10:16 AM > Subject: Re: [Netconf] WG Chair question: where are we with defaults > > "Randy Presuhn" writes: > >My problem is that I don't see how this metamodel constraint is ever > >made explicit in netconf-land. > > It was never explicit or even implicit. The issue only arises when > you start thinking about data models, which NETCONF does not consider. > With YANG, we hit this issue repeatedly and the w-d draft was > intended to address it in a way that isn't YANG specific. (banging head against wall) This is the point. Whether you like it or not, a configuration management protocol necessarily makes assumptions about the metamodel. To pretend that a protocol makes no assumptions or imposes no constraints is to invite a real mess, as demonstrated by the current discussion. Randy From phil@juniper.net Tue May 11 11:06: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 CEE873A6A0F for ; Tue, 11 May 2010 11:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.233 X-Spam-Level: X-Spam-Status: No, score=-6.233 tagged_above=-999 required=5 tests=[AWL=0.366, 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 3BmiwU3jRVn5 for ; Tue, 11 May 2010 11:06:26 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id A257D3A6A39 for ; Tue, 11 May 2010 11:06:22 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKS+mckk1Tu75oYe+txrbZGi2CcIPsKvlM@postini.com; Tue, 11 May 2010 11:06:14 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Tue, 11 May 2010 10:52:57 -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); Tue, 11 May 2010 10:52:57 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 May 2010 10:52:56 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 May 2010 10:52:56 -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 o4BHqtD00345; Tue, 11 May 2010 10:52:55 -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 o4BHZhOY058563; Tue, 11 May 2010 17:35:43 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005111735.o4BHZhOY058563@idle.juniper.net> To: In-Reply-To: <4BE99869.3030603@iwl.com> Date: Tue, 11 May 2010 13:35:43 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 May 2010 17:52:56.0417 (UTC) FILETIME=[C9772D10:01CAF132] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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, 11 May 2010 18:06:26 -0000 Andy Bierman writes: >I don't want any YANG-derivable meta-data included >in the NETCONF standard . An old-client >will not handle it at all, and not all new clients want >this meta-data. Any 'server MAY send' is also >a 'client MUST accept'. That's unacceptable. Old clients won't pass the new with-defaults parameter to the server, so they won't get this new attribute. >The WG already rejected this proposal twice -- once >on the mailing list, and once at an IETF meeting. >There is no consensus or permission to expand the >charter of the with-defaults draft. I don't recall this. I'm not sure this has been even been written up as a concrete proposal. Can the chairs confirm please if the WG has rejected this proposal twice? Thanks, Phil From phil@juniper.net Tue May 11 11:15: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 5663928C22D for ; Tue, 11 May 2010 11:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_05=-1.11, 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 Jcvkq+31-ZAz for ; Tue, 11 May 2010 11:15:28 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 2D7B128C202 for ; Tue, 11 May 2010 11:13:48 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKS+meUANuGwqge5sd66SI8KHCSFd1zfpL@postini.com; Tue, 11 May 2010 11:13:38 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Tue, 11 May 2010 10:58:15 -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); Tue, 11 May 2010 10:58:15 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 May 2010 10:58:15 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 May 2010 10:58:15 -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 o4BHwED02548; Tue, 11 May 2010 10:58:14 -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 o4BHf1DQ058675; Tue, 11 May 2010 17:41:01 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005111741.o4BHf1DQ058675@idle.juniper.net> To: Randy Presuhn In-Reply-To: <005901caf132$c486ae20$6801a8c0@oemcomputer> Date: Tue, 11 May 2010 13:41:01 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 May 2010 17:58:15.0147 (UTC) FILETIME=[877183B0:01CAF133] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] WG Chair question: where are we 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, 11 May 2010 18:15:30 -0000 "Randy Presuhn" writes: >(banging head against wall) This is the point. Whether you like it >or not, a configuration management protocol necessarily makes >assumptions about the metamodel. To pretend that a protocol >makes no assumptions or imposes no constraints is to invite a >real mess, as demonstrated by the current discussion. (with no head banging) No, one can carry anything in NETCONF, including CMIP, SNMP, CLI, or YANG-based data. There's no need to pretend that a single view of the meaning of default values will apply to all these models. YANG is free to define how YANG-based models deal with default values. If you make a "CMIP over NETCONF" draft, you can freely define how CMIP handles default values. These views can be very different. This "one size fits all" view of the world is IMHO the source of your bruised forehead x;^) (where "x" is the briuse) Thanks, Phil From randy_presuhn@mindspring.com Tue May 11 11:42:13 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA523A67B5 for ; Tue, 11 May 2010 11:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.145 X-Spam-Level: X-Spam-Status: No, score=-0.145 tagged_above=-999 required=5 tests=[AWL=-0.146, 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 x0BnvYSGK95j for ; Tue, 11 May 2010 11:42:12 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 0D4E53A6A69 for ; Tue, 11 May 2010 11:41:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=cNiTG12VN/cRCkELM8HvH14vegxWhPHjXF8/SCeFWzYuPUFVPkiLqqsPrqQqmRia; 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.152] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OBuOn-0006RF-Ce for netconf@ietf.org; Tue, 11 May 2010 14:41:45 -0400 Message-ID: <009301caf139$9e3e66c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <201005111741.o4BHf1DQ058675@idle.juniper.net> Date: Tue, 11 May 2010 11:41:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035dd619dd5b8e2658c81fbbc2170dad7ee350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.49.152 Subject: Re: [Netconf] WG Chair question: where are we 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, 11 May 2010 18:42:13 -0000 Hi - > From: "Phil Shafer" > To: "Randy Presuhn" > Cc: > Sent: Tuesday, May 11, 2010 10:41 AM > Subject: Re: [Netconf] WG Chair question: where are we with defaults > > "Randy Presuhn" writes: > >(banging head against wall) This is the point. Whether you like it > >or not, a configuration management protocol necessarily makes > >assumptions about the metamodel. To pretend that a protocol > >makes no assumptions or imposes no constraints is to invite a > >real mess, as demonstrated by the current discussion. > > (with no head banging) No, one can carry anything in NETCONF, > including CMIP, SNMP, CLI, or YANG-based data. Not true. The semantics of NETCONF don't support SNMP get-next, for example, nor CMIP set-to-default, nor CMIP cancel-get. (The latter could not even be emulated by created a new RPC.) Nor can it handle CMIP's create-with-reference-object. I'm not arguing that it should, but simply that, as we're seeing now, there *are* assumptions about the models it can handle, even if folks didn't think them through. > There's no need to > pretend that a single view of the meaning of default values will > apply to all these models. YANG is free to define how YANG-based > models deal with default values. If you make a "CMIP over NETCONF" > draft, you can freely define how CMIP handles default values. These > views can be very different. This would lead one to conclude that the behaviour of operations in netconf is both implementation and data model specific. Doesn't sound like much help for interoperability. Randy From j.schoenwaelder@jacobs-university.de Tue May 11 12:52: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 DF7F13A6C36 for ; Tue, 11 May 2010 12:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.152 X-Spam-Level: X-Spam-Status: No, score=0.152 tagged_above=-999 required=5 tests=[AWL=-0.199, 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 GhldZDb63Mvf for ; Tue, 11 May 2010 12:52:49 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 83DA33A6896 for ; Tue, 11 May 2010 12:52:27 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C134BC000F; Tue, 11 May 2010 21:52:16 +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 IzWmvnQosSNX; Tue, 11 May 2010 21:52:15 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A2F63C0004; Tue, 11 May 2010 21:52:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6803A1207647; Tue, 11 May 2010 21:52:15 +0200 (CEST) Date: Tue, 11 May 2010 21:52:15 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20100511195215.GA8428@elstar.local> Mail-Followup-To: Phil Shafer , "Bert (IETF) Wijnen" , "netconf@ietf.org" References: <20100510183529.GB5080@elstar.local> <201005111719.o4BHJBoH058183@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005111719.o4BHJBoH058183@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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: Tue, 11 May 2010 19:52:51 -0000 On Tue, May 11, 2010 at 07:19:11PM +0200, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >>..... > >> Setting a leaf to the default value removes it from the configuration > >> database. So when I set "version" to "1", is disappears. > >OK, this makes it clear. > > Should we add a more detailed version of this discussion to the > w-d draft? Do we need to change the words "operationally behave" > to something that makes it clear we are talking about how the > device behaves, not how the server handles NETCONF operations? We definitely need this text, where it goes is still unclear. /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 Tue May 11 12:57: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 639C63A69BF for ; Tue, 11 May 2010 12:57:33 -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=-0.197, 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 k7YXygUJujl7 for ; Tue, 11 May 2010 12:57: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 D42F93A6947 for ; Tue, 11 May 2010 12:57:31 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 216A3C0009; Tue, 11 May 2010 21:57:21 +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 NBz6+Ns57Rxf; Tue, 11 May 2010 21:57:19 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 634E5C0004; Tue, 11 May 2010 21:57:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5095E1207699; Tue, 11 May 2010 21:57:19 +0200 (CEST) Date: Tue, 11 May 2010 21:57:19 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100511195719.GB8428@elstar.local> Mail-Followup-To: Andy Bierman , Kent Watsen , 'Ladislav Lhotka' , "netconf@ietf.org" References: <1273322804.7078.110.camel@missotis> <4BE5B243.5070006@iwl.com> <20100508.225108.214646842.mbj@tail-f.com> <1273473685.1752.62.camel@missotis> <4BE7F4B2.5060602@bwijnen.net> <20100510140840.GA3760@elstar.local> <1273501090.1752.231.camel@missotis> <84600D05C20FF943918238042D7670FD36C7D76381@EMBX01-HQ.jnpr.net> <20100510193708.GA5246@elstar.local> <4BE98E6D.6020003@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BE98E6D.6020003@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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: Tue, 11 May 2010 19:57:33 -0000 On Tue, May 11, 2010 at 07:05:49PM +0200, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > .... > > I do not see the issue. If you can explain the three different default > > modes in 4741bis, then it should be possible to announce the > > basic-mode in 4741bis. How defaults are discovered is out of scope, > > independent of whether 4741bis includes the announcement of the > > basic-mode or not. For understanding how protocol operations behave, > > you only need a description of the three modes plus the announcement. > > This is not really true. > The only mode in which the meta-data tells you enough > is basic-mode=report-all. Do any NETCONF vendors > even use report-all as their basic mode? I doubt it. > The proponents of report-all (including me) want it > as a client-initiated debug mode. Did I say anything about meta-data in the text you quoted? I am kind of lost. > Knowing the basic-mode does not tell the client anything > definitive, except in the basic-mode nobody actually uses. For me, it makes a whole lot of a different to know whether a server is explicit or trim. > Advertising with-defaults basic-mode doesn't really > solve the create/delete ambiguity problem at all. > IMO, there is no reason to make this advertisement a > MUST implement for all 4741bis servers. The advertisement tells me what behaviour my client can expect. I do not see why not informing the client about the server's behaviour can make things simpler. We are going in circles. /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 May 11 13:29: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 D595B3A6C40 for ; Tue, 11 May 2010 13:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.097 X-Spam-Level: * X-Spam-Status: No, score=1.097 tagged_above=-999 required=5 tests=[AWL=-0.253, 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 6Lha9mRP1v0L for ; Tue, 11 May 2010 13:29:18 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7661E3A6A00 for ; Tue, 11 May 2010 13:26:59 -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 A680B2CDE057 for ; Tue, 11 May 2010 22:26:47 +0200 (CEST) From: Ladislav Lhotka To: netconf@ietf.org In-Reply-To: <201005111719.o4BHJBoH058183@idle.juniper.net> References: <201005111719.o4BHJBoH058183@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 11 May 2010 22:26:45 +0200 Message-ID: <1273609605.10083.32.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [Netconf] WG Chair question: where are we 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, 11 May 2010 20:29:18 -0000 Phil Shafer píše v Út 11. 05. 2010 v 13:19 -0400: > Juergen Schoenwaelder writes: > >>..... > >> Setting a leaf to the default value removes it from the configuration > >> database. So when I set "version" to "1", is disappears. > >OK, this makes it clear. > > Should we add a more detailed version of this discussion to the > w-d draft? Do we need to change the words "operationally behave" > to something that makes it clear we are talking about how the > device behaves, not how the server handles NETCONF operations? I think so, although IMO it's a slippery slope. I would prefer if the adjective "operationally" was removed entirely. Lada > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From bertietf@bwijnen.net Tue May 11 13:32: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 5DC643A691F for ; Tue, 11 May 2010 13:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.48 X-Spam-Level: * X-Spam-Status: No, score=1.48 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_20=-0.74, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=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 O50mFZUB7z10 for ; Tue, 11 May 2010 13:32:45 -0700 (PDT) Received: from relay.versatel.net (relay58.tele2.vuurwerk.nl [62.250.3.58]) by core3.amsl.com (Postfix) with ESMTP id 268A63A6987 for ; Tue, 11 May 2010 13:32:35 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1OBw7e-0004ay-Lm; Tue, 11 May 2010 22:32:10 +0200 Message-ID: <22D9DEAE72CD45DA82ABDFE81B005BC7@BertLaptop> From: "Bert Wijnen \(IETF\)" To: , "Phil Shafer" References: <201005111735.o4BHZhOY058563@idle.juniper.net> In-Reply-To: <201005111735.o4BHZhOY058563@idle.juniper.net> Date: Tue, 11 May 2010 22:31:23 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Cc: netconf@ietf.org Subject: Re: [Netconf] WG Chair question: where are we 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, 11 May 2010 20:32:46 -0000 Inline ----- Original Message ----- From: "Phil Shafer" To: Cc: Sent: Tuesday, May 11, 2010 7:35 PM Subject: Re: [Netconf] WG Chair question: where are we with defaults > Andy Bierman writes: >>I don't want any YANG-derivable meta-data included >>in the NETCONF standard . An old-client >>will not handle it at all, and not all new clients want >>this meta-data. Any 'server MAY send' is also >>a 'client MUST accept'. That's unacceptable. > > Old clients won't pass the new with-defaults parameter > to the server, so they won't get this new attribute. > >>The WG already rejected this proposal twice -- once >>on the mailing list, and once at an IETF meeting. >>There is no consensus or permission to expand the >>charter of the with-defaults draft. > > I don't recall this. I'm not sure this has been even been written > up as a concrete proposal. Can the chairs confirm please if the > WG has rejected this proposal twice? > I do not recall a concrete proposla either. I suggest that the person who claims that auch a proposal was rejected (so Andy in this case) provides a ptr to the suggested proposal and at least some time indication as to when it was discussed. Then I may be able to find it. Bert > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From phil@juniper.net Tue May 11 13:42: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 E48F03A691F for ; Tue, 11 May 2010 13:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.233 X-Spam-Level: X-Spam-Status: No, score=-6.233 tagged_above=-999 required=5 tests=[AWL=0.366, 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 LOk8XMezp67e for ; Tue, 11 May 2010 13:42:12 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 2EB843A67B5 for ; Tue, 11 May 2010 13:42:11 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKS+nBF+0aTS6ydtJ9IfgSs/EFLcKLJ3Y/@postini.com; Tue, 11 May 2010 13:42:01 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Tue, 11 May 2010 13:39:01 -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); Tue, 11 May 2010 13:39:01 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 May 2010 13:39:01 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 May 2010 13:39:00 -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 o4BKd0D72488; Tue, 11 May 2010 13:39:00 -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 o4BKLlfJ059953; Tue, 11 May 2010 20:21:47 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005112021.o4BKLlfJ059953@idle.juniper.net> To: Randy Presuhn In-Reply-To: <009301caf139$9e3e66c0$6801a8c0@oemcomputer> Date: Tue, 11 May 2010 16:21:47 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 May 2010 20:39:00.0742 (UTC) FILETIME=[FCAA8260:01CAF149] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] WG Chair question: where are we 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, 11 May 2010 20:42:13 -0000 "Randy Presuhn" writes: >Not true. The semantics of NETCONF don't support SNMP get-next, >for example, nor CMIP set-to-default, nor CMIP cancel-get. (The latter >could not even be emulated by created a new RPC.) Nor can >it handle CMIP's create-with-reference-object. Um, what about: 1.2.3.4.5.6.7 I'm not a CMIP-head, but next IETF maybe we should talk face-2-face about how CMIP operations are impossible to represent over an RPC-based protocol. >This would lead one to conclude that the behaviour of operations in netconf >is both implementation and data model specific. Doesn't sound like >much help for interoperability. The NETCONF WG elected to dodge the data modeling bullet, and left that for later. The NETMOD WG has produced YANG, which is IMHO a great way to model data for networing devices. Put the two together and I think you have an emmense improvement on network management, and if accepted and used by the IETF, this will be a monstrous help for interoperability. Thanks, Phil From phil@juniper.net Tue May 11 13:44: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 61B123A69E6 for ; Tue, 11 May 2010 13:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.243 X-Spam-Level: X-Spam-Status: No, score=-6.243 tagged_above=-999 required=5 tests=[AWL=0.356, 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 0S4fxawgZPaK for ; Tue, 11 May 2010 13:44:51 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 19A6F3A69AD for ; Tue, 11 May 2010 13:44:50 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKS+nBtXfyM5qoGeWgP/T3foIN04Fp7ryS@postini.com; Tue, 11 May 2010 13:44:41 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Tue, 11 May 2010 13:42:19 -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); Tue, 11 May 2010 13:42:19 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 May 2010 13:42:19 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 May 2010 13:42:18 -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 o4BKgID74076; Tue, 11 May 2010 13:42:18 -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 o4BKP5ln060060; Tue, 11 May 2010 20:25:05 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005112025.o4BKP5ln060060@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20100511195719.GB8428@elstar.local> Date: Tue, 11 May 2010 16:25:05 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 May 2010 20:42:18.0896 (UTC) FILETIME=[72C66900:01CAF14A] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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, 11 May 2010 20:44:52 -0000 Juergen Schoenwaelder writes: >For me, it makes a whole lot of a different to know whether a server >is explicit or trim. This is the part I'm missing. How will you use the knowledge that a particular server is trim or explicit in your code? The only difference is that trim will not return leafs whose value is equal to the default. If your client simply understand this is optional behavior, what further differences will it make for the client code? Thanks, Phil From phil@juniper.net Tue May 11 13:47: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 7A2353A69E6 for ; Tue, 11 May 2010 13:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.253 X-Spam-Level: X-Spam-Status: No, score=-6.253 tagged_above=-999 required=5 tests=[AWL=0.346, 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 Ul42a6BgxyJN for ; Tue, 11 May 2010 13:47:13 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id F0DBB3A691F for ; Tue, 11 May 2010 13:47:12 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKS+nCRM9SUMAFhhhlMWAJwrv8bYceTB38@postini.com; Tue, 11 May 2010 13:47:03 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Tue, 11 May 2010 13:44:05 -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); Tue, 11 May 2010 13:44:04 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 May 2010 13:44:04 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 May 2010 13:44:03 -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 o4BKi2D74853; Tue, 11 May 2010 13:44:02 -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 o4BKQouV060130; Tue, 11 May 2010 20:26:50 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005112026.o4BKQouV060130@idle.juniper.net> To: Ladislav Lhotka Date: Tue, 11 May 2010 16:26:50 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 May 2010 20:44:03.0723 (UTC) FILETIME=[B141BDB0:01CAF14A] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] WG Chair question: where are we 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, 11 May 2010 20:47:18 -0000 Ladislav Lhotka writes: >I think so, although IMO it's a slippery slope. I would prefer if the >adjective "operationally" was removed entirely. -1 Removing this word creates an unacceptable change to the draft. Thanks, Phil From lhotka@cesnet.cz Tue May 11 13:52: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 37AB73A68FE for ; Tue, 11 May 2010 13:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.012 X-Spam-Level: * X-Spam-Status: No, score=1.012 tagged_above=-999 required=5 tests=[AWL=-0.152, 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 372k5iKg-rUs for ; Tue, 11 May 2010 13:52:55 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 2B6A03A6A21 for ; Tue, 11 May 2010 13:52:38 -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 2B5B32CDE057 for ; Tue, 11 May 2010 22:52:27 +0200 (CEST) From: Ladislav Lhotka To: netconf@ietf.org In-Reply-To: <201005112025.o4BKP5ln060060@idle.juniper.net> References: <201005112025.o4BKP5ln060060@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 11 May 2010 22:52:25 +0200 Message-ID: <1273611145.10083.38.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [Netconf] WG Chair question: where are we 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, 11 May 2010 20:52:56 -0000 Phil Shafer píše v Út 11. 05. 2010 v 16:25 -0400: > Juergen Schoenwaelder writes: > >For me, it makes a whole lot of a different to know whether a server > >is explicit or trim. > > This is the part I'm missing. How will you use the knowledge that > a particular server is trim or explicit in your code? The only > difference is that trim will not return leafs whose value is equal > to the default. If your client simply understand this is optional > behavior, what further differences will it make for the client code? Configuration scripts that work for a "trim" server may fail for an "explicit" server and vice versa. Lada > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Tue May 11 14:38: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 6032C3A69CD for ; Tue, 11 May 2010 14:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.975 X-Spam-Level: X-Spam-Status: No, score=-2.975 tagged_above=-999 required=5 tests=[AWL=0.624, 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 XQ4W87E7z0Us for ; Tue, 11 May 2010 14:38:01 -0700 (PDT) Received: from smtp214.iad.emailsrvr.com (smtp214.iad.emailsrvr.com [207.97.245.214]) by core3.amsl.com (Postfix) with ESMTP id 08C833A697B for ; Tue, 11 May 2010 14:37:54 -0700 (PDT) Received: from relay11.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay11.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 3D3C01B40A4; Tue, 11 May 2010 17:37:42 -0400 (EDT) Received: by relay11.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id A5DAB1B403F; Tue, 11 May 2010 17:37:41 -0400 (EDT) Message-ID: <4BE9CE44.30506@iwl.com> Date: Tue, 11 May 2010 14:38:12 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <201005111735.o4BHZhOY058563@idle.juniper.net> <22D9DEAE72CD45DA82ABDFE81B005BC7@BertLaptop> In-Reply-To: <22D9DEAE72CD45DA82ABDFE81B005BC7@BertLaptop> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] WG Chair question: where are we 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: Tue, 11 May 2010 21:38:06 -0000 Bert Wijnen (IETF) wrote: > Inline > > ----- Original Message ----- From: "Phil Shafer" > To: > Cc: > Sent: Tuesday, May 11, 2010 7:35 PM > Subject: Re: [Netconf] WG Chair question: where are we with defaults > > >> Andy Bierman writes: >>> I don't want any YANG-derivable meta-data included >>> in the NETCONF standard . An old-client >>> will not handle it at all, and not all new clients want >>> this meta-data. Any 'server MAY send' is also >>> a 'client MUST accept'. That's unacceptable. >> >> Old clients won't pass the new with-defaults parameter >> to the server, so they won't get this new attribute. >> >>> The WG already rejected this proposal twice -- once >>> on the mailing list, and once at an IETF meeting. >>> There is no consensus or permission to expand the >>> charter of the with-defaults draft. >> >> I don't recall this. I'm not sure this has been even been written >> up as a concrete proposal. Can the chairs confirm please if the >> WG has rejected this proposal twice? >> > > I do not recall a concrete proposla either. I suggest that the person > who claims that auch a proposal was rejected > (so Andy in this case) provides a ptr to the suggested proposal and at > least some time indication as to when it was discussed. Then I may > be able to find it. I do not recall the email thread conclusion. I do recall the discussion at the IETF meeting, and the room decision was not to add any XML attributes to the with-defaults reply. The only person who objected to the room decision on the ML was the person who proposed the change. I do not recall any emails or WG meeting minutes that declared that the with-defaults charter has been expanded to include XML attributes in the rpc-reply. Can you point out that email? IMO, expansion of the charter for this document has not been agreed upon, and the problem/solution proposal has not been properly presented to the WG. > > Bert Andy From andyb@iwl.com Tue May 11 14:45: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 820F93A6A82 for ; Tue, 11 May 2010 14:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_05=-1.11, 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 4ZYREHdCWGEm for ; Tue, 11 May 2010 14:45:07 -0700 (PDT) Received: from smtp214.iad.emailsrvr.com (smtp214.iad.emailsrvr.com [207.97.245.214]) by core3.amsl.com (Postfix) with ESMTP id EEF603A6A87 for ; Tue, 11 May 2010 14:45:06 -0700 (PDT) Received: from relay11.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay11.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 43EDD1B4161; Tue, 11 May 2010 17:44:56 -0400 (EDT) Received: by relay11.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id BDDA71B40A4; Tue, 11 May 2010 17:44:55 -0400 (EDT) Message-ID: <4BE9CFF7.1080400@iwl.com> Date: Tue, 11 May 2010 14:45:27 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Ladislav Lhotka References: <201005112025.o4BKP5ln060060@idle.juniper.net> <1273611145.10083.38.camel@missotis> In-Reply-To: <1273611145.10083.38.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] WG Chair question: where are we 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: Tue, 11 May 2010 21:45:09 -0000 Ladislav Lhotka wrote: > Phil Shafer píše v Út 11. 05. 2010 v 16:25 -0400: > >> Juergen Schoenwaelder writes: >> >>> For me, it makes a whole lot of a different to know whether a server >>> is explicit or trim. >>> >> This is the part I'm missing. How will you use the knowledge that >> a particular server is trim or explicit in your code? The only >> difference is that trim will not return leafs whose value is equal >> to the default. If your client simply understand this is optional >> behavior, what further differences will it make for the client code? >> > > Configuration scripts that work for a "trim" server may fail for an > "explicit" server and vice versa. > > Can you expand on this generalization? It doesn't matter for merge/replace. For create/delete, the client really needs to do a get-config first. I don't see how the client knows if the leaf contains the default or normal value already, so it knows whether create/delete should work or not. How realistic is it for a client to do creates or deletes without first doing a get-config? BTW, one of the use-cases for report-all is to retrieve an XML document that can be used for off-line validation. How does the possible inclusion of XML attributes in this XML document affect off-line validation? Seems like this would cause a problem. > Lada > Andy From andyb@iwl.com Tue May 11 14:57: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 7B2043A69C1 for ; Tue, 11 May 2010 14:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.989 X-Spam-Level: X-Spam-Status: No, score=-2.989 tagged_above=-999 required=5 tests=[AWL=0.610, 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 BNeM4EUuQFLp for ; Tue, 11 May 2010 14:57:55 -0700 (PDT) Received: from smtp214.iad.emailsrvr.com (smtp214.iad.emailsrvr.com [207.97.245.214]) by core3.amsl.com (Postfix) with ESMTP id 658FC3A69DF for ; Tue, 11 May 2010 14:57:55 -0700 (PDT) Received: from relay11.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay11.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 52A1F1B4088; Tue, 11 May 2010 17:57:44 -0400 (EDT) Received: by relay11.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 56A7D1B53AE; Tue, 11 May 2010 17:57:43 -0400 (EDT) Message-ID: <4BE9D2EF.6050901@iwl.com> Date: Tue, 11 May 2010 14:58:07 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201005111735.o4BHZhOY058563@idle.juniper.net> In-Reply-To: <201005111735.o4BHZhOY058563@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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: Tue, 11 May 2010 21:57:56 -0000 Phil Shafer wrote: > Andy Bierman writes: > >> I don't want any YANG-derivable meta-data included >> in the NETCONF standard . An old-client >> will not handle it at all, and not all new clients want >> this meta-data. Any 'server MAY send' is also >> a 'client MUST accept'. That's unacceptable. >> > > Old clients won't pass the new with-defaults parameter > to the server, so they won't get this new attribute. > > I'm still confused why clients need an attribute added to the reply. That's why a real draft should be submitted, so the WG can understand this problem more. It seems rather strange that the company that insists 'report-all' is pointless and does not want to implement it, also insists that the report-all reply needs XML attributes added to it. > Thanks, > Phil > > Andy From kwatsen@juniper.net Tue May 11 15:28: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 B0C083A6BF4 for ; Tue, 11 May 2010 15:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_05=-1.11, 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 xi-py7PiYi+T for ; Tue, 11 May 2010 15:28:38 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 958083A6C26 for ; Tue, 11 May 2010 15:27:40 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKS+nZz0I/y7Pp7a7LjU/LakbxZp+j6+/q@postini.com; Tue, 11 May 2010 15:27:30 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 11 May 2010 15:24:24 -0700 From: Kent Watsen To: Phil Shafer , Juergen Schoenwaelder Date: Tue, 11 May 2010 15:24:23 -0700 Thread-Topic: [Netconf] WG Chair question: where are we with defaults Thread-Index: AcrxSssFJw/e9SrIT6mKA6npeDeblgADMw6w Message-ID: <84600D05C20FF943918238042D7670FD36C7D7639C@EMBX01-HQ.jnpr.net> References: <20100511195719.GB8428@elstar.local> <201005112025.o4BKP5ln060060@idle.juniper.net> In-Reply-To: <201005112025.o4BKP5ln060060@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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, 11 May 2010 22:28:39 -0000 =20 > This is the part I'm missing. How will you use the knowledge=20 > that a particular server is trim or explicit in your code? =20 > The only difference is that trim will not return leafs whose=20 > value is equal to the default. If your client simply=20 > understand this is optional behavior, what further=20 > differences will it make for the client code? Primarily to allow an NMS provide a better user-experience. For instance, = if user sets a value same as default, an NMS can note that the operation ha= s no affect on report-all/trim servers. Likewise, if value is already defa= ult, an NMS can disable "clear to default" option on report-all/trim server= s and highlight that the value is explicitly set on an explicit server. Thanks, Kent From randy_presuhn@mindspring.com Tue May 11 15:30: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 20CB43A68E4 for ; Tue, 11 May 2010 15:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.222 X-Spam-Level: X-Spam-Status: No, score=-0.222 tagged_above=-999 required=5 tests=[AWL=-0.037, 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 UTCqjMk-H1r5 for ; Tue, 11 May 2010 15:30:43 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 12C833A6800 for ; Tue, 11 May 2010 15:30:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ZBVvAVUvZAMopjEIYPOyNZZX5Ru8b9271gLbfbn7ojoEf7qb5cloKkbLPLgNez3z; 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.152] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OBxyC-0004Xe-A7 for netconf@ietf.org; Tue, 11 May 2010 18:30:32 -0400 Message-ID: <002901caf159$94b73b20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <201005112021.o4BKLlfJ059953@idle.juniper.net> Date: Tue, 11 May 2010 15:30:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035a510a399854f7d56a8a62477131ddae7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.49.152 Subject: Re: [Netconf] WG Chair question: where are we 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, 11 May 2010 22:30:45 -0000 Hi - > From: "Phil Shafer" > To: "Randy Presuhn" > Cc: > Sent: Tuesday, May 11, 2010 1:21 PM > Subject: Re: [Netconf] WG Chair question: where are we with defaults > > "Randy Presuhn" writes: > >Not true. The semantics of NETCONF don't support SNMP get-next, > >for example, nor CMIP set-to-default, nor CMIP cancel-get. (The latter > >could not even be emulated by created a new RPC.) Nor can > >it handle CMIP's create-with-reference-object. > > Um, what about: > > > 1.2.3.4.5.6.7 > That's not netconf. That's a protocol you've overlayed on netconf, and has nothing to do with the semantics of netconf. When you've explained how the behaviour of this RPC in the presence of access control would match that of SNMP, you'll only have scratched the surface. But you could do the same thing with FTP or HTTP, and I'd find those equally unpersuasive. The particular case of cancel-get cannot even be emulated with RPC, because its behaviour is at odds with netconf's request/response flow. Cancel-get would be used while a long series of linked replies is coming down the pipe. In CMIP, a get may result in many responses. This operation provides a way to say "no more, I didn't mean to ask for a recursive listing of the entire tree." > I'm not a CMIP-head, but next IETF maybe we should talk > face-2-face about how CMIP operations are impossible > to represent over an RPC-based protocol. CMIP specifics are a moot point. The issue is that protocol design DOES make assumptions about models. The lack of attention given to this will come back to haunt netconf. > >This would lead one to conclude that the behaviour of operations in netconf > >is both implementation and data model specific. Doesn't sound like > >much help for interoperability. > > The NETCONF WG elected to dodge the data modeling bullet, and > left that for later. The NETMOD WG has produced YANG, which > is IMHO a great way to model data for networing devices. Put > the two together and I think you have an emmense improvement > on network management, and if accepted and used by the IETF, > this will be a monstrous help for interoperability. I am amazed by your faith, and hope you are correct. Randy From kwatsen@juniper.net Tue May 11 15:32: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 C84733A6BF4 for ; Tue, 11 May 2010 15:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.846 X-Spam-Level: X-Spam-Status: No, score=-5.846 tagged_above=-999 required=5 tests=[AWL=0.753, 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 RWmNyW5gByWH for ; Tue, 11 May 2010 15:32:43 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id D2A8D3A6AAF for ; Tue, 11 May 2010 15:32:34 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKS+na9kbyC6RqdG8QndHsamHKxlkrtBjF@postini.com; Tue, 11 May 2010 15:32:24 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 11 May 2010 15:29:43 -0700 From: Kent Watsen To: "'andyb@iwl.com'" , Ladislav Lhotka Date: Tue, 11 May 2010 15:29:43 -0700 Thread-Topic: [Netconf] WG Chair question: where are we with defaults Thread-Index: AcrxU2WqCBd/WA/bSK+r5u/UBUiFrAABZNJg Message-ID: <84600D05C20FF943918238042D7670FD36C7D7639D@EMBX01-HQ.jnpr.net> References: <201005112025.o4BKP5ln060060@idle.juniper.net> <1273611145.10083.38.camel@missotis> <4BE9CFF7.1080400@iwl.com> In-Reply-To: <4BE9CFF7.1080400@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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, 11 May 2010 22:32:45 -0000 =20 > How realistic is it for a client to do creates or deletes=20 > without first doing a get-config? I tend to agree. I'm personally less worried about failing protocol operat= ions as an NMS's basic "update device" algorithm will likely diff against t= he device to calc what the should look like, and thus should = never create a node that already exists or delete a node that doesn't Thanks, Kent From kwatsen@juniper.net Tue May 11 15:58: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 823F73A69E5 for ; Tue, 11 May 2010 15:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.896 X-Spam-Level: X-Spam-Status: No, score=-5.896 tagged_above=-999 required=5 tests=[AWL=0.703, 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 dtECIRs5j0C2 for ; Tue, 11 May 2010 15:58:45 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 9AB293A69A1 for ; Tue, 11 May 2010 15:58:45 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKS+nhGYP15R2vYTGw0R0jvKguefxGGvrx@postini.com; Tue, 11 May 2010 15:58:35 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 11 May 2010 15:57:34 -0700 From: Kent Watsen To: "'andyb@iwl.com'" , Phil Shafer Date: Tue, 11 May 2010 15:57:33 -0700 Thread-Topic: [Netconf] WG Chair question: where are we with defaults Thread-Index: AcrxVQ4Ny9ssNeWXTkOy2qjNIIlLDAAA8k+g Message-ID: <84600D05C20FF943918238042D7670FD36C7D7639E@EMBX01-HQ.jnpr.net> References: <201005111735.o4BHZhOY058563@idle.juniper.net> <4BE9D2EF.6050901@iwl.com> In-Reply-To: <4BE9D2EF.6050901@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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, 11 May 2010 22:58:46 -0000 =20 > It seems rather strange that the company that insists=20 > 'report-all' is pointless and does not want to implement it,=20 > also insists that the report-all reply needs XML attributes=20 > added to it. That is a mischaracterization - our request has consistently been to *eithe= r* remove the "MUST implement report-all" or make it safe by tagging defaul= ts. Also, we argued that report-all is useful for thin clients (i.e. not p= ointless). Thanks, Kent From andyb@iwl.com Tue May 11 16:00: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 AF6F13A69A1 for ; Tue, 11 May 2010 16:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[AWL=-0.343, 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 OUJysevVxDHX for ; Tue, 11 May 2010 16:00:27 -0700 (PDT) Received: from smtp194.dfw.emailsrvr.com (smtp194.dfw.emailsrvr.com [67.192.241.194]) by core3.amsl.com (Postfix) with ESMTP id 59A013A6853 for ; Tue, 11 May 2010 16:00:25 -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 90EA82748B6F; Tue, 11 May 2010 19:00:14 -0400 (EDT) Received: by relay19.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 536DA2748CE2; Tue, 11 May 2010 19:00:14 -0400 (EDT) Message-ID: <4BE9E19F.7020605@iwl.com> Date: Tue, 11 May 2010 16:00:47 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <201005112025.o4BKP5ln060060@idle.juniper.net> <1273611145.10083.38.camel@missotis> <4BE9CFF7.1080400@iwl.com> <84600D05C20FF943918238042D7670FD36C7D7639D@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D7639D@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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: Tue, 11 May 2010 23:00:27 -0000 Kent Watsen wrote: > > >> How realistic is it for a client to do creates or deletes without >> first doing a get-config? > > > I tend to agree. I'm personally less worried about failing protocol > operations as an NMS's basic "update device" algorithm will likely > diff against the device to calc what the should look > like, and thus should never create a node that already exists or > delete a node that doesn't > What may be good for your thin client is bad for my thin client. I have modular applications and the program that knows about get-config requests/replies may not be the same program as the the one that would have to strip XML attributes out of the reply. The former does not know how to strip attributes out of the reply, and the latter does not correlate requests with replies, so it doesn't know it should strip out particular XML attributes. So unless my thin client can request report-all without any XML attributes added, it breaks. These attributes cause false diffs, and cause unknown-attribute errors during off-line validation. > > Thanks, Kent > Andy From kwatsen@juniper.net Tue May 11 16:04: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 E0A973A6A04 for ; Tue, 11 May 2010 16:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.94 X-Spam-Level: X-Spam-Status: No, score=-5.94 tagged_above=-999 required=5 tests=[AWL=0.659, 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 O-iK3AlqAD1B for ; Tue, 11 May 2010 16:04:04 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id CEA3B3A695C for ; Tue, 11 May 2010 16:04:03 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKS+niWJvzZa470OoXIp7NX7NNzpMZgm6E@postini.com; Tue, 11 May 2010 16:03:53 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 11 May 2010 16:02:09 -0700 From: Kent Watsen To: "'andyb@iwl.com'" Date: Tue, 11 May 2010 16:02:08 -0700 Thread-Topic: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt Thread-Index: AcrwohJ0wI/Uy6SaRnyNvJxI+WeaXgAuzuTA Message-ID: <84600D05C20FF943918238042D7670FD36C7D7639F@EMBX01-HQ.jnpr.net> References: <201005061837.o46IbNKd064651@idle.juniper.net> <4BE31209.3060507@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76372@EMBX01-HQ.jnpr.net> <4BE4757F.7050909@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76376@EMBX01-HQ.jnpr.net> <4BE49139.7050607@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76380@EMBX01-HQ.jnpr.net> <4BE848F8.3090809@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76387@EMBX01-HQ.jnpr.net> <4BE8908A.1040602@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76389@EMBX01-HQ.jnpr.net> <4BE8A6C4.8070502@iwl.com> In-Reply-To: <4BE8A6C4.8070502@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 23:04:05 -0000 > I agree it is OK to change MUST support report-all to SHOULD=20 > support report-all, especially if it means we can finally=20 > stop debating defaults. >=20 > If the server does not have any 'also-supported' values, then=20 > the leaf accepts only 1 value so it's pointless. > The conformance for the YANG module would be: >=20 > - MUST implement ietf-netconf-with-defaults.yang > if the 'also-supported' parameter is used in the > :with-defaults capability advertisement. >=20 Can we make the following change to the I-D? "A NETCONF server implementing the :with-defaults capability MUST indicate its basic behavior, whether it sends default data in the + absence of any specific request from the NETCONF client; and SHOULD - absence of any specific request from the NETCONF client; and MUST support the 'report-all' handling mode and MAY support other modes." Thanks, Kent From andyb@iwl.com Tue May 11 16:29: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 AB5F93A6C0E for ; Tue, 11 May 2010 16:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[AWL=0.593, 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 MNcnvhzcipII for ; Tue, 11 May 2010 16:29:58 -0700 (PDT) Received: from smtp114.dfw.emailsrvr.com (smtp114.dfw.emailsrvr.com [67.192.241.114]) by core3.amsl.com (Postfix) with ESMTP id 05A4F3A69CE for ; Tue, 11 May 2010 16:29:55 -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 795332E405D3; Tue, 11 May 2010 19:29:45 -0400 (EDT) Received: by relay21.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 454152E405BF; Tue, 11 May 2010 19:29:45 -0400 (EDT) Message-ID: <4BE9E889.6010508@iwl.com> Date: Tue, 11 May 2010 16:30:17 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <201005061837.o46IbNKd064651@idle.juniper.net> <4BE31209.3060507@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76372@EMBX01-HQ.jnpr.net> <4BE4757F.7050909@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76376@EMBX01-HQ.jnpr.net> <4BE49139.7050607@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76380@EMBX01-HQ.jnpr.net> <4BE848F8.3090809@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76387@EMBX01-HQ.jnpr.net> <4BE8908A.1040602@iwl.com> <84600D05C20FF943918238042D7670FD36C7D76389@EMBX01-HQ.jnpr.net> <4BE8A6C4.8070502@iwl.com> <84600D05C20FF943918238042D7670FD36C7D7639F@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D7639F@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 11 May 2010 23:29:58 -0000 Kent Watsen wrote: > >> I agree it is OK to change MUST support report-all to SHOULD >> support report-all, especially if it means we can finally >> stop debating defaults. >> >> If the server does not have any 'also-supported' values, then >> the leaf accepts only 1 value so it's pointless. >> The conformance for the YANG module would be: >> >> - MUST implement ietf-netconf-with-defaults.yang >> if the 'also-supported' parameter is used in the >> :with-defaults capability advertisement. >> >> > > > > Can we make the following change to the I-D? > > "A NETCONF server implementing the :with-defaults capability MUST > indicate its basic behavior, whether it sends default data in the > + absence of any specific request from the NETCONF client; and SHOULD > - absence of any specific request from the NETCONF client; and MUST > support the 'report-all' handling mode and MAY support other modes." > > What is the point of having also-supported modes in the standard, but no way to make sure there is a standard way to access these other modes? The YANG module is needed if also-supported in non-empty. > Thanks, > Kent > > > > > Andy From kwatsen@juniper.net Tue May 11 16:39: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 DE2233A6A18 for ; Tue, 11 May 2010 16:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.235 X-Spam-Level: X-Spam-Status: No, score=-5.235 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_05=-1.11, 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 lLgVXNvyhJIc for ; Tue, 11 May 2010 16:39:26 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 8AEB33A68BF for ; Tue, 11 May 2010 16:39:26 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKS+nqorPOflc/+2bVVu8FzGRzff7G3tl8@postini.com; Tue, 11 May 2010 16:39:16 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Tue, 11 May 2010 16:37:37 -0700 From: Kent Watsen To: "'andyb@iwl.com'" Date: Tue, 11 May 2010 16:37:37 -0700 Thread-Topic: [Netconf] WG Chair question: where are we with defaults Thread-Index: AcrxXbib9o/yq5BtQgqHvgLB+C8iHgAAHOZA Message-ID: <84600D05C20FF943918238042D7670FD36C7D763A0@EMBX01-HQ.jnpr.net> References: <201005112025.o4BKP5ln060060@idle.juniper.net> <1273611145.10083.38.camel@missotis> <4BE9CFF7.1080400@iwl.com> <84600D05C20FF943918238042D7670FD36C7D7639D@EMBX01-HQ.jnpr.net> <4BE9E19F.7020605@iwl.com> In-Reply-To: <4BE9E19F.7020605@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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, 11 May 2010 23:39:28 -0000 > >> How realistic is it for a client to do creates or deletes without=20 > >> first doing a get-config? > > > > > > I tend to agree. I'm personally less worried about failing=20 > protocol=20 > > operations as an NMS's basic "update device" algorithm will likely=20 > > diff against the device to calc what the should look=20 > > like, and thus should never create a node that already exists or=20 > > delete a node that doesn't > > >=20 > What may be good for your thin client is bad for my thin client. > I have modular applications and the program that knows about=20 > get-config requests/replies may not be the same program as=20 > the the one that would have to strip XML attributes out of the reply. Huh? I thought this fork in the thread was debating the reason why advertis= ing the basic-mode might be a MUST... Also, note that I was agreeing with = you! ;) > The former does not know how to strip attributes out of the=20 > reply, and the latter does not correlate requests with=20 > replies, so it doesn't know it should strip out particular=20 > XML attributes. I don't understand how why client coded to request report-all would be unab= le to strip out attributes (s/wd:default=3D\"true\"//g) > So unless my thin client can request report-all without any=20 > XML attributes added, it breaks. These attributes cause=20 > false diffs, and cause unknown-attribute errors during=20 > off-line validation. >From what I wrote on 5/7: If we allow tagging defaults, I think we should let trim/explicit servers a= dvertise if the tagging is: - not supported by the server - supported, but must be asked for - default, may be disabled - always on, no way to disable Your arguing that, if we support tagging defaults, you'd want to remove the= last option - right? Thanks, Kent From andyb@iwl.com Tue May 11 17:08: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 0DFA03A6934 for ; Tue, 11 May 2010 17:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.476 X-Spam-Level: X-Spam-Status: No, score=-0.476 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_40=-0.185, 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 YlaBAjWkuvpm for ; Tue, 11 May 2010 17:08:34 -0700 (PDT) Received: from smtp174.dfw.emailsrvr.com (smtp174.dfw.emailsrvr.com [67.192.241.174]) by core3.amsl.com (Postfix) with ESMTP id 35AA03A68F2 for ; Tue, 11 May 2010 17:08:34 -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 87278CE4E47; Tue, 11 May 2010 20:08:23 -0400 (EDT) Received: by relay7.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 3E827CE4E16; Tue, 11 May 2010 20:08:23 -0400 (EDT) Message-ID: <4BE9F198.8010504@iwl.com> Date: Tue, 11 May 2010 17:08:56 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <201005112025.o4BKP5ln060060@idle.juniper.net> <1273611145.10083.38.camel@missotis> <4BE9CFF7.1080400@iwl.com> <84600D05C20FF943918238042D7670FD36C7D7639D@EMBX01-HQ.jnpr.net> <4BE9E19F.7020605@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763A0@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D763A0@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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, 12 May 2010 00:08:35 -0000 Kent Watsen wrote: >>>> How realistic is it for a client to do creates or deletes without >>>> first doing a get-config? >>>> >>> I tend to agree. I'm personally less worried about failing >>> >> protocol >> >>> operations as an NMS's basic "update device" algorithm will likely >>> diff against the device to calc what the should look >>> like, and thus should never create a node that already exists or >>> delete a node that doesn't >>> >>> >> What may be good for your thin client is bad for my thin client. >> I have modular applications and the program that knows about >> get-config requests/replies may not be the same program as >> the the one that would have to strip XML attributes out of the reply. >> > > Huh? I thought this fork in the thread was debating the reason why advertising the basic-mode might be a MUST... Also, note that I was agreeing with you! ;) > > > > >> The former does not know how to strip attributes out of the >> reply, and the latter does not correlate requests with >> replies, so it doesn't know it should strip out particular >> XML attributes. >> > > I don't understand how why client coded to request report-all would be unable to strip out attributes (s/wd:default=\"true\"//g) > > > The code is separated, so it can't strip out XML attributes. I don't know why your code can't diff 2 XML trees. The point is that my thin client has just as much right to NOT get XML attributes as your thin client has a right to get them. Why should my thin client that already works with the current WG solution break for some new addition that my thin client does not want? I want the server to respond exactly as I request. If the server MAY add stuff I don't want, then the operation is no use to me. > >> So unless my thin client can request report-all without any >> XML attributes added, it breaks. These attributes cause >> false diffs, and cause unknown-attribute errors during >> off-line validation. >> > > >From what I wrote on 5/7: > > > If we allow tagging defaults, I think we should let trim/explicit servers advertise if the tagging is: > - not supported by the server > - supported, but must be asked for > - default, may be disabled > - always on, no way to disable > > > Your arguing that, if we support tagging defaults, you'd want to remove the last option - right? > > I do not want the server to decide what to send. I want the client to always decide. I also want the server to be able to not implement this XML attribute. basic-mode = [trim | explicit | report-all] also-supported = 0 or more of [trim | explicit | report-all | report-all-tagged] [full-list-of-enums] This fixes the problem. If the server wants to support this XML attribute, it will list it in its also-supported parameter. If the client wants report-all-tagged, it will ask for it. > Thanks, > Kent > > > > Andy From andyb@iwl.com Tue May 11 17:21: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 978DA3A688C for ; Tue, 11 May 2010 17:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=-0.336, 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 TYR4emUWeohZ for ; Tue, 11 May 2010 17:21:46 -0700 (PDT) Received: from smtp204.iad.emailsrvr.com (smtp204.iad.emailsrvr.com [207.97.245.204]) by core3.amsl.com (Postfix) with ESMTP id 984363A6A04 for ; Tue, 11 May 2010 17:21:20 -0700 (PDT) Received: from relay20.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay20.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id B826C1B40CC; Tue, 11 May 2010 20:21:09 -0400 (EDT) Received: by relay20.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 295681B406D; Tue, 11 May 2010 20:21:09 -0400 (EDT) Message-ID: <4BE9F495.9010801@iwl.com> Date: Tue, 11 May 2010 17:21:41 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: andyb@iwl.com References: <201005112025.o4BKP5ln060060@idle.juniper.net> <1273611145.10083.38.camel@missotis> <4BE9CFF7.1080400@iwl.com> <84600D05C20FF943918238042D7670FD36C7D7639D@EMBX01-HQ.jnpr.net> <4BE9E19F.7020605@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763A0@EMBX01-HQ.jnpr.net> <4BE9F198.8010504@iwl.com> In-Reply-To: <4BE9F198.8010504@iwl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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, 12 May 2010 00:21:51 -0000 Andy Bierman wrote: > Kent Watsen wrote: > >>>>> How realistic is it for a client to do creates or deletes without >>>>> first doing a get-config? >>>>> >>>>> >>>> I tend to agree. I'm personally less worried about failing >>>> >>>> >>> protocol >>> >>> >>>> operations as an NMS's basic "update device" algorithm will likely >>>> diff against the device to calc what the should look >>>> like, and thus should never create a node that already exists or >>>> delete a node that doesn't >>>> >>>> >>>> >>> What may be good for your thin client is bad for my thin client. >>> I have modular applications and the program that knows about >>> get-config requests/replies may not be the same program as >>> the the one that would have to strip XML attributes out of the reply. >>> >>> >> Huh? I thought this fork in the thread was debating the reason why advertising the basic-mode might be a MUST... Also, note that I was agreeing with you! ;) >> >> >> >> >> >>> The former does not know how to strip attributes out of the >>> reply, and the latter does not correlate requests with >>> replies, so it doesn't know it should strip out particular >>> XML attributes. >>> >>> >> I don't understand how why client coded to request report-all would be unable to strip out attributes (s/wd:default=\"true\"//g) >> >> >> >> > > The code is separated, so it can't strip out XML attributes. > I don't know why your code can't diff 2 XML trees. > The point is that my thin client has just as much right to > NOT get XML attributes as your thin client has a right > to get them. Why should my thin client that already > works with the current WG solution break for some > new addition that my thin client does not want? > > I want the server to respond exactly as I request. > If the server MAY add stuff I don't want, then > the operation is no use to me. > > > > > > >> >> >>> So unless my thin client can request report-all without any >>> XML attributes added, it breaks. These attributes cause >>> false diffs, and cause unknown-attribute errors during >>> off-line validation. >>> >>> >> >From what I wrote on 5/7: >> >> >> If we allow tagging defaults, I think we should let trim/explicit servers advertise if the tagging is: >> - not supported by the server >> - supported, but must be asked for >> - default, may be disabled >> - always on, no way to disable >> >> >> Your arguing that, if we support tagging defaults, you'd want to remove the last option - right? >> >> >> > > I do not want the server to decide what to send. > I want the client to always decide. I also want > the server to be able to not implement this XML attribute. > > basic-mode = [trim | explicit | report-all] > > also-supported = 0 or more of > [trim | explicit | report-all | report-all-tagged] > > [full-list-of-enums] > > > This fixes the problem. > If the server wants to support this XML attribute, > it will list it in its also-supported parameter. > If the client wants report-all-tagged, it will ask for it. > > > Actually, the XML attribute tagging does not work with YANG. YANG does not support XML attributes, and a hack like the one in ietf-netconf.yang to support applies to a specific XML element. I don't know how to write a YANG extension that would allow a YANG validation program to properly deal with NETCONF PDUs that contain the XML attribute in random elements. All the more reason for you to write a draft explaining the solution in detail. >> Thanks, >> Kent >> >> >> >> >> > > Andy > Andy From kwatsen@juniper.net Tue May 11 17:49: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 6A93F3A69F2 for ; Tue, 11 May 2010 17:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.972 X-Spam-Level: X-Spam-Status: No, score=-5.972 tagged_above=-999 required=5 tests=[AWL=0.627, 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 kKCU+cxR+GuF for ; Tue, 11 May 2010 17:49:02 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 5574E3A6823 for ; Tue, 11 May 2010 17:49:02 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKS+n68/aCrMVynDPIxfhjMO3S514+Dsrt@postini.com; Tue, 11 May 2010 17:48:52 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 11 May 2010 17:46:46 -0700 From: Kent Watsen To: "'andyb@iwl.com'" Date: Tue, 11 May 2010 17:46:46 -0700 Thread-Topic: [Netconf] WG Chair question: where are we with defaults Thread-Index: AcrxaQbLL5mGEvnPSNiNLMIt3eZg5QAAvt8A Message-ID: <84600D05C20FF943918238042D7670FD36C7D763A1@EMBX01-HQ.jnpr.net> References: <201005112025.o4BKP5ln060060@idle.juniper.net> <1273611145.10083.38.camel@missotis> <4BE9CFF7.1080400@iwl.com> <84600D05C20FF943918238042D7670FD36C7D7639D@EMBX01-HQ.jnpr.net> <4BE9E19F.7020605@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763A0@EMBX01-HQ.jnpr.net> <4BE9F198.8010504@iwl.com> <4BE9F495.9010801@iwl.com> In-Reply-To: <4BE9F495.9010801@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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, 12 May 2010 00:49:03 -0000 =20 > Actually, the XML attribute tagging does not work with YANG. > YANG does not support XML attributes, and a hack like the one=20 > in ietf-netconf.yang to support applies to a=20 > specific XML element. I don't know how to write a YANG=20 > extension that would allow a YANG validation program to=20 > properly deal with NETCONF PDUs that contain the XML=20 > attribute in random elements. >=20 > All the more reason for you to write a draft explaining the=20 > solution in detail. This is why on 4/5 I asked: One thing I'm not clear on is the extent that a YANG module definition must= itself use YANG - specifically for protocol modifications. For instance, = the with-defaults I-D has YANG statements like: augment /nc:get-config/nc:input { uses with-defaults-parameters; } Are these *required* because YANG compilers MUST be 100% data-driven? - or= could this I-D have alternatively left it developer to read the RFC cited = by the module's "reference" statement? =20 Are you saying your "YANG validation program" will be 100% data-driven? Thanks, Kent From andyb@iwl.com Tue May 11 19:03: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 D6DD93A6ACD for ; Tue, 11 May 2010 19:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[AWL=-0.698, 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 vP6VKt2j3Tie for ; Tue, 11 May 2010 19:03:36 -0700 (PDT) Received: from smtp204.iad.emailsrvr.com (smtp204.iad.emailsrvr.com [207.97.245.204]) by core3.amsl.com (Postfix) with ESMTP id DD95B3A67AB for ; Tue, 11 May 2010 19:03:31 -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 584901E5D8D; Tue, 11 May 2010 22:03:21 -0400 (EDT) Received: by relay10.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id E05311E58E3; Tue, 11 May 2010 22:03:20 -0400 (EDT) Message-ID: <4BEA0C8A.7090702@iwl.com> Date: Tue, 11 May 2010 19:03:54 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <201005112025.o4BKP5ln060060@idle.juniper.net> <1273611145.10083.38.camel@missotis> <4BE9CFF7.1080400@iwl.com> <84600D05C20FF943918238042D7670FD36C7D7639D@EMBX01-HQ.jnpr.net> <4BE9E19F.7020605@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763A0@EMBX01-HQ.jnpr.net> <4BE9F198.8010504@iwl.com> <4BE9F495.9010801@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763A1@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D763A1@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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, 12 May 2010 02:03:36 -0000 Kent Watsen wrote: > > > >> Actually, the XML attribute tagging does not work with YANG. >> YANG does not support XML attributes, and a hack like the one >> in ietf-netconf.yang to support applies to a >> specific XML element. I don't know how to write a YANG >> extension that would allow a YANG validation program to >> properly deal with NETCONF PDUs that contain the XML >> attribute in random elements. >> >> All the more reason for you to write a draft explaining the >> solution in detail. >> > > > This is why on 4/5 I asked: > > > One thing I'm not clear on is the extent that a YANG module definition must itself use YANG - specifically for protocol modifications. For instance, the with-defaults I-D has YANG statements like: > > augment /nc:get-config/nc:input { > uses with-defaults-parameters; > } > > Are these *required* because YANG compilers MUST be 100% data-driven? - or could this I-D have alternatively left it developer to read the RFC cited by the module's "reference" statement? > > We wanted some hack to justify using XML attributes in a specific XML element, so we have this extension in the ietf-netconf.yang module: extension get-filter-element-attributes { description "If this extension is present within the an 'anyxml' statement named 'filter', which must be conceptually defined within the RPC input section for the 'get' and 'get-config' RPC operations, then the following unqualified XML attribute is supported within the 'filter' element, within a 'get' or 'get-config' protocol operation: type : optional attribute with allowed value strings 'subtree' and 'xpath'. If missing, the default value is 'subtree'. If the xpath feature is supported, then the following unqualified XML attribute is also supported: select: optional attribute containing a string representing an XPath expression. The 'type' attribute must be equal to 'xpath' if this attribute is present."; } > > Are you saying your "YANG validation program" will be 100% data-driven? > > yes -- for the NETCONF content layer, which happens to be the layer that YANG standardizes now. YANG does not support XML attributes. An XML validation program looks at all the XML. If the schema doesn't allow any XML attributes to be present, then why is it OK for a server to just add them to the reply? This violates the Postel Principle. NETCONF before YANG: no standard content layer. No standard content. Vendors do whatever they want, NETCONF after YANG; standard content layer. What does that mean? How are these XML attributes part of the standard content layer, but the NETCONF standard data modeling language has no support for XML attributes? Perhaps we should scrap YANG and use RelaxNG, if we want to use XML attributes in the standard NETCONF content layer. > Thanks, > Kent > > > Andy From j.schoenwaelder@jacobs-university.de Wed May 12 00:14: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 A49DE3A6C63 for ; Wed, 12 May 2010 00:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.157 X-Spam-Level: X-Spam-Status: No, score=0.157 tagged_above=-999 required=5 tests=[AWL=-0.194, 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 86R7giWVXlQQ for ; Wed, 12 May 2010 00:14:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1F1F73A6C9F for ; Wed, 12 May 2010 00:14:47 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43822C0009; Wed, 12 May 2010 09:14:36 +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 s33BSQfYRVNL; Wed, 12 May 2010 09:14:35 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA5D7C0004; Wed, 12 May 2010 09:14:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C1E5E12088C7; Wed, 12 May 2010 09:14:32 +0200 (CEST) Date: Wed, 12 May 2010 09:14:32 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20100512071432.GA9517@elstar.local> Mail-Followup-To: Phil Shafer , Andy Bierman , "netconf@ietf.org" References: <20100511195719.GB8428@elstar.local> <201005112025.o4BKP5ln060060@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005112025.o4BKP5ln060060@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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, 12 May 2010 07:14:51 -0000 On Tue, May 11, 2010 at 10:25:05PM +0200, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >For me, it makes a whole lot of a different to know whether a server > >is explicit or trim. > > This is the part I'm missing. How will you use the knowledge that > a particular server is trim or explicit in your code? The only > difference is that trim will not return leafs whose value is equal > to the default. If your client simply understand this is optional > behavior, what further differences will it make for the client code? The client will know that setting this leaf to a value (which might be the default value) and not getting it back is not a bug of the server but considered a feature by whoever implemented the server. In the simples case, my client could generate a warning "this netconf server is trimming defaults, be careful". Believe me or not, this kind of information is operationally useful. Have you seen an operator knocking his head against the wall for hours because when he sets a specific value the value disappears in the config? Don't answer me he should have read the YANG / NETCONF RFCs and he should understand the details of the data model. /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 May 12 04:16:13 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D27E3A6A96 for ; Wed, 12 May 2010 04:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.109 X-Spam-Level: * X-Spam-Status: No, score=1.109 tagged_above=-999 required=5 tests=[AWL=-0.241, 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 EsAeZIXWPhRC for ; Wed, 12 May 2010 04:16:12 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 1FC9E3A6A9D for ; Wed, 12 May 2010 04:15:44 -0700 (PDT) Received: from [195.113.238.21] (ws-eduroam-21.cesnet.cz [195.113.238.21]) by office2.cesnet.cz (Postfix) with ESMTPSA id CDD312CDE057; Wed, 12 May 2010 13:15:32 +0200 (CEST) From: Ladislav Lhotka To: andyb@iwl.com In-Reply-To: <4BE9CFF7.1080400@iwl.com> References: <201005112025.o4BKP5ln060060@idle.juniper.net> <1273611145.10083.38.camel@missotis> <4BE9CFF7.1080400@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 12 May 2010 13:15:30 +0200 Message-ID: <1273662930.1857.13.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netconf@ietf.org Subject: Re: [Netconf] WG Chair question: where are we 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, 12 May 2010 11:16:13 -0000 Andy Bierman píše v Út 11. 05. 2010 v 14:45 -0700: > > > > Configuration scripts that work for a "trim" server may fail for an > > "explicit" server and vice versa. > > > > > > Can you expand on this generalization? > It doesn't matter for merge/replace. > For create/delete, the client really needs to do a get-config > first. I don't see how the client knows if the leaf This may not help. Consider a leaf X with a default defined in the data model. If the client get a configuration where X is not present, then 1. creating leaf X with the default value and then deleting it will succeed for an "explicit" server but fail for a "trim" server; 2. creating leaf X with the default value and then creating it again with any value succeeds for a "trim" server and fails for an "explicit" server. > contains the default or normal value already, so it knows > whether create/delete should work or not. Yes, but who wants to retrieve the configuration after every operation? > > How realistic is it for a client to do creates or deletes > without first doing a get-config? > > BTW, one of the use-cases for report-all is to retrieve > an XML document that can be used for off-line validation. The DSRL schema created by the DSDL mapping from YANG module(s) is able to generate the "report-all" version from any valid configuration. > How does the possible inclusion of XML attributes in > this XML document affect off-line validation? > Seems like this would cause a problem. Why? I think it should be doable, e.g., if the attributes reside in a dedicated namespace. Lada > > > > Lada > > > > Andy > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Wed May 12 05:32:00 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 407A73A6C66 for ; Wed, 12 May 2010 05:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.518 X-Spam-Level: X-Spam-Status: No, score=-5.518 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_05=-1.11, 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 4-Znvuzi-DIw for ; Wed, 12 May 2010 05:31:59 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 7C0A63A692C for ; Wed, 12 May 2010 05:29:10 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKS+qfCsD50oByNNKvQZuGBzhO4ESKMLqU@postini.com; Wed, 12 May 2010 05:29:02 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Wed, 12 May 2010 05:25:23 -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, 12 May 2010 05:25:23 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 05:25:23 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 May 2010 05:25:23 -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 o4CCPHD53916; Wed, 12 May 2010 05:25:20 -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 o4CC83OX064587; Wed, 12 May 2010 12:08:03 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005121208.o4CC83OX064587@idle.juniper.net> To: In-Reply-To: <4BE9D2EF.6050901@iwl.com> Date: Wed, 12 May 2010 08:08:03 -0400 From: Phil Shafer X-OriginalArrivalTime: 12 May 2010 12:25:23.0128 (UTC) FILETIME=[319B0380:01CAF1CE] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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, 12 May 2010 12:32:00 -0000 Andy Bierman writes: >It seems rather strange that the company that >insists 'report-all' is pointless and does not want to >implement it, also insists that the report-all reply >needs XML attributes added to it. IIRC one of the cornerstone of the IETF is that we appear as individuals, not representatives of our current employers. Clearly Kent and I disagree on the neccessity of w-d, and I think that's completely healthy. My main interest is that the w-d draft be suitably written so that if I am pushed to implement it, no harm will come to my users. Kent's proposal is meant to reduce the possibility of harm, which is why I see it as a Good Thing. Again, I think this is completely healthy. In contrast, your claims that this issue has been rejected multiple times seem like fabrication, which is clearly not healthy. Thanks, Phil From phil@juniper.net Wed May 12 05:34: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 5DC5128C141 for ; Wed, 12 May 2010 05:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.252 X-Spam-Level: X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[AWL=0.347, 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 w89elayiFVds for ; Wed, 12 May 2010 05:34:41 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id CF96A3A68FA for ; Wed, 12 May 2010 05:32:52 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKS+qf6sHFWpY9EuFOfYsfe40ugZh7j9mc@postini.com; Wed, 12 May 2010 05:32:44 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Wed, 12 May 2010 05:28:40 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 May 2010 05:28:40 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 05:28:40 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 May 2010 05:28:39 -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 o4CCScD55078; Wed, 12 May 2010 05:28:39 -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 o4CCBP44064629; Wed, 12 May 2010 12:11:25 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005121211.o4CCBP44064629@idle.juniper.net> To: In-Reply-To: <4BE9E889.6010508@iwl.com> Date: Wed, 12 May 2010 08:11:25 -0400 From: Phil Shafer X-OriginalArrivalTime: 12 May 2010 12:28:39.0782 (UTC) FILETIME=[A6D20860:01CAF1CE] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 12:34:42 -0000 Andy Bierman writes: >What is the point of having also-supported modes >in the standard, but no way to make sure there is >a standard way to access these other modes? You've already said that report-all is for "debug mode", which would limit its usefulness as a "standard way". If my server doesn't need "debug mode", why is report-all a MUST? Thanks, Phil From andyb@iwl.com Wed May 12 05:40: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 E8A1C3A62C1 for ; Wed, 12 May 2010 05:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[AWL=-0.587, 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 JMGDF+Vyjzzc for ; Wed, 12 May 2010 05:40:09 -0700 (PDT) Received: from smtp234.iad.emailsrvr.com (smtp234.iad.emailsrvr.com [207.97.245.234]) by core3.amsl.com (Postfix) with ESMTP id 9E1DE3A67A6 for ; Wed, 12 May 2010 05:38:42 -0700 (PDT) Received: from relay13.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay13.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 349F21D50D1; Wed, 12 May 2010 08:38:32 -0400 (EDT) Received: by relay13.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id AE7241CF3BB; Wed, 12 May 2010 08:38:31 -0400 (EDT) Message-ID: <4BEAA16C.6090103@iwl.com> Date: Wed, 12 May 2010 05:39:08 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201005121208.o4CC83OX064587@idle.juniper.net> In-Reply-To: <201005121208.o4CC83OX064587@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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, 12 May 2010 12:40:10 -0000 Phil Shafer wrote: > Andy Bierman writes: > >> It seems rather strange that the company that >> insists 'report-all' is pointless and does not want to >> implement it, also insists that the report-all reply >> needs XML attributes added to it. >> > > IIRC one of the cornerstone of the IETF is that we appear as > individuals, not representatives of our current employers. Clearly > Kent and I disagree on the neccessity of w-d, and I think that's > completely healthy. > > My main interest is that the w-d draft be suitably written so that > if I am pushed to implement it, no harm will come to my users. > Kent's proposal is meant to reduce the possibility of harm, which > is why I see it as a Good Thing. Again, I think this is completely > healthy. > As individuals, you cancel each other out. You cannot argue one minute that with-defaults is harmful, and also argue it has to done 'your way' or the highway. IMO, there is no need to encode the YANG file on-the-wire. We didn't need that in SNMP and we don't need it in NETCONF. YANG does not support XML attributes, and simply ignoring all XML attributes does not seem like a standardized content layer to me. > In contrast, your claims that this issue has been rejected multiple > times seem like fabrication, which is clearly not healthy. > > I recall the conclusion from the IETF meeting: No consensus to add the XML attribute. There was no consensus established on the mailing list either. If you have proof of this, point it out. > Thanks, > Phil > > Andy From phil@juniper.net Wed May 12 05:42:21 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 23A863A6B84 for ; Wed, 12 May 2010 05:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.054 X-Spam-Level: X-Spam-Status: No, score=-5.054 tagged_above=-999 required=5 tests=[AWL=-0.869, BAYES_40=-0.185, 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 JN3DR-WWCovJ for ; Wed, 12 May 2010 05:42:20 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 1212428C133 for ; Wed, 12 May 2010 05:40:36 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKS+qhuT9O6DXiz8U7QdyiMKxSaFIVV7fb@postini.com; Wed, 12 May 2010 05:40:27 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Wed, 12 May 2010 05:40:04 -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); Wed, 12 May 2010 05:40:04 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 05:40:03 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 May 2010 05:40:03 -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 o4CCe2D59666; Wed, 12 May 2010 05:40:02 -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 o4CCMnOt064750; Wed, 12 May 2010 12:22:49 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005121222.o4CCMnOt064750@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20100512071432.GA9517@elstar.local> Date: Wed, 12 May 2010 08:22:49 -0400 From: Phil Shafer X-OriginalArrivalTime: 12 May 2010 12:40:03.0523 (UTC) FILETIME=[3E5CA130:01CAF1D0] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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, 12 May 2010 12:42:21 -0000 Juergen Schoenwaelder writes: >The client will know that setting this leaf to a value (which might be >the default value) and not getting it back is not a bug of the server >but considered a feature by whoever implemented the server. In the >simples case, my client could generate a warning "this netconf server >is trimming defaults, be careful". Believe me or not, this kind of >information is operationally useful. This assumes that your client will set the leaf and then check the leaf, which is not the behavior I'm used to seeing in clients. Most clients are "fire and forget", so if the operation succeeds, they move on and assume the right thing has happened. I could see some utility in comparisons on a higher level, when I asked to load a zillion import policies and what to fetch them all and make sure the work was really done, but teaching teaching the policy generator about defaults would be easier than teaching the compare function to handle trimmed default values. >Have you seen an operator knocking his head against the wall for hours >because when he sets a specific value the value disappears in the >config? Don't answer me he should have read the YANG / NETCONF RFCs >and he should understand the details of the data model. Trust me; I had the same mental anguish when I first used IOS (which is why I did my CLI differently ;^) Thanks, Phil From andyb@iwl.com Wed May 12 05:47: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 B05D33A6B4E for ; Wed, 12 May 2010 05:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[AWL=0.593, 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 p0rPWfltHHz8 for ; Wed, 12 May 2010 05:47:39 -0700 (PDT) Received: from smtp184.dfw.emailsrvr.com (smtp184.dfw.emailsrvr.com [67.192.241.184]) by core3.amsl.com (Postfix) with ESMTP id E55FE3A6B8E for ; Wed, 12 May 2010 05:47:07 -0700 (PDT) Received: from relay18.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay18.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 9274B16F017A; Wed, 12 May 2010 08:46:57 -0400 (EDT) Received: by relay18.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 50D7116F0183; Wed, 12 May 2010 08:46:57 -0400 (EDT) Message-ID: <4BEAA366.8090709@iwl.com> Date: Wed, 12 May 2010 05:47:34 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201005121211.o4CCBP44064629@idle.juniper.net> In-Reply-To: <201005121211.o4CCBP44064629@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 12 May 2010 12:47:39 -0000 Phil Shafer wrote: > Andy Bierman writes: > >> What is the point of having also-supported modes >> in the standard, but no way to make sure there is >> a standard way to access these other modes? >> > > You've already said that report-all is for "debug mode", which would > limit its usefulness as a "standard way". If my server doesn't > need "debug mode", why is report-all a MUST? > > The standard provides 2 mandatory buts of functionality 1) advertise the modes supported 2) ability to retrieve all the nodes We already established that every server CAN return report-all. You just don't want to do that, even though that is a client decision, not a server decision. The WG already agreed that report-all MUST be part of this capability. Since there is no implementation burden, I do not see any reason to change that. > Thanks, > Phil > > Andy From phil@juniper.net Wed May 12 05:47: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 AF4633A68FA for ; Wed, 12 May 2010 05:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.360, 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 0s8KLJ+1xiKz for ; Wed, 12 May 2010 05:47:54 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id D7EF83A6B4C for ; Wed, 12 May 2010 05:47:22 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKS+qjUIvc9+M4PRPlIH1c3wbMtxcIdotr@postini.com; Wed, 12 May 2010 05:47:13 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Wed, 12 May 2010 05:45:03 -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); Wed, 12 May 2010 05:45:03 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 05:45:03 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 May 2010 05:45:02 -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 o4CCj1D61870; Wed, 12 May 2010 05:45:01 -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 o4CCRlP5064849; Wed, 12 May 2010 12:27:47 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005121227.o4CCRlP5064849@idle.juniper.net> To: Randy Presuhn In-Reply-To: <002901caf159$94b73b20$6801a8c0@oemcomputer> Date: Wed, 12 May 2010 08:27:47 -0400 From: Phil Shafer X-OriginalArrivalTime: 12 May 2010 12:45:02.0738 (UTC) FILETIME=[F0B53720:01CAF1D0] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] WG Chair question: where are we 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, 12 May 2010 12:47:54 -0000 "Randy Presuhn" writes: >I am amazed by your faith, and hope you are correct. Considering that these (or similar) tools and approaches have been used for ~10 years in Juniper products, I don't see this as faith. I see it as knowledge sharing. I know this stuff works. I've used it for years. It's quite nice. Honest. Thanks, Phil From phil@juniper.net Wed May 12 05:57: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 039DF3A6B7F for ; Wed, 12 May 2010 05:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=0.351, 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 Ex2-vE1VBd+u for ; Wed, 12 May 2010 05:57:10 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 79F293A6B69 for ; Wed, 12 May 2010 05:56:49 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKS+qlhhV2NaTvRZTwDCKODlIP+JRpbfhx@postini.com; Wed, 12 May 2010 05:56:40 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Wed, 12 May 2010 05:54:35 -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); Wed, 12 May 2010 05:54:35 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 05:54:35 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 May 2010 05:54:33 -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 o4CCsXD65361; Wed, 12 May 2010 05:54:33 -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 o4CCbJ68064944; Wed, 12 May 2010 12:37:19 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005121237.o4CCbJ68064944@idle.juniper.net> To: In-Reply-To: <4BEAA16C.6090103@iwl.com> Date: Wed, 12 May 2010 08:37:19 -0400 From: Phil Shafer X-OriginalArrivalTime: 12 May 2010 12:54:33.0856 (UTC) FILETIME=[451EE800:01CAF1D2] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Chair question: where are we 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, 12 May 2010 12:57:11 -0000 Andy Bierman writes: >As individuals, you cancel each other out. I don't see it that way. I see us as individuals contributing to help the WG develop a better way. >You cannot argue one minute that with-defaults >is harmful, and also argue it has to done 'your way' or the highway. If I saw the world in this silly way, I don' think I'd have stuck around this long ;^) >IMO, there is no need to encode the YANG file on-the-wire. >We didn't need that in SNMP and we don't need it in NETCONF. I didn't think "YANG file on-the-wire" was the current discussion, but I think the monitoring draft does allow this. If you are seeing the defaults discussion as "YANG file on-the-wire", my view has always been that intermixing defaults with "real" data is unneccessary, since these defaults can be found in the YANG modules. I guess I'm not following your argument here. Thanks, Phil From phil@juniper.net Wed May 12 05:58:13 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C200D3A67A6 for ; Wed, 12 May 2010 05:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.256 X-Spam-Level: X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=0.343, 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 rmTnmghdwRc2 for ; Wed, 12 May 2010 05:58:13 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id C68913A6901 for ; Wed, 12 May 2010 05:58:05 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKS+ql0odDES3mVKRoM4ODpj00dcN4fZZq@postini.com; Wed, 12 May 2010 05:57:56 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Wed, 12 May 2010 05:56:09 -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, 12 May 2010 05:56:09 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 05:56:08 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 May 2010 05:56:08 -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 o4CCu7D65959; Wed, 12 May 2010 05:56:07 -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 o4CCcqlY064960; Wed, 12 May 2010 12:38:52 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005121238.o4CCcqlY064960@idle.juniper.net> To: In-Reply-To: <4BE9CE44.30506@iwl.com> Date: Wed, 12 May 2010 08:38:52 -0400 From: Phil Shafer X-OriginalArrivalTime: 12 May 2010 12:56:08.0011 (UTC) FILETIME=[7D3DD1B0:01CAF1D2] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] WG Chair question: where are we 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, 12 May 2010 12:58:13 -0000 Andy Bierman writes: >I do not recall any emails or WG meeting minutes that >declared that the with-defaults charter has been expanded >to include XML attributes in the rpc-reply. >Can you point out that email? Do documents _have_ charters? I had no idea..... Thanks, Phil From phil@juniper.net Wed May 12 06:09: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 B6A3A28C14A for ; Wed, 12 May 2010 06:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.264 X-Spam-Level: X-Spam-Status: No, score=-6.264 tagged_above=-999 required=5 tests=[AWL=0.335, 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 9Y482+l8i9yv for ; Wed, 12 May 2010 06:09:02 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 7314628C14E for ; Wed, 12 May 2010 06:05:54 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKS+qnpyrsCRQJZcEsDk+rVmWPr5QkFsO4@postini.com; Wed, 12 May 2010 06:05:45 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Wed, 12 May 2010 06:03:08 -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, 12 May 2010 06:03:08 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 06:03:08 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 May 2010 06:03:07 -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 o4CD36D70397; Wed, 12 May 2010 06:03:06 -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 o4CCjqKn065087; Wed, 12 May 2010 12:45:52 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005121245.o4CCjqKn065087@idle.juniper.net> To: In-Reply-To: <4BEAA366.8090709@iwl.com> Date: Wed, 12 May 2010 08:45:52 -0400 From: Phil Shafer X-OriginalArrivalTime: 12 May 2010 13:03:07.0771 (UTC) FILETIME=[77701CB0:01CAF1D3] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 13:09:03 -0000 Andy Bierman writes: >We already established that every server CAN >return report-all. You just don't want to do that, >even though that is a client decision, not a server decision. My concern remains that intermixing default values with "real" configuration data is a problem waiting to happen. Kent's proposal attempts to let the client (and the server to which the client feeds a default-laden config) understand which are phantom defaults and which are "real" config, allowing both sides to deal with these defaults in an appropriate manner. The w-d attribute gives a means of keeping the pin in the grenade. Should I turn this around and ask where in Kent's proposal? What problems are created by flagging defaults as defaults? Is there any harm in giving this information to clients and servers? Thanks, Phil From andyb@iwl.com Wed May 12 06:38: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 BB68628C242 for ; Wed, 12 May 2010 06:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.752 X-Spam-Level: X-Spam-Status: No, score=-0.752 tagged_above=-999 required=5 tests=[AWL=-0.346, 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 b2vk-ln4nORE for ; Wed, 12 May 2010 06:38:54 -0700 (PDT) Received: from smtp124.dfw.emailsrvr.com (smtp124.dfw.emailsrvr.com [67.192.241.124]) by core3.amsl.com (Postfix) with ESMTP id 591873A6CA6 for ; Wed, 12 May 2010 06:29:42 -0700 (PDT) Received: from relay2.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay2.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id D2DC7E211EF; Wed, 12 May 2010 09:29:31 -0400 (EDT) Received: by relay2.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 86E9DE210A8; Wed, 12 May 2010 09:29:31 -0400 (EDT) Message-ID: <4BEAAD60.1000800@iwl.com> Date: Wed, 12 May 2010 06:30:08 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201005121245.o4CCjqKn065087@idle.juniper.net> In-Reply-To: <201005121245.o4CCjqKn065087@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 12 May 2010 13:38:54 -0000 Phil Shafer wrote: > Andy Bierman writes: > >> We already established that every server CAN >> return report-all. You just don't want to do that, >> even though that is a client decision, not a server decision. >> > > My concern remains that intermixing default values with "real" > configuration data is a problem waiting to happen. Kent's proposal > attempts to let the client (and the server to which the client feeds > a default-laden config) understand which are phantom defaults and > which are "real" config, allowing both sides to deal with these > defaults in an appropriate manner. The w-d attribute gives a means > of keeping the pin in the grenade. > > Should I turn this around and ask where in Kent's proposal? What > problems are created by flagging defaults as defaults? Is there > any harm in giving this information to clients and servers? > > A client cannot use the retrieved get-config as input to an edit-config or copy-config without altering the get-config reply. IMO, tagging would be acceptable if (and only if) the client asks for tagged output. The client MUST be the one that decides to receive XML attributes, not the server. > Thanks, > Phil > > Andy From phil@juniper.net Wed May 12 06:46: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 2A54B3A6845 for ; Wed, 12 May 2010 06:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.272 X-Spam-Level: X-Spam-Status: No, score=-6.272 tagged_above=-999 required=5 tests=[AWL=0.327, 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 X8vXsnPHzgWF for ; Wed, 12 May 2010 06:46:49 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 2B0493A6BA1 for ; Wed, 12 May 2010 06:35:26 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKS+quk1r5hChFBpS0HpdrhKUUFDIcTsul@postini.com; Wed, 12 May 2010 06:35:17 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.436.0; Wed, 12 May 2010 06:33:07 -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, 12 May 2010 06:33:07 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 06:33:07 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 May 2010 06:33:06 -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 o4CDX5D82696; Wed, 12 May 2010 06:33:06 -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 o4CDFqWi065458; Wed, 12 May 2010 13:15:52 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005121315.o4CDFqWi065458@idle.juniper.net> To: In-Reply-To: <4BEAAD60.1000800@iwl.com> Date: Wed, 12 May 2010 09:15:52 -0400 From: Phil Shafer X-OriginalArrivalTime: 12 May 2010 13:33:06.0748 (UTC) FILETIME=[A7B637C0:01CAF1D7] MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 13:46:50 -0000 Andy Bierman writes: >A client cannot use the retrieved get-config as >input to an edit-config or copy-config without >altering the get-config reply. You made this claim before and Martin's response was that part of defining this attribute would be requiring that servers parse is and discard/ignore leafs so tagged. I think this is a great addition. >IMO, tagging would be acceptable if (and only if) >the client asks for tagged output. The client MUST >be the one that decides to receive XML attributes, >not the server. So you are agreeable to adding another w-d parameter that turns on this attribute-tagged-of-defaults behavior? Thanks, Phil From andyb@iwl.com Wed May 12 06:48: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 95D1128C229 for ; Wed, 12 May 2010 06:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=0.589, 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 2OsZXKSb98gM for ; Wed, 12 May 2010 06:48:17 -0700 (PDT) Received: from smtp124.dfw.emailsrvr.com (smtp124.dfw.emailsrvr.com [67.192.241.124]) by core3.amsl.com (Postfix) with ESMTP id 309E828C22E for ; Wed, 12 May 2010 06:37:39 -0700 (PDT) Received: from relay2.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay2.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id B98BDE21669; Wed, 12 May 2010 09:37:28 -0400 (EDT) Received: by relay2.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 75FC5E2125D; Wed, 12 May 2010 09:37:28 -0400 (EDT) Message-ID: <4BEAAF3D.7070703@iwl.com> Date: Wed, 12 May 2010 06:38:05 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201005121315.o4CDFqWi065458@idle.juniper.net> In-Reply-To: <201005121315.o4CDFqWi065458@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 12 May 2010 13:48:18 -0000 Phil Shafer wrote: > Andy Bierman writes: > >> A client cannot use the retrieved get-config as >> input to an edit-config or copy-config without >> altering the get-config reply. >> > > You made this claim before and Martin's response was that part of > defining this attribute would be requiring that servers parse is > and discard/ignore leafs so tagged. I think this is a great addition. > > >> IMO, tagging would be acceptable if (and only if) >> the client asks for tagged output. The client MUST >> be the one that decides to receive XML attributes, >> not the server. >> > > So you are agreeable to adding another w-d parameter that > turns on this attribute-tagged-of-defaults behavior? > > repetition is the key to learning.... I do not want the server to decide what to send. I want the client to always decide. I also want the server to be able to not implement this XML attribute. basic-mode = [trim | explicit | report-all] also-supported = 0 or more of [trim | explicit | report-all | report-all-tagged] [full-list-of-enums] This fixes the problem. If the server wants to support this XML attribute, it will list it in its also-supported parameter. If the client wants report-all-tagged, it will ask for it. > Thanks, > Phil > > Andy From andyb@iwl.com Wed May 12 07:01: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 961C23A6B79 for ; Wed, 12 May 2010 07:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.04 X-Spam-Level: X-Spam-Status: No, score=-1.04 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SG3gBo0L-yC2 for ; Wed, 12 May 2010 07:01:45 -0700 (PDT) Received: from smtp124.dfw.emailsrvr.com (smtp124.dfw.emailsrvr.com [67.192.241.124]) by core3.amsl.com (Postfix) with ESMTP id 19A5F28C2A4 for ; Wed, 12 May 2010 06:52:08 -0700 (PDT) Received: from relay2.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay2.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 6FBE1E224D0; Wed, 12 May 2010 09:51:54 -0400 (EDT) Received: by relay2.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 6CF5AE2028C; Wed, 12 May 2010 09:51:51 -0400 (EDT) Message-ID: <4BEAB29B.6010800@iwl.com> Date: Wed, 12 May 2010 06:52:27 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 References: <201005121315.o4CDFqWi065458@idle.juniper.net> <4BEAAF3D.7070703@iwl.com> In-Reply-To: <4BEAAF3D.7070703@iwl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 12 May 2010 14:01:45 -0000 Andy Bierman wrote: > Phil Shafer wrote: > >> ... >> So you are agreeable to adding another w-d parameter that >> turns on this attribute-tagged-of-defaults behavior? >> >> >> > > repetition is the key to learning.... > > I do not want the server to decide what to send. > I want the client to always decide. I also want > the server to be able to not implement this XML attribute. > > basic-mode = [trim | explicit | report-all] > > also-supported = 0 or more of > Note the phrase '0 or more'. This is not a typo. In my proposal, some form of report-all would be SHOULD, not MUST. > [trim | explicit | report-all | report-all-tagged] > > [full-list-of-enums] > > > This fixes the problem. > If the server wants to support this XML attribute, > it will list it in its also-supported parameter. > If the client wants report-all-tagged, it will ask for it. > > > > >> Thanks, >> Phil >> >> >> > Andy > > Andy From andyb@iwl.com Wed May 12 07:39: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 EDC3E28C3B2 for ; Wed, 12 May 2010 07:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.664 X-Spam-Level: X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[AWL=-0.665, 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 Py0H6RXmExeZ for ; Wed, 12 May 2010 07:39:02 -0700 (PDT) Received: from smtp184.iad.emailsrvr.com (smtp184.iad.emailsrvr.com [207.97.245.184]) by core3.amsl.com (Postfix) with ESMTP id 4F06B28C3E3 for ; Wed, 12 May 2010 07:20:57 -0700 (PDT) Received: from relay28.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay28.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 3A21A1B4766; Wed, 12 May 2010 10:20:47 -0400 (EDT) Received: by relay28.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id E86271B4765; Wed, 12 May 2010 10:20:46 -0400 (EDT) Message-ID: <4BEAB963.2040103@iwl.com> Date: Wed, 12 May 2010 07:21:23 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: [Netconf] with-defaults consensus time 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, 12 May 2010 14:39:03 -0000 Hi Kent, I think we are reaching a compromise. IMO, here are the 2 use-cases that actually matter. Everything else is implementation-biased, and should be ignored for consensus purposes. Argument for report-all-tagged: Even though the tagging will produce the exact same results as obtained by comparing the report-all and basic-mode replies, this requires a lock on the database to be done safely. Lock-time can be a precious resource, so this solution is not always acceptable. A solution is needed that allows the same information retrieval without locking. Argument for report-all-untagged: Even though the XML attributes can be stripped out of reply by writing more code, the extra bytes on the wire that these attributes consume cannot be avoided. The extra overhead in every default node will significant -- depending on the data -- but could easily reach 40% - 50% of the reply packet. If the client knows it does not want these XML attributes, and network bandwidth is a precious resource, then the unwanted overhead is unacceptable. A solution is needed that allows the client to minimize the reply size. Andy From j.schoenwaelder@jacobs-university.de Wed May 12 07:48:01 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8DA63A699C for ; Wed, 12 May 2010 07:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.21 X-Spam-Level: X-Spam-Status: No, score=-0.21 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_20=-0.74, 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 lGP0HK+eNPgI for ; Wed, 12 May 2010 07:48:01 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C7AE228C366 for ; Wed, 12 May 2010 07:32:41 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E41FC000F; Wed, 12 May 2010 16:32:31 +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 Ui73ryFq09jA; Wed, 12 May 2010 16:32:30 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D333C0006; Wed, 12 May 2010 16:32:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3042F1209AAE; Wed, 12 May 2010 16:32:30 +0200 (CEST) Date: Wed, 12 May 2010 16:32:30 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100512143230.GB10790@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , "netconf@ietf.org" References: <201005121315.o4CDFqWi065458@idle.juniper.net> <4BEAAF3D.7070703@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BEAAF3D.7070703@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 12 May 2010 14:48:01 -0000 On Wed, May 12, 2010 at 03:38:05PM +0200, Andy Bierman wrote: > I do not want the server to decide what to send. > I want the client to always decide. I also want > the server to be able to not implement this XML attribute. > > basic-mode = [trim | explicit | report-all] > > also-supported = 0 or more of > [trim | explicit | report-all | report-all-tagged] > > [full-list-of-enums] > > This fixes the problem. > If the server wants to support this XML attribute, > it will list it in its also-supported parameter. > If the client wants report-all-tagged, it will ask for it. If we do tagging, we should have a plan how in general we want to deal with operational state. For explicit server, leafs with defaults are simply operational state, not config. I guess I lacking the meta model here to say it in Randy's terms. /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 May 12 08:09: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 CECEE3A6BB2 for ; Wed, 12 May 2010 08:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[AWL=0.580, 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 b0f10DKS2PIZ for ; Wed, 12 May 2010 08:09:19 -0700 (PDT) Received: from smtp124.dfw.emailsrvr.com (smtp124.dfw.emailsrvr.com [67.192.241.124]) by core3.amsl.com (Postfix) with ESMTP id AEBCC28C33A for ; Wed, 12 May 2010 07:57:32 -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 22A572080224; Wed, 12 May 2010 10:57:22 -0400 (EDT) Received: by relay12.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id BC8D5208020C; Wed, 12 May 2010 10:57:21 -0400 (EDT) Message-ID: <4BEAC1F6.2040608@iwl.com> Date: Wed, 12 May 2010 07:57:58 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Andy Bierman , Phil Shafer , "netconf@ietf.org" References: <201005121315.o4CDFqWi065458@idle.juniper.net> <4BEAAF3D.7070703@iwl.com> <20100512143230.GB10790@elstar.local> In-Reply-To: <20100512143230.GB10790@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 12 May 2010 15:09:20 -0000 Juergen Schoenwaelder wrote: > On Wed, May 12, 2010 at 03:38:05PM +0200, Andy Bierman wrote: > > >> I do not want the server to decide what to send. >> I want the client to always decide. I also want >> the server to be able to not implement this XML attribute. >> >> basic-mode = [trim | explicit | report-all] >> >> also-supported = 0 or more of >> [trim | explicit | report-all | report-all-tagged] >> >> [full-list-of-enums] >> >> This fixes the problem. >> If the server wants to support this XML attribute, >> it will list it in its also-supported parameter. >> If the client wants report-all-tagged, it will ask for it. >> > > If we do tagging, we should have a plan how in general we want to deal > with operational state. For explicit server, leafs with defaults are > simply operational state, not config. > > I guess I lacking the meta model here to say it in Randy's terms. > > The tagging proposal is not detailed enough, so we may be debating different versions of the proposal. Does wd:default='true' mean: 1) "This is a default node by my definition of a default" OR 2) "The value is equal to the schema-default for the node" Martin pointed out that not all servers know (2), they only can be forced to know (1). If (1), then get-config(report-all) - get-config(basic-mode) describes the set of nodes that will be tagged. If (2), not sure what problem this solves. If (1), the report-all mode can be thought of as the 'include all your operational data' mode, since that is what the non-basic-mode nodes represent in every case. > /js > > Andy From j.schoenwaelder@jacobs-university.de Wed May 12 08:39: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 C5EFA3A6999 for ; Wed, 12 May 2010 08:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.159 X-Spam-Level: X-Spam-Status: No, score=0.159 tagged_above=-999 required=5 tests=[AWL=-0.192, 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 igKzCvR0dYnn for ; Wed, 12 May 2010 08:39:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 548ED3A6CC2 for ; Wed, 12 May 2010 08:28:07 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 03685C000C; Wed, 12 May 2010 17:27:57 +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 0tU2BUyYoqGP; Wed, 12 May 2010 17:27: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 E0566C0006; Wed, 12 May 2010 17:27:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CDCEB1209D71; Wed, 12 May 2010 17:27:55 +0200 (CEST) Date: Wed, 12 May 2010 17:27:55 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100512152755.GB10978@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , "netconf@ietf.org" References: <201005121315.o4CDFqWi065458@idle.juniper.net> <4BEAAF3D.7070703@iwl.com> <20100512143230.GB10790@elstar.local> <4BEAC1F6.2040608@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BEAC1F6.2040608@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 12 May 2010 15:39:03 -0000 On Wed, May 12, 2010 at 04:57:58PM +0200, Andy Bierman wrote: > If (1), the report-all mode can be thought of as the > 'include all your operational data' mode, since that > is what the non-basic-mode nodes represent in every case. A route inserted into my router via BGP is not default data but still operational state. So I see it the other way round: If we would have a mechanism to retrieve data tagged config / operational state / ..., a solution for defaults likely falls out naturally. (This might be done by introducing a new operation instead of adding more parameters to existing operations - but that is just one option and there can be debates about what the best approach is.) There are lots of examples where operational state if coming both from explicit config and control protocols and I have yet to see how we like to model this with YANG and the semantics of the NETCONF operations we have. It would be nice if we do not have to duplicate definitions in order to separate the operational state view from the config view - this is I think what is currently required (and this approach makes comparison of operational state and config state a non automated process the relationship is not machine readable). /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 May 12 09:08: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 F0F8B3A69D3 for ; Wed, 12 May 2010 09:08:29 -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.729, 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 e2g0KezsUNFX for ; Wed, 12 May 2010 09:08:29 -0700 (PDT) Received: from smtp154.dfw.emailsrvr.com (smtp154.dfw.emailsrvr.com [67.192.241.154]) by core3.amsl.com (Postfix) with ESMTP id E45193A6CAE for ; Wed, 12 May 2010 08:53:49 -0700 (PDT) Received: from relay25.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay25.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 1E9E53601D6; Wed, 12 May 2010 11:53:39 -0400 (EDT) Received: by relay25.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 38313360C9A; Wed, 12 May 2010 11:51:56 -0400 (EDT) Message-ID: <4BEACEC1.5070701@iwl.com> Date: Wed, 12 May 2010 08:52:33 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Andy Bierman , Phil Shafer , "netconf@ietf.org" References: <201005121315.o4CDFqWi065458@idle.juniper.net> <4BEAAF3D.7070703@iwl.com> <20100512143230.GB10790@elstar.local> <4BEAC1F6.2040608@iwl.com> <20100512152755.GB10978@elstar.local> In-Reply-To: <20100512152755.GB10978@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Reeminder: Action required before May 5th 2010: WG LAST CALL for draft-ietf-netconf-with-defaults-07.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, 12 May 2010 16:08:30 -0000 Juergen Schoenwaelder wrote: > On Wed, May 12, 2010 at 04:57:58PM +0200, Andy Bierman wrote: > > >> If (1), the report-all mode can be thought of as the >> 'include all your operational data' mode, since that >> is what the non-basic-mode nodes represent in every case. >> > > A route inserted into my router via BGP is not default data but still > operational state. So I see it the other way round: If we would have a > mechanism to retrieve data tagged config / operational state / ..., a > solution for defaults likely falls out naturally. (This might be done > by introducing a new operation instead of adding more > parameters to existing operations - but that is just one option and > there can be debates about what the best approach is.) > > There are lots of examples where operational state if coming both from > explicit config and control protocols and I have yet to see how we > like to model this with YANG and the semantics of the NETCONF > operations we have. It would be nice if we do not have to duplicate > definitions in order to separate the operational state view from the > config view - this is I think what is currently required (and this > approach makes comparison of operational state and config state a non > automated process the relationship is not machine readable). > > So we agree the tag means (1) not (2). Good. A new operation to retrieve just the operational data is one option. This would be fine with me. This would be client-initiated, which is important. I still like the current report-all because it supports some use-cases the WG has agreed are important, such as off-line schema validation, and simplified diff-tracking. I agree that much more work is needed for NETCONF/YANG to properly model real-world micro-details of configuration behavior, such as server containers vs. client-created containers, or disabled config subtrees, or pre-provisioned config sub-trees. I never really agreed in the first place that config-stmt was a boolean. I argued for a 3rd state to represent operational-config (I called it transient config or 'tconfig'). Gee, guess what the wd:default=true is? -- that 3rd state. But it is just in NETCONF, not YANG. YANG must/when/unique constraints are still fuzzy because config-stmt is a boolean. > /js > > Andy From kwatsen@juniper.net Wed May 12 14:05:00 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4F923A6933 for ; Wed, 12 May 2010 14:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.005 X-Spam-Level: X-Spam-Status: No, score=-6.005 tagged_above=-999 required=5 tests=[AWL=0.594, 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 g6gtNP8R11er for ; Wed, 12 May 2010 14:04:59 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 455883A690C for ; Wed, 12 May 2010 14:04:57 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKS+sX7rodwrmg3CbumPZN3nDraqXk+WzZ@postini.com; Wed, 12 May 2010 14:04:47 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 12 May 2010 14:02:36 -0700 From: Kent Watsen To: "'andyb@iwl.com'" Date: Wed, 12 May 2010 14:02:35 -0700 Thread-Topic: with-defaults consensus time Thread-Index: Acrx3luWx9LyCp3eQKOXg6beWFIt3wALP9Vg Message-ID: <84600D05C20FF943918238042D7670FD36C7D763AE@EMBX01-HQ.jnpr.net> References: <4BEAB963.2040103@iwl.com> In-Reply-To: <4BEAB963.2040103@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: NETCONF Subject: Re: [Netconf] with-defaults consensus time X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 12 May 2010 21:05:00 -0000 =20 Hi Andy, > I think we are reaching a compromise. No problem - supporting untagged defaults is fine so long as it's not requi= red for servers to support. Also, your recent proposal looks very good/fle= xible to me: Capability Identifier basic-mode =3D [trim | explicit | report-all] also-supported =3D 0 or more of [trim | explicit | report-all | report-a= ll-tagged] where the "0 or more" is intentional; trim and explicit servers are not required to support any additional modes. Modification to , , [full-list-of-enums] where "report-all-tagged" directs the server to add the XML attribute wd:default=3D'true' to nodes it believes are "default". For explicit an= d trim servers, default nodes are those that it would otherwise not send. For report-all servers, default nodes are those that have the same value as its default value. Modification to , Servers advertising report-all-tagged MUST handle nodes containing the XML attribute wd:default=3D'true'. When passed in conjunction with=20 's "test-option", these servers MAY validate that the value is indeed the default value, but, otherwise, these servers MUST discard/ignore nodes containing the wd:default=3D'true' attribute; they are not retained in any datastore, specifically the candidate datastore. What do you think? Thanks, Kent From andyb@iwl.com Wed May 12 14:50: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 03B8E3A6876 for ; Wed, 12 May 2010 14:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=-0.949, BAYES_50=0.001, J_CHICKENPOX_74=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 wwk26yP29DEk for ; Wed, 12 May 2010 14:50:05 -0700 (PDT) Received: from smtp174.iad.emailsrvr.com (smtp174.iad.emailsrvr.com [207.97.245.174]) by core3.amsl.com (Postfix) with ESMTP id 8425C3A6905 for ; Wed, 12 May 2010 14:50:04 -0700 (PDT) Received: from relay7.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay7.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id B3D661DED52; Wed, 12 May 2010 17:49:53 -0400 (EDT) Received: by relay7.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 44E2E1DED2C; Wed, 12 May 2010 17:49:53 -0400 (EDT) Message-ID: <4BEB22A8.7050304@iwl.com> Date: Wed, 12 May 2010 14:50:32 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <4BEAB963.2040103@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763AE@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D763AE@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] with-defaults consensus time 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, 12 May 2010 21:50:10 -0000 Kent Watsen wrote: > > Hi Andy, > > >> I think we are reaching a compromise. >> > > No problem - supporting untagged defaults is fine so long as it's not required for servers to support. Also, your recent proposal looks very good/flexible to me: > > > Capability Identifier > > basic-mode = [trim | explicit | report-all] > also-supported = 0 or more of [trim | explicit | report-all | report-all-tagged] > > where the "0 or more" is intentional; trim and explicit servers are > not required to support any additional modes. > > > Modification to , , > > [full-list-of-enums] > > where "report-all-tagged" directs the server to add the XML attribute > wd:default='true' to nodes it believes are "default". For explicit and > trim servers, default nodes are those that it would otherwise not send. > For report-all servers, default nodes are those that have the same value > as its default value. > > > If basic-mode='report-all' then the server is not required to keep track of defaults, so it cannot tag anything. In all cases, the tagged nodes are the ones that would be left out of a basic-mode reply. Juergen pointed out that entire list entries might be left out of a reply because they are operational state, not config. I guess the tagging still works, right? > Modification to , > > Servers advertising report-all-tagged MUST handle nodes containing the > XML attribute wd:default='true'. When passed in conjunction with > 's "test-option", these servers MAY validate that the > value is indeed the default value, but, otherwise, these servers MUST > discard/ignore nodes containing the wd:default='true' attribute; they > are not retained in any datastore, specifically the candidate datastore. > > This is different than the client-side ignore. Ignoring the attribute is one thing but ignoring the entire element is another. A report-all server does not want the tagged nodes discarded. I am not sure any trim/explicit server wants the elements trimmed. The XML attribute is not retained in any datastore target (candidate, running, startup, or URL file). What if the current node value is no longer the default? Then an edit/copy source that tags the node as the default is really asking for a config-change. This cannot be ignored. It has to be honored or an error returned. A delete needs to be used to return a node to its default (from a non-default). Using edit-config will cause an explicit server to treat the new (default) value as an explicit value. It will not return the node to its default. > What do you think? > There needs to be an XSD defining a qualified (global) attribute. Is this attribute limited to leaf nodes? Either way, the attribute definition needs to define the scope of the default=true. (entire XML subtree in every case?) > Thanks, > Kent > > > Andy From kwatsen@juniper.net Wed May 12 17:00: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 C1FFC3A6928 for ; Wed, 12 May 2010 17:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.435 X-Spam-Level: X-Spam-Status: No, score=-4.435 tagged_above=-999 required=5 tests=[AWL=-1.036, BAYES_50=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvYPwHnFPcwJ for ; Wed, 12 May 2010 17:00:36 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id C832A3A68F7 for ; Wed, 12 May 2010 17:00:35 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKS+tBGKqquot/pb9RMy9nMaFbHetYrWyE@postini.com; Wed, 12 May 2010 17:00:26 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 12 May 2010 16:58:40 -0700 From: Kent Watsen To: "'andyb@iwl.com'" Date: Wed, 12 May 2010 16:58:40 -0700 Thread-Topic: with-defaults consensus time Thread-Index: AcryHQ8PbUhx4pguRR20qehJi4mZmgAA2kIg Message-ID: <84600D05C20FF943918238042D7670FD36C7D763B0@EMBX01-HQ.jnpr.net> References: <4BEAB963.2040103@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763AE@EMBX01-HQ.jnpr.net> <4BEB22A8.7050304@iwl.com> In-Reply-To: <4BEB22A8.7050304@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: NETCONF Subject: Re: [Netconf] with-defaults consensus time X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 13 May 2010 00:00:36 -0000 > If basic-mode=3D'report-all' then the server is not required to=20 > keep track of defaults, so it cannot tag anything. True, but this text was in a block for report-all-tagged, which I assuming = could also be presented by a basic-mode=3Dreport-all server and, if it does= , then that behavior make sense. If the server doesn't support it, then it= shouldn't advertise report-all-tagged... > In all cases, the tagged nodes are the ones that would be=20 > left out of a basic-mode reply. That definition makes sense, as long as we don't allow a basic-mode=3Drepor= t-all server to also support the "report-all-tagged" mode > Juergen pointed out that entire list entries might be left=20 > out of a reply because they are operational state, not config. > I guess the tagging still works, right? Yes, makes sense > A report-all server does not want the tagged nodes discarded. Good point! > I am not sure any trim/explicit server wants the elements trimmed. An explicit server needs to do something to avoid default bloat, but you're= right that trim server doesn't care, it will trim the default values again= anyway... > The XML attribute is not retained in any datastore target=20 > (candidate, running, startup, or URL file). Sure, adding URL file to that list makes sense > What if the current node value is no longer the default? > Then an edit/copy source that tags the node as the default is=20 > really asking for a config-change. This cannot be ignored. > It has to be honored or an error returned. A delete needs to=20 > be used to return a node to its default (from a non-default). > Using edit-config will cause an explicit server to treat the=20 > new (default) value as an explicit value. It will not return=20 > the node to its default. Interesting. It certainly is the most conservative to make the server vali= date that the tagged-nodes are still, in fact, defaults - assuming there ar= e no implementation concerns... > There needs to be an XSD defining a qualified (global) attribute. > Is this attribute limited to leaf nodes? > Either way, the attribute definition needs to define the=20 > scope of the default=3Dtrue. (entire XML subtree in every case?) YANG only supports default on leafs. If a device as a default container (i= s that even possible?), report-all-tagged should return the subtree while t= agging the container node, with the understanding it recursively applies to= all its decedents. As you say, the entire XML subtree in every case Thanks, Kent From andyb@iwl.com Thu May 13 12:31: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 D95893A6832 for ; Thu, 13 May 2010 12:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.218 X-Spam-Level: X-Spam-Status: No, score=0.218 tagged_above=-999 required=5 tests=[AWL=-1.317, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_27=0.6, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSCNTbl95s3f for ; Thu, 13 May 2010 12:31:50 -0700 (PDT) Received: from smtp134.dfw.emailsrvr.com (smtp134.dfw.emailsrvr.com [67.192.241.134]) by core3.amsl.com (Postfix) with ESMTP id 667DE3A6D1B for ; Thu, 13 May 2010 12:30:50 -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 7DE823130D88; Thu, 13 May 2010 15:30:40 -0400 (EDT) Received: by relay13.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 309023130B59; Thu, 13 May 2010 15:30:40 -0400 (EDT) Message-ID: <4BEC538D.6090003@iwl.com> Date: Thu, 13 May 2010 12:31:25 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <4BEAB963.2040103@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763AE@EMBX01-HQ.jnpr.net> <4BEB22A8.7050304@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763B0@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D763B0@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] with-defaults consensus time 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, 13 May 2010 19:31:52 -0000 Kent Watsen wrote: >> If basic-mode='report-all' then the server is not required to keep >> track of defaults, so it cannot tag anything. > > True, but this text was in a block for report-all-tagged, which I > assuming could also be presented by a basic-mode=report-all server > and, if it does, then that behavior make sense. If the server > doesn't support it, then it shouldn't advertise report-all-tagged... > oops -- my mistake if it was just report-all-tagged. I missed that. > > >> In all cases, the tagged nodes are the ones that would be left out >> of a basic-mode reply. > > That definition makes sense, as long as we don't allow a > basic-mode=report-all server to also support the "report-all-tagged" > mode > it would not really mean anything. I would rather not make a rule. I will point out what is expected to be tagged. For basic-mode=report-all, that is nothing. > > >> Juergen pointed out that entire list entries might be left out of a >> reply because they are operational state, not config. I guess the >> tagging still works, right? > > Yes, makes sense > Yes, by our definition of wd;default it will make sense. > > >> A report-all server does not want the tagged nodes discarded. > > Good point! > > > >> I am not sure any trim/explicit server wants the elements trimmed. > > An explicit server needs to do something to avoid default bloat, but > you're right that trim server doesn't care, it will trim the default > values again anyway... > You are assuming that the target database is still in synch with the new config tags. No matter what, the server will treat differences in the and the target database as edits. It all depends on the operation-in-effect, the new value, and the current value. The WG needs to be caseful wrt/ changing this delicate operational model as a side affect of the wd:default attribute being present in an edit-config or copy-config. IMO, there are 2 requirements for wd:default in server input: Req 1) All servers MUST treat wd:default in input the same way. Req 2) All servers that encounter the wd:default='true' XML attribute MUST treat the tagged node as a conceptual request to convert that node from any set value to a 'default node'. The editing operation, in affect (e.g. nc:operation) MUST NOT conflict with this conceptual edit request. The client can achieve this 'force back to default' mode by using copy-config or nc:operation='replace', and the server simply ignoring the tagged nodes. The problem is that the merge operation does not provide this 'force back to default' feature. Note that allowing the wd:default attribute to have any affect at all on the server editing operations means the client needs to be careful with report-all-tagged data. > > >> The XML attribute is not retained in any datastore target >> (candidate, running, startup, or URL file). > > Sure, adding URL file to that list makes sense > > > >> What if the current node value is no longer the default? Then an >> edit/copy source that tags the node as the default is really asking >> for a config-change. This cannot be ignored. It has to be honored >> or an error returned. A delete needs to be used to return a node >> to its default (from a non-default). Using edit-config will cause >> an explicit server to treat the new (default) value as an explicit >> value. It will not return the node to its default. > > Interesting. It certainly is the most conservative to make the > server validate that the tagged-nodes are still, in fact, defaults - > assuming there are no implementation concerns... > IMO, they must be processed the same way on all servers -- see above > > > >> There needs to be an XSD defining a qualified (global) attribute. >> Is this attribute limited to leaf nodes? Either way, the attribute >> definition needs to define the scope of the default=true. (entire >> XML subtree in every case?) > > YANG only supports default on leafs. If a device as a default > container (is that even possible?), report-all-tagged should return > the subtree while tagging the container node, with the understanding > it recursively applies to all its decedents. As you say, the entire > XML subtree in every case > I will construct a definition that is XML-specific, not YANG-specific. This will go in the wd:default XSD. > > Thanks, Kent > Andy From kwatsen@juniper.net Fri May 14 14:40: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 480063A6965 for ; Fri, 14 May 2010 14:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.478 X-Spam-Level: X-Spam-Status: No, score=-4.478 tagged_above=-999 required=5 tests=[AWL=-0.893, BAYES_40=-0.185, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsRpUw8wfHDg for ; Fri, 14 May 2010 14:40:57 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 388E03A68F8 for ; Fri, 14 May 2010 14:40:57 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKS+3DXTNU6McY8zJBM9rV9i6l2sn6Yrxp@postini.com; Fri, 14 May 2010 14:40:48 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 14 May 2010 14:39:31 -0700 From: Kent Watsen To: "'andyb@iwl.com'" Date: Fri, 14 May 2010 14:39:30 -0700 Thread-Topic: with-defaults consensus time Thread-Index: Acry0saV2bm2KipZQXWGxU2GMcM8nQA2bl4A Message-ID: <84600D05C20FF943918238042D7670FD36C7D763C8@EMBX01-HQ.jnpr.net> References: <4BEAB963.2040103@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763AE@EMBX01-HQ.jnpr.net> <4BEB22A8.7050304@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763B0@EMBX01-HQ.jnpr.net> <4BEC538D.6090003@iwl.com> In-Reply-To: <4BEC538D.6090003@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: NETCONF Subject: Re: [Netconf] with-defaults consensus time X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 14 May 2010 21:40:58 -0000 > The WG needs to be caseful wrt/ changing this delicate=20 > operational model as a side affect of the wd:default=20 > attribute being present in an edit-config or copy-config. >=20 > IMO, there are 2 requirements for wd:default in server input: >=20 > Req 1) All servers MUST treat wd:default in input the same way. >=20 > Req 2) All servers that encounter the wd:default=3D'true'=20 > XML attribute > MUST treat the tagged node as a conceptual=20 > request to convert that > node from any set value to a 'default node'. =20 > The editing operation, > in affect (e.g. nc:operation) MUST NOT conflict=20 > with this > conceptual edit request. >=20 > The client can achieve this 'force back to default' mode by=20 > using copy-config or nc:operation=3D'replace', and the server=20 > simply ignoring the tagged nodes. The problem is that the=20 > merge operation does not provide this 'force back to default' > feature. >=20 > Note that allowing the wd:default attribute to have any=20 > affect at all on the server editing operations means the=20 > client needs to be careful with report-all-tagged data. This is a good analysis - thanks > I will construct a definition that is XML-specific, not YANG-specific. > This will go in the wd:default XSD. Looking forward to seeing it - thanks Andy Thanks again, Kent From andyb@iwl.com Fri May 14 14:48: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 C22FA3A67E7 for ; Fri, 14 May 2010 14:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.445 X-Spam-Level: X-Spam-Status: No, score=0.445 tagged_above=-999 required=5 tests=[AWL=-1.504, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6, J_CHICKENPOX_46=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 N25EG3e-PyDE for ; Fri, 14 May 2010 14:48:39 -0700 (PDT) Received: from smtp124.dfw.emailsrvr.com (smtp124.dfw.emailsrvr.com [67.192.241.124]) by core3.amsl.com (Postfix) with ESMTP id 80E253A6826 for ; Fri, 14 May 2010 14:48:35 -0700 (PDT) Received: from relay2.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay2.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 3601AE2322D; Fri, 14 May 2010 17:48:26 -0400 (EDT) Received: by relay2.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id BBF5BE23256; Fri, 14 May 2010 17:48:25 -0400 (EDT) Message-ID: <4BEDC55E.2080406@iwl.com> Date: Fri, 14 May 2010 14:49:18 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <4BEAB963.2040103@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763AE@EMBX01-HQ.jnpr.net> <4BEB22A8.7050304@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763B0@EMBX01-HQ.jnpr.net> <4BEC538D.6090003@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763C8@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D763C8@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] with-defaults consensus time 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, 14 May 2010 21:48:42 -0000 Kent Watsen wrote: >> The WG needs to be caseful wrt/ changing this delicate >> operational model as a side affect of the wd:default >> attribute being present in an edit-config or copy-config. >> >> IMO, there are 2 requirements for wd:default in server input: >> >> Req 1) All servers MUST treat wd:default in input the same way. >> >> Req 2) All servers that encounter the wd:default='true' >> XML attribute >> MUST treat the tagged node as a conceptual >> request to convert that >> node from any set value to a 'default node'. >> The editing operation, >> in affect (e.g. nc:operation) MUST NOT conflict >> with this >> conceptual edit request. >> >> The client can achieve this 'force back to default' mode by >> using copy-config or nc:operation='replace', and the server >> simply ignoring the tagged nodes. The problem is that the >> merge operation does not provide this 'force back to default' >> feature. >> >> Note that allowing the wd:default attribute to have any >> affect at all on the server editing operations means the >> client needs to be careful with report-all-tagged data. >> > > This is a good analysis - thanks > > I did not mention that the server does not keep the XML attribute, but that is implied. It is not mentioned for nc:operation or yang:insert, but the same implementation detail applies. > > > >> I will construct a definition that is XML-specific, not YANG-specific. >> This will go in the wd:default XSD. >> > > Looking forward to seeing it - thanks Andy > > > OK -- if anybody has any objections to these changes then they could speed up the process by speaking up now. > Thanks again, > Kent > > Andy From andyb@iwl.com Tue May 18 15:30:01 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03AA63A6916 for ; Tue, 18 May 2010 15:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.297 X-Spam-Level: X-Spam-Status: No, score=-0.297 tagged_above=-999 required=5 tests=[AWL=-0.632, 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 ym61s9hBayWI for ; Tue, 18 May 2010 15:30:00 -0700 (PDT) Received: from smtp154.dfw.emailsrvr.com (smtp154.dfw.emailsrvr.com [67.192.241.154]) by core3.amsl.com (Postfix) with ESMTP id A4FC23A6902 for ; Tue, 18 May 2010 15:29:56 -0700 (PDT) Received: from relay25.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay25.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 489F23D003C9 for ; Tue, 18 May 2010 18:29:49 -0400 (EDT) Received: by relay25.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 29AD23D003C6 for ; Tue, 18 May 2010 18:29:49 -0400 (EDT) Message-ID: <4BF314E0.90604@iwl.com> Date: Tue, 18 May 2010 15:29:52 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] problem with validate: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: Tue, 18 May 2010 22:30:01 -0000 Hi, I am working on the next version of the 4741bis draft. feature validate { status "deprecated"; ... } feature validate-1.1 { ... } leaf test-option { if-feature validate; type enumeration { enum test-then-set; enum set; enum test-only { description "This value can only be used if the 'validate-1.1' feature is supported."; } } } Notice what is broken? We can never deprecate the validate:1.0 capability feature because of the 'if-feature' stmt in the 'test-option' leaf. We can only AND if-feature-stmts together, not OR them together like is needed in this case: leaf test-option { if-feature "validate or validate-1.1"; type enumeration { ... } } Another solution (I've already implemented) is to use an XPath function: boolean feature-enabled (string module-name, string feature-name); Returns 'true' if the feature 'feature-name' from module 'module-name' is enabled. Returns 'false' otherwise. leaf test-option { when "feature-enabled('ietf-netconf', 'validate') or feature-enabled('ietf-netconf', 'validate-1.1')"; type enumeration { ... } } Another solution is to remove the 'status deprecated' from the validate feature, and add an if-feature validate; statement to the validate-1.1 feature. Essentially, we can never deprecate old features, just keep adding to them. So which solution should we use? 1) change YANG if-feature-stmt 2) add feature-enabled XPath function for when-stmt 3) never deprecate the old feature version; the new version adds to the old instead of replacing it. Only (3) is easy in the short-term, but also the most painful in the long-term. Andy From andyb@iwl.com Wed May 19 15:23: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 3C46A3A69E5 for ; Wed, 19 May 2010 15:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[AWL=-1.259, BAYES_50=0.001, FRT_BEFORE=1.272, 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 Vh9616k8f2MI for ; Wed, 19 May 2010 15:23:13 -0700 (PDT) Received: from smtp194.dfw.emailsrvr.com (smtp194.dfw.emailsrvr.com [67.192.241.194]) by core3.amsl.com (Postfix) with ESMTP id 418023A6910 for ; Wed, 19 May 2010 15:23:02 -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 2C80F2748709 for ; Wed, 19 May 2010 18:22:55 -0400 (EDT) Received: by relay19.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 0C03527486FB for ; Wed, 19 May 2010 18:22:54 -0400 (EDT) Message-ID: <4BF464C3.20800@iwl.com> Date: Wed, 19 May 2010 15:22:59 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] rpc-error details 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, 19 May 2010 22:23:18 -0000 Hi, I want to check consensus on 4 little details for in 4741bis. Note that these would only apply if the client and server both request base:1.1 in their message: 1) rpc-warning error-tag Does the WG want to add a new error-tag that would allow new NETCONF capabilities and YANG data models to utilize the error-severity=warning mode. The next chance to add warnings may not be for 3-5 years. Just because there are no protocol warnings is irrelevant. This error could only be allowed for error-type=application, although I think the 'validate' operation should be able to issue implementation-specific warnings. [Default: do not add] 2) capability-changed error-tag Does the WG want to add a new error-tag to indicate that the operation did not have a specific error, but rather the session capabilities have changed and no further operations will be accepted. (TBD: operation to clear this state.) [Default: add (consensus from Anaheim)] 3) Change 'error-app-tag' from maxOccurs=1 to maxOccurs=unbounded Sometimes the standard modules require a particular error-app-tag. Sometimes the YANG module has an error-app-tag specified by the YANG author. Sometimes vendors hardwire their own error-app-tag to support their own applications. [Default: do not change] 4) Change 'error-message' from maxOccurs=1 to maxOccurs=unbounded Sometimes the standard modules require a particular error-message. Sometimes the YANG module has an error-message specified by the YANG author. Sometimes vendors hardwire their own error-message to support their own applications. Some servers may want to support multiple languages at once, but the current spec does not allow it. [Default: do not change] Andy From root@core3.amsl.com Thu May 20 13:15: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 E47113A68C6; Thu, 20 May 2010 13: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: <20100520201502.E47113A68C6@core3.amsl.com> Date: Thu, 20 May 2010 13:15:02 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action: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, 20 May 2010 20:15:03 -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-08.txt Pages : 30 Date : 2010-05-20 The NETCONF protocol defines ways to read and edit configuration data from a NETCONF server. Part of this data may not be set by the NETCONF client, but rather a default value is used. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to 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 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-with-defaults-08.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-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-20130942.I-D@ietf.org> --NextPart-- From kwatsen@juniper.net Thu May 20 13:40: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 5EF5E3A6783 for ; Thu, 20 May 2010 13:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.009 X-Spam-Level: X-Spam-Status: No, score=-4.009 tagged_above=-999 required=5 tests=[AWL=-1.282, BAYES_50=0.001, FRT_BEFORE=1.272, 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 ujc-5Chaqvi5 for ; Thu, 20 May 2010 13:40:54 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 308F83A63D3 for ; Thu, 20 May 2010 13:40:51 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKS/WeS+YSEcNgtuWON46NVqoGlLgsuiO5@postini.com; Thu, 20 May 2010 13:40:48 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Thu, 20 May 2010 13:40:23 -0700 From: Kent Watsen To: "'andyb@iwl.com'" , NETCONF Date: Thu, 20 May 2010 13:40:22 -0700 Thread-Topic: [Netconf] rpc-error details Thread-Index: Acr3oegsXvTXEguBQ3GTJJFrM/FJ1gAtxiXw Message-ID: <84600D05C20FF943918238042D7670FD36C7D763E3@EMBX01-HQ.jnpr.net> References: <4BF464C3.20800@iwl.com> In-Reply-To: <4BF464C3.20800@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] rpc-error details X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 20:40:55 -0000 > 1) rpc-warning error-tag >=20 > Does the WG want to add a new error-tag that would allow > new NETCONF capabilities and YANG data models to utilize the > error-severity=3Dwarning mode. The next chance to add warnings > may not be for 3-5 years. Just because there are no protocol > warnings is irrelevant. This error could only be allowed for > error-type=3Dapplication, although I think the 'validate' > operation should be able to issue implementation-specific warnings. >=20 > [Default: do not add] Is the idea to allow a server to return an instead of a with error-severity=3Dwarning? I think that this would be nice to = have as currently we have to document that clients must not assume means there was an error - it's a bit confusing... BTW, our only use for warnings may interest the group. Essentially, we all= ow a RPC to return a warning to identify any implicit-changes the = device made (e.g. hashing a clear-text password) that warrant the applicati= on to the new value from the device. Specifically, we have: * for each implicit-change, the contains one * each is filled in as follows: error-type "application" error-tag "partial-operation" error-severity "warning" error-app-tag "implicit-change" error-path The XPath to the node(s) that changed error-message A human-readable string indicating the reason for=20 the implicit-change. If no reason can be provided,=20 the string "The specified nodes have been implicitly changed" should be used Thanks, Kent From andyb@iwl.com Thu May 20 13:51: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 E7C103A683C for ; Thu, 20 May 2010 13:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.272 X-Spam-Level: X-Spam-Status: No, score=0.272 tagged_above=-999 required=5 tests=[AWL=-1.149, BAYES_40=-0.185, FRT_BEFORE=1.272, 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 hfOuJfI7BtTK for ; Thu, 20 May 2010 13:51:28 -0700 (PDT) Received: from smtp154.dfw.emailsrvr.com (smtp154.dfw.emailsrvr.com [67.192.241.154]) by core3.amsl.com (Postfix) with ESMTP id 2DEC83A6898 for ; Thu, 20 May 2010 13:51:27 -0700 (PDT) Received: from relay25.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay25.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 8075A3602F9; Thu, 20 May 2010 16:51:20 -0400 (EDT) Received: by relay25.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 4C4DE360224; Thu, 20 May 2010 16:51:20 -0400 (EDT) Message-ID: <4BF5A0CD.7090909@iwl.com> Date: Thu, 20 May 2010 13:51:25 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <4BF464C3.20800@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763E3@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D763E3@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] rpc-error details 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, 20 May 2010 20:51:29 -0000 Kent Watsen wrote: >> 1) rpc-warning error-tag >> >> Does the WG want to add a new error-tag that would allow new >> NETCONF capabilities and YANG data models to utilize the >> error-severity=warning mode. The next chance to add warnings may >> not be for 3-5 years. Just because there are no protocol warnings >> is irrelevant. This error could only be allowed for >> error-type=application, although I think the 'validate' operation >> should be able to issue implementation-specific warnings. >> >> [Default: do not add] > > > > Is the idea to allow a server to return an instead of a > with error-severity=warning? I think that this would be > nice to have as currently we have to document that clients must not > assume means there was an error - it's a bit confusing... > No. The element is still . We currently have no error-tag that uses an errorseverity value of 'warning'. Since error-tag values are hardwired, that means nobody can use error-severity=warning. > > BTW, our only use for warnings may interest the group. Essentially, > we allow a RPC to return a warning to identify any > implicit-changes the device made (e.g. hashing a clear-text password) > that warrant the application to the new value from the > device. Specifically, we have: > > * for each implicit-change, the contains one > * each is filled in as follows: > > error-type "application" error-tag "partial-operation" > error-severity "warning" error-app-tag "implicit-change" > error-path The XPath to the node(s) that changed error-message This does not follow the rules in RFC 4741 for a partial-operation error-tag. Technically, a server MUST encode according to the specification. > A human-readable string indicating the reason for the > implicit-change. If no reason can be provided, the string "The > specified nodes have been implicitly changed" should be used > I am not trying to standardize particular warnings. I am trying to make it legal to use any sort of error-severity=warning. > > Thanks, Kent > > > Andy From andyb@iwl.com Thu May 20 14:15: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 4A5D53A6358 for ; Thu, 20 May 2010 14:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.89 X-Spam-Level: X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[AWL=0.709, 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 FisH1ZEvxsyt for ; Thu, 20 May 2010 14:15:52 -0700 (PDT) Received: from smtp134.iad.emailsrvr.com (smtp134.iad.emailsrvr.com [207.97.245.134]) by core3.amsl.com (Postfix) with ESMTP id 1F0243A68CB for ; Thu, 20 May 2010 14:15:08 -0700 (PDT) Received: from relay23.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay23.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id C53041B47D2; Thu, 20 May 2010 17:14:56 -0400 (EDT) Received: by relay23.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 44AF71B4479; Thu, 20 May 2010 17:14:56 -0400 (EDT) Message-ID: <4BF5A655.7050705@iwl.com> Date: Thu, 20 May 2010 14:15:01 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <4BF464C3.20800@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763E3@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D763E3@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF Subject: Re: [Netconf] rpc-error details 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, 20 May 2010 21:15:53 -0000 Kent Watsen wrote: >> 1) rpc-warning error-tag >> ... >> FYI, the partial-operation error-tag is going away in 4741bis. The full proposal for warnings has been posted, but I will try to rewrite it here: error-type: application error-tag: rpc-warning error-severity: warning error-app-tag: [set by application] error-path: [set by application] error-message: [human readable warning message] error-info: [set by application] > > Thanks, > Kent > Andy From andyb@iwl.com Fri May 21 09:58: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 342EB3A6CAD for ; Fri, 21 May 2010 09:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.38 X-Spam-Level: X-Spam-Status: No, score=0.38 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_50=0.001, FRT_BEFORE=1.272, 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 e8pL8zkfR0j1 for ; Fri, 21 May 2010 09:58:28 -0700 (PDT) Received: from smtp154.dfw.emailsrvr.com (smtp154.dfw.emailsrvr.com [67.192.241.154]) by core3.amsl.com (Postfix) with ESMTP id 406353A92B0 for ; Fri, 21 May 2010 04:49:39 -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 1E82A3EFC80; Fri, 21 May 2010 07:49:33 -0400 (EDT) Received: by relay5.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id C6F1E3EFA59; Fri, 21 May 2010 07:49:32 -0400 (EDT) Message-ID: <4BF6734D.3090307@iwl.com> Date: Fri, 21 May 2010 04:49:33 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Bjorklund References: <4BF464C3.20800@iwl.com> <20100521.131210.78187880.mbj@tail-f.com> In-Reply-To: <20100521.131210.78187880.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-error details 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, 21 May 2010 16:58:29 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: > >> Hi, >> >> I want to check consensus on 4 little details for >> in 4741bis. Note that these would only apply if the client and server >> both request base:1.1 in their message: >> >> 1) rpc-warning error-tag >> >> Does the WG want to add a new error-tag that would allow >> new NETCONF capabilities and YANG data models to utilize the >> error-severity=warning mode. The next chance to add warnings >> may not be for 3-5 years. Just because there are no protocol >> warnings is irrelevant. This error could only be allowed for >> error-type=application, although I think the 'validate' >> operation should be able to issue implementation-specific warnings. >> >> [Default: do not add] >> > > +1 to the default > > If we want to add warnings, we need to describe how they are supposed > to work. For example, it must be clear that clients cannot just check > for if they want to know if something succeeded or not. They > also must check all elements for warnings. > > Of course the client would have to check the error-severity field to see if the response is an error or a warning. That is what the WG intended when it was written, Other than that, why is this a problem? Only a base:1.1 session would be allowed to use it. By definition, warnings are fuzzy and even implementation-specific. Maybe we should remove error-severity since it is just wasting space in the PDU. > >> 2) capability-changed error-tag >> >> Does the WG want to add a new error-tag to indicate that the >> operation did not have a specific error, but rather the >> session capabilities have changed and no further operations >> will be accepted. (TBD: operation to clear this state.) >> >> [Default: add (consensus from Anaheim)] >> > > +1 to the default > -1 for me. The procedures for this complicated mess are not written down, and the WG doesn't agree on the, or even the need for this entire 'solution'. For example, a simple notification would be good enough, for sessions that actually cared about this condition. > >> 3) Change 'error-app-tag' from maxOccurs=1 to maxOccurs=unbounded >> >> Sometimes the standard modules require a particular error-app-tag. >> Sometimes the YANG module has an error-app-tag specified by the >> YANG author. Sometimes vendors hardwire their own error-app-tag >> to support their own applications. >> >> [Default: do not change] >> > > +1 to the default > > I am not sure it would be correct to use error-app-tags in this way. > > > IMO, error-app-tag is kind of useless because an application is never sure if its error-app-tag will be present, or if some standard has required an arbitrary string be used instead. If applications could look for 1 of N error-app-tags (e.g., 1 is an alias for another) then the original intent of error-app-tag would not be lost, like it is now. >> 4) Change 'error-message' from maxOccurs=1 to maxOccurs=unbounded >> >> Sometimes the standard modules require a particular error-message. >> Sometimes the YANG module has an error-message specified by the >> YANG author. Sometimes vendors hardwire their own error-message >> to support their own applications. Some servers may want to >> support multiple languages at once, but the current spec does >> not allow it. >> >> [Default: do not change] >> > > I would not mind this change. It _can_ be achieved by sending > multiple rpc-errors, but if you want to support mulitple langauges, > this change would be a better solution, since it is clear that each > error-message describes the same error. > > > /martin > > Andy From andyb@iwl.com Fri May 21 12:53: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 62B533A67EF for ; Fri, 21 May 2010 12:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_50=0.001, FRT_BEFORE=1.272, 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 U-MsgYuc257j for ; Fri, 21 May 2010 12:53:16 -0700 (PDT) Received: from smtp144.dfw.emailsrvr.com (smtp144.dfw.emailsrvr.com [67.192.241.144]) by core3.amsl.com (Postfix) with ESMTP id 368143A6B94 for ; Fri, 21 May 2010 08:19:47 -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 4AE4B908422; Fri, 21 May 2010 11:19:41 -0400 (EDT) Received: by relay14.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 1D105908578; Fri, 21 May 2010 11:19:41 -0400 (EDT) Message-ID: <4BF6A48D.2040606@iwl.com> Date: Fri, 21 May 2010 08:19:41 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Bjorklund References: <4BF464C3.20800@iwl.com> <20100521.131210.78187880.mbj@tail-f.com> In-Reply-To: <20100521.131210.78187880.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] rpc-error details 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, 21 May 2010 19:53:17 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: > >> Hi, >> >> I want to check consensus on 4 little details for >> in 4741bis. Note that these would only apply if the client and server >> both request base:1.1 in their message: >> >> 1) rpc-warning error-tag >> >> Does the WG want to add a new error-tag that would allow >> new NETCONF capabilities and YANG data models to utilize the >> error-severity=warning mode. The next chance to add warnings >> may not be for 3-5 years. Just because there are no protocol >> warnings is irrelevant. This error could only be allowed for >> error-type=application, although I think the 'validate' >> operation should be able to issue implementation-specific warnings. >> >> [Default: do not add] >> > > +1 to the default > > If we want to add warnings, we need to describe how they are supposed > to work. For example, it must be clear that clients cannot just check > for if they want to know if something succeeded or not. They > also must check all elements for warnings. > > > You are right -- it is clear that changing the or logic in applications would be a major change. So if we ever do add warnings, it would probably need to be in a new element that was allowed to be sent along with . It doesn't seem like we will ever set the error-severity field to 'warning'. >> 2) capability-changed error-tag >> >> Does the WG want to add a new error-tag to indicate that the >> operation did not have a specific error, but rather the >> session capabilities have changed and no further operations >> will be accepted. (TBD: operation to clear this state.) >> >> [Default: add (consensus from Anaheim)] >> > > +1 to the default > My new concern: I would like to see the entire solution package in more detail, especially the mechanism to clear this error condition. It is not that clear to me that a client developer would want to set the 'on-capability-change=error' parameter in the without a way to clear the error. Otherwise, the server should just drop the session since that's all the client can do anyway. Also, resending the requires that the client save each . A notification that provided patches to the the current capabilities seems easier to use for the client. A capability-changed event seems to be the exact sort of intended use for RFC 5277. I don't understand why we don't use it. .... > > /martin > > Andy From mbj@tail-f.com Fri May 21 13:00: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 19A3F3A69D2 for ; Fri, 21 May 2010 13:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.012 X-Spam-Level: * X-Spam-Status: No, score=1.012 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_50=0.001, FRT_BEFORE=1.272, 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 9CiintSWjlk8 for ; Fri, 21 May 2010 13:00: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 2672A3A72B0 for ; Fri, 21 May 2010 04:12:17 -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 B11FF76C09A; Fri, 21 May 2010 13:12:10 +0200 (CEST) Date: Fri, 21 May 2010 13:12:10 +0200 (CEST) Message-Id: <20100521.131210.78187880.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4BF464C3.20800@iwl.com> References: <4BF464C3.20800@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] rpc-error details X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 20:00:54 -0000 Andy Bierman wrote: > Hi, > > I want to check consensus on 4 little details for > in 4741bis. Note that these would only apply if the client and server > both request base:1.1 in their message: > > 1) rpc-warning error-tag > > Does the WG want to add a new error-tag that would allow > new NETCONF capabilities and YANG data models to utilize the > error-severity=warning mode. The next chance to add warnings > may not be for 3-5 years. Just because there are no protocol > warnings is irrelevant. This error could only be allowed for > error-type=application, although I think the 'validate' > operation should be able to issue implementation-specific warnings. > > [Default: do not add] +1 to the default If we want to add warnings, we need to describe how they are supposed to work. For example, it must be clear that clients cannot just check for if they want to know if something succeeded or not. They also must check all elements for warnings. > 2) capability-changed error-tag > > Does the WG want to add a new error-tag to indicate that the > operation did not have a specific error, but rather the > session capabilities have changed and no further operations > will be accepted. (TBD: operation to clear this state.) > > [Default: add (consensus from Anaheim)] +1 to the default > 3) Change 'error-app-tag' from maxOccurs=1 to maxOccurs=unbounded > > Sometimes the standard modules require a particular error-app-tag. > Sometimes the YANG module has an error-app-tag specified by the > YANG author. Sometimes vendors hardwire their own error-app-tag > to support their own applications. > > [Default: do not change] +1 to the default I am not sure it would be correct to use error-app-tags in this way. > 4) Change 'error-message' from maxOccurs=1 to maxOccurs=unbounded > > Sometimes the standard modules require a particular error-message. > Sometimes the YANG module has an error-message specified by the > YANG author. Sometimes vendors hardwire their own error-message > to support their own applications. Some servers may want to > support multiple languages at once, but the current spec does > not allow it. > > [Default: do not change] I would not mind this change. It _can_ be achieved by sending multiple rpc-errors, but if you want to support mulitple langauges, this change would be a better solution, since it is clear that each error-message describes the same error. /martin From mbj@tail-f.com Fri May 21 13:12: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 D6EB83A6C93 for ; Fri, 21 May 2010 13:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[AWL=-0.154, 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 7o24PkhgEmjz for ; Fri, 21 May 2010 13:09: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 284043A87F7 for ; Fri, 21 May 2010 04:27:56 -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 AA90A76C09A; Fri, 21 May 2010 13:27:49 +0200 (CEST) Date: Fri, 21 May 2010 13:27:49 +0200 (CEST) Message-Id: <20100521.132749.237447611.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D763E3@EMBX01-HQ.jnpr.net> References: <4BF464C3.20800@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763E3@EMBX01-HQ.jnpr.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] rpc-error details X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 20:14:02 -0000 Hi Kent, Kent Watsen wrote: > BTW, our only use for warnings may interest the group. Essentially, we allow > a RPC to return a warning to identify any implicit-changes the device > made (e.g. hashing a clear-text password) that warrant the application to > the new value from the device. Specifically, we have: > > * for each implicit-change, the contains one > * each is filled in as follows: > > error-type "application" > error-tag "partial-operation" > error-severity "warning" > error-app-tag "implicit-change" > error-path The XPath to the node(s) that changed > error-message A human-readable string indicating the reason for > the implicit-change. If no reason can be provided, > the string "The specified nodes have been implicitly > changed" should be used This is not compliant with 4741, but you are probably aware of that. partial-operation is listed as an "error" (i.e. not warning) with the description: Some part of the requested operation failed or was not attempted for some reason. It also specifies that the ok-element, err-element, noop-element elements should be sent in error-info. As Andy wrote, this error will be removed in 4741bis. /martin From mbj@tail-f.com Fri May 21 13:29:38 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 C8C5E3A6EB3 for ; Fri, 21 May 2010 13:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.404 X-Spam-Level: X-Spam-Status: No, score=0.404 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 20hLAtfn-MSq for ; Fri, 21 May 2010 13:29:09 -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 5A7773A8892 for ; Fri, 21 May 2010 04:30:21 -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 D830476C09A; Fri, 21 May 2010 13:30:14 +0200 (CEST) Date: Fri, 21 May 2010 13:30:14 +0200 (CEST) Message-Id: <20100521.133014.102478691.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4BF314E0.90604@iwl.com> References: <4BF314E0.90604@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] problem with validate:1.1 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 21 May 2010 20:31:53 -0000 Andy Bierman wrote: > Hi, > > I am working on the next version of the 4741bis draft. > > > feature validate { > status "deprecated"; > ... > } > > feature validate-1.1 { > ... > } > > leaf test-option { > if-feature validate; > type enumeration { > enum test-then-set; > enum set; > enum test-only { > description > "This value can only be used if the 'validate-1.1' > feature is supported."; > } > } > } > > Notice what is broken? > We can never deprecate the validate:1.0 capability > feature because of the 'if-feature' stmt in the 'test-option' > leaf. Since we now have decided to define a base:1.1 capability, we should not even define the deprecated "validate" feature. This document should just define the validate:1.1 capabiltiy, and specifiy what it can do. /martin From kwatsen@juniper.net Fri May 21 13:41: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 0E0553A69E1 for ; Fri, 21 May 2010 13:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.589 X-Spam-Level: X-Spam-Status: No, score=-4.589 tagged_above=-999 required=5 tests=[AWL=-0.590, 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 qBmmPHCE2ulh for ; Fri, 21 May 2010 13:41:32 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 9499F3A690D for ; Fri, 21 May 2010 13:01:03 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKS/bmeUqfrT4jgmuQ7KwlvV93uES2j2i5@postini.com; Fri, 21 May 2010 13:01:00 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 21 May 2010 11:39:39 -0700 From: Kent Watsen To: "'andyb@iwl.com'" , Martin Bjorklund Date: Fri, 21 May 2010 11:39:38 -0700 Thread-Topic: [Netconf] rpc-error details Thread-Index: Acr5BtXnGwqtcWbDR8C0hO/ihwBsnwACr0Bg Message-ID: <84600D05C20FF943918238042D7670FD36C7D763E9@EMBX01-HQ.jnpr.net> References: <4BF464C3.20800@iwl.com> <20100521.131210.78187880.mbj@tail-f.com> <4BF6734D.3090307@iwl.com> In-Reply-To: <4BF6734D.3090307@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] rpc-error details X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 20:41:53 -0000 > Of course the client would have to check the error-severity > field to see if the response is an error or a warning. > That is what the WG intended when it was written, > Other than that, why is this a problem? > Only a base:1.1 session would be allowed to use it. >=20 > By definition, warnings are fuzzy and even implementation-specific. > Maybe we should remove error-severity since it is just > wasting space in the PDU. Please don't drop it, unless there is another way for a server to notify th= e client about implicit-changes - maybe allow app-specific fields with an <= ok>? > -1 for me. > The procedures for this complicated mess are not written down, > and the WG doesn't agree on the, or even the need for this > entire 'solution'. For example, a simple notification would > be good enough, for sessions that actually cared about this condition. -1 for me too; I agree with Andy's assessment > >> 3) Change 'error-app-tag' from maxOccurs=3D1 to maxOccurs=3Dunbounde= d > >> > >> Sometimes the standard modules require a particular error-app-tag. > >> Sometimes the YANG module has an error-app-tag specified by the > >> YANG author. Sometimes vendors hardwire their own error-app-tag > >> to support their own applications. > >> > >> [Default: do not change] I'm for sticking with the default. I don't see a good use case for needing = more than one error-app-tag per element... > > I would not mind this change. It _can_ be achieved by sending > > multiple rpc-errors, but if you want to support mulitple langauges, > > this change would be a better solution, since it is clear that each > > error-message describes the same error. Do you have another example? I'm not comfortable with this example as I be= lieve there are better ways to support internationalization Thanks, Kent From kwatsen@juniper.net Fri May 21 13:51: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 3890D3A6782 for ; Fri, 21 May 2010 13:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.865 X-Spam-Level: X-Spam-Status: No, score=-5.865 tagged_above=-999 required=5 tests=[AWL=0.734, 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 XN0QJpwYSnQj for ; Fri, 21 May 2010 13:51:14 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id D5FD13A6359 for ; Fri, 21 May 2010 13:51:10 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKS/byNe8DGRdVM7f5f3WJ0Hc8DCeBOQKv@postini.com; Fri, 21 May 2010 13:51:08 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Fri, 21 May 2010 13:50:51 -0700 From: Kent Watsen To: 'Martin Bjorklund' Date: Fri, 21 May 2010 13:50:51 -0700 Thread-Topic: [Netconf] rpc-error details Thread-Index: Acr42KfIfrFcUhMESSyPVq/qxCgXhgATX3rw Message-ID: <84600D05C20FF943918238042D7670FD36C7D763EB@EMBX01-HQ.jnpr.net> References: <4BF464C3.20800@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763E3@EMBX01-HQ.jnpr.net> <20100521.132749.237447611.mbj@tail-f.com> In-Reply-To: <20100521.132749.237447611.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] rpc-error details X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 20:51:16 -0000 > This is not compliant with 4741, but you are probably aware of that. > partial-operation is listed as an "error" (i.e. not warning) with the > description: >=20 > Some part of the requested operation failed or was not attempted for > some reason. Right, but we had to pick something, as no other error-tag allowed us to us= e warning. "partial operation" was the closest to describing our situation > It also specifies that the ok-element, err-element, noop-element > elements should be sent in error-info. True - we fudged this to make it "work" > As Andy wrote, this error will be removed in 4741bis. Then can we find another way to enable implicit-changes to be communicated = in an ? Thanks, Kent From andyb@iwl.com Fri May 21 13:58: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 AE81F3A684C for ; Fri, 21 May 2010 13:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[AWL=-0.607, 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 YMsKYgcoNOTG for ; Fri, 21 May 2010 13:58:13 -0700 (PDT) Received: from smtp204.iad.emailsrvr.com (smtp204.iad.emailsrvr.com [207.97.245.204]) by core3.amsl.com (Postfix) with ESMTP id DC5B93A6842 for ; Fri, 21 May 2010 13:58:13 -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 DA1181B4086 for ; Fri, 21 May 2010 15:42:21 -0400 (EDT) Received: by relay30.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id AAF141B4C14 for ; Fri, 21 May 2010 15:42:21 -0400 (EDT) Message-ID: <4BF6E21E.3050509@iwl.com> Date: Fri, 21 May 2010 12:42:22 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] error-app-tag in standards 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, 21 May 2010 20:58:14 -0000 Hi, I started a new thread because I want to understand how implementors use . There are several instances in standard NETCONF content where error-app-tag values are mandated. Besides creating busy work for server developers, I'm not sure this has any other impact. Strings like 'no-matches' or the worst one (in with-defaults!) called 'with-defaults-mode-not-supported', look like error messages with dashes instead of spaces. Why not mandate error messages instead? At least those can be translated into other languages. error-app-tag: Contains a string identifying the data-model-specific or implementation-specific error condition, if one exists. This element will not be present if no appropriate application error tag can be associated with a particular error condition. IMO, this field is over-loaded. The problem is when there may be more than 1 tag, not zero tags. Implementations cannot reply on this field if standards values override the vendor tag with an arbitrary string. We use this field for classifying errors into 1 of about 10 different enumerations, to help tune error dialogs based on a known set of enumerations. The IETF is overloading the error-app-tag field with random error messages. This ruins any vendor-specific use of this field. Andy From kwatsen@juniper.net Fri May 21 15:02: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 9BFF13A6924 for ; Fri, 21 May 2010 15:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.964 X-Spam-Level: X-Spam-Status: No, score=-4.964 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_20=-0.74, 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 WSiie993hqPa for ; Fri, 21 May 2010 15:02:38 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 723893A68CB for ; Fri, 21 May 2010 15:02:38 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKS/cC9GHjqsQyutGBX8pH0i5hIf/g3TWP@postini.com; Fri, 21 May 2010 15:02:32 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 21 May 2010 14:58:49 -0700 From: Kent Watsen To: "'andyb@iwl.com'" Date: Fri, 21 May 2010 14:58:50 -0700 Thread-Topic: [Netconf] rpc-error details Thread-Index: Acr5GBJG+vZLLFRpRHqXZbQ7jKScIwAEXqzw Message-ID: <84600D05C20FF943918238042D7670FD36C7D763ED@EMBX01-HQ.jnpr.net> References: <4BF464C3.20800@iwl.com> <20100521.131210.78187880.mbj@tail-f.com> <4BF6734D.3090307@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763E9@EMBX01-HQ.jnpr.net> <4BF6D820.3000209@iwl.com> In-Reply-To: <4BF6D820.3000209@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] rpc-error details X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 22:02:39 -0000 > I do not like that approach. > I would rather see a structured warning > rather than unspecified vendor-add-ons. A structured response would be best The thing about reporting implicit-changes is: 1) it must be in the - notifications didn't work for us 2) it's only applicable to , , and - it's not applicable to most RPCs The structure provided in the existing is pretty close to our n= eeds. There either of the following two choices would work: 1) define a new called "implicit-change" having error-severity=3Dwarning. We'd have to define that not all s are actually errors and, of course, we couldn't drop the field 2) define a new type with processing semantics similar . This strategy would allow of to drop the field. The schema could be something like: Thanks, Kent From andyb@iwl.com Fri May 21 15:28: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 B3BB53A6847 for ; Fri, 21 May 2010 15:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.523 X-Spam-Level: X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[AWL=0.742, 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 zVGRpjSmRpso for ; Fri, 21 May 2010 15:28:46 -0700 (PDT) Received: from smtp134.dfw.emailsrvr.com (smtp134.dfw.emailsrvr.com [67.192.241.134]) by core3.amsl.com (Postfix) with ESMTP id B902F3A681E for ; Fri, 21 May 2010 15:28:43 -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 7E0413130EB4; Fri, 21 May 2010 18:28:37 -0400 (EDT) Received: by relay13.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 3B2E93130E77; Fri, 21 May 2010 18:28:37 -0400 (EDT) Message-ID: <4BF70916.60700@iwl.com> Date: Fri, 21 May 2010 15:28:38 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <4BF464C3.20800@iwl.com> <20100521.131210.78187880.mbj@tail-f.com> <4BF6734D.3090307@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763E9@EMBX01-HQ.jnpr.net> <4BF6D820.3000209@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763ED@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D763ED@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] rpc-error details 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, 21 May 2010 22:28:47 -0000 Kent Watsen wrote: >> I do not like that approach. >> I would rather see a structured warning >> rather than unspecified vendor-add-ons. >> > > A structured response would be best > > The thing about reporting implicit-changes is: > 1) it must be in the > - notifications didn't work for us > why not? > 2) it's only applicable to , , and > - it's not applicable to most RPCs > it's up to the RPC. It certainly applies to validate. Maybe delete-config as well. I think Martin changed my mind. I don't think 'implicit-change' is really needed in the standard. It seems very specific to 1 implementation. Another solution completely is the '-Werror' approach. Add a flag to edit-config and to validate to elevate warnings to errors. > > > Thanks, > Kent > > > Andy From andyb@iwl.com Fri May 21 15:38: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 AEC2A3A6A27 for ; Fri, 21 May 2010 15:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.593 X-Spam-Level: X-Spam-Status: No, score=-1.593 tagged_above=-999 required=5 tests=[AWL=-0.594, 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 sP1nm2u1IreX for ; Fri, 21 May 2010 15:38:13 -0700 (PDT) Received: from smtp184.iad.emailsrvr.com (smtp184.iad.emailsrvr.com [207.97.245.184]) by core3.amsl.com (Postfix) with ESMTP id BA5723A69C0 for ; Fri, 21 May 2010 15:38:13 -0700 (PDT) Received: from relay28.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay28.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 9913F1B4A64; Fri, 21 May 2010 14:59:44 -0400 (EDT) Received: by relay28.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 378051B4A55; Fri, 21 May 2010 14:59:44 -0400 (EDT) Message-ID: <4BF6D820.3000209@iwl.com> Date: Fri, 21 May 2010 11:59:44 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <4BF464C3.20800@iwl.com> <20100521.131210.78187880.mbj@tail-f.com> <4BF6734D.3090307@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763E9@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36C7D763E9@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] rpc-error details 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, 21 May 2010 22:38:14 -0000 Kent Watsen wrote: >> Of course the client would have to check the error-severity >> field to see if the response is an error or a warning. >> That is what the WG intended when it was written, >> Other than that, why is this a problem? >> Only a base:1.1 session would be allowed to use it. >> >> By definition, warnings are fuzzy and even implementation-specific. >> Maybe we should remove error-severity since it is just >> wasting space in the PDU. >> > > Please don't drop it, unless there is another way for a server to notify the client about implicit-changes - maybe allow app-specific fields with an ? > > > I do not like that approach. I would rather see a structured warning rather than unspecified vendor-add-ons. > >> -1 for me. >> The procedures for this complicated mess are not written down, >> and the WG doesn't agree on the, or even the need for this >> entire 'solution'. For example, a simple notification would >> be good enough, for sessions that actually cared about this condition. >> > > -1 for me too; I agree with Andy's assessment > IMO, the notification solution was dismissed too early. "What if the client is not listening for system events?" Then the client doesn't care about system events. A capability change is simply a system event. It cannot classified as dangerous or irrelevant without considering the application context. Only the application can decide that. The server's job is simply to notify the client. > > > >>>> 3) Change 'error-app-tag' from maxOccurs=1 to maxOccurs=unbounded >>>> >>>> Sometimes the standard modules require a particular error-app-tag. >>>> Sometimes the YANG module has an error-app-tag specified by the >>>> YANG author. Sometimes vendors hardwire their own error-app-tag >>>> to support their own applications. >>>> >>>> [Default: do not change] >>>> > > I'm for sticking with the default. I don't see a good use case for needing more than one error-app-tag per element... > > > > >>> I would not mind this change. It _can_ be achieved by sending >>> multiple rpc-errors, but if you want to support mulitple langauges, >>> this change would be a better solution, since it is clear that each >>> error-message describes the same error. >>> > > Do you have another example? I'm not comfortable with this example as I believe there are better ways to support internationalization > > yes -- we can push the entire problem onto the application. that is a reasonable solution. > Thanks, > Kent > > > From kwatsen@juniper.net Mon May 24 12:04: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 D43AD3A6781 for ; Mon, 24 May 2010 12:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.585 X-Spam-Level: X-Spam-Status: No, score=-4.585 tagged_above=-999 required=5 tests=[AWL=-0.586, 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 iEqAArwfs9oY for ; Mon, 24 May 2010 12:04:34 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 96FF73A6D5A for ; Mon, 24 May 2010 12:04:34 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKS/rNtyNRvcuXe6bb4Yr+oE6SPPfDvJek@postini.com; Mon, 24 May 2010 12:04:27 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 24 May 2010 12:02:09 -0700 From: Kent Watsen To: "'andyb@iwl.com'" Date: Mon, 24 May 2010 12:02:07 -0700 Thread-Topic: [Netconf] rpc-error details Thread-Index: Acr5NPYqucgvsQBdSVyMcDjQZWE8EgCNT1oQ Message-ID: <84600D05C20FF943918238042D7670FD36CAB1B436@EMBX01-HQ.jnpr.net> References: <4BF464C3.20800@iwl.com> <20100521.131210.78187880.mbj@tail-f.com> <4BF6734D.3090307@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763E9@EMBX01-HQ.jnpr.net> <4BF6D820.3000209@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763ED@EMBX01-HQ.jnpr.net> <4BF70916.60700@iwl.com> In-Reply-To: <4BF70916.60700@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] rpc-error details X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 19:04:35 -0000 > > The thing about reporting implicit-changes is: > > 1) it must be in the > > - notifications didn't work for us >=20 > why not? For one, notifications may get dropped - logging is a best-effort service o= n most devices. But, more importantly, because the logic the client needs = to implements is something: / if then changes It needs to be in the as it's critical we associate any implicit-cha= nges with the application-level operation that caused them. If we don't im= port implicit-changes, then the application won't be in sync. We could alw= ays do a full import (i.e. with no filters) after every update= , but that is a very expensive operation just to test if there were any imp= licit-changes. Besides, it's intuitive to us that implicit-change notifica= tion would be in the rpc-reply; it really seems a natural fit for the proto= col. It doesn't seem to be as intuitive for it to be notification/syslog; = how many APIs return warnings out-of-band? > > 2) it's only applicable to , , and > > - it's not applicable to most RPCs > > >=20 > it's up to the RPC. It certainly applies to validate. > Maybe delete-config as well. I don't think or could generate an implicit-chan= ge. is read-only and is on the entire datastore= . But where implicit-changes are applicable is not too important, so long = as we agree that reporting them in them in is the right thing t= o do ;) > I think Martin changed my mind I searched Martin's responses, but I can't locate what it is he may have sa= id to change your mind. He mentioned that how to process warnings would ha= ve to be documented - I thought you correctly responded "why is this a prob= lem?" > I don't think 'implicit-change' is really needed > in the standard. It seems very specific to > 1 implementation. I may be the only ones mentioning it on the WG list, but the real question = is if the WG can/should define a mechanism for warnings. I've already iden= tified one use-case, maybe there are others yet to be identified? How abou= t letting a "trim" server warning that it trimmed some defaults values from= the datastore? > Another solution completely is the '-Werror' approach. > Add a flag to edit-config and to validate > to elevate warnings to errors. I don't understand this suggestion. We don't want implicit-changes to gene= rate an error. They occur under normal operation, we just need to be notif= ied when they do... Thanks, Kent From andyb@iwl.com Mon May 24 12:32: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 4DB183A7070 for ; Mon, 24 May 2010 12:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.233 X-Spam-Level: X-Spam-Status: No, score=-0.233 tagged_above=-999 required=5 tests=[AWL=-0.568, 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 mkQMUXtsRktN for ; Mon, 24 May 2010 12:32:46 -0700 (PDT) Received: from smtp174.dfw.emailsrvr.com (smtp174.dfw.emailsrvr.com [67.192.241.174]) by core3.amsl.com (Postfix) with ESMTP id 545B73A7163 for ; Mon, 24 May 2010 12:31:12 -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 E0EB72C72840; Mon, 24 May 2010 15:31:02 -0400 (EDT) Received: by relay17.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 4C84D2C7252F; Mon, 24 May 2010 15:31:02 -0400 (EDT) Message-ID: <4BFAD3E9.6040105@iwl.com> Date: Mon, 24 May 2010 12:30:49 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <4BF464C3.20800@iwl.com> <20100521.131210.78187880.mbj@tail-f.com> <4BF6734D.3090307@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763E9@EMBX01-HQ.jnpr.net> <4BF6D820.3000209@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763ED@EMBX01-HQ.jnpr.net> <4BF70916.60700@iwl.com> <84600D05C20FF943918238042D7670FD36CAB1B436@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36CAB1B436@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] rpc-error details 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, 24 May 2010 19:32:47 -0000 Kent Watsen wrote: > >>> The thing about reporting implicit-changes is: >>> 1) it must be in the >>> - notifications didn't work for us >>> >> why not? >> > > For one, notifications may get dropped - logging is a best-effort service on most devices. But, more importantly, because the logic the client needs to implements is something: > > We use TCP. It is an implementation detail as to how the application treats a NETCONF message once it is delivered. > > / > if then changes > > > It needs to be in the as it's critical we associate any implicit-changes with the application-level operation that caused them. If we don't import implicit-changes, then the application won't be in sync. We could always do a full import (i.e. with no filters) after every update, but that is a very expensive operation just to test if there were any implicit-changes. Besides, it's intuitive to us that implicit-change notification would be in the rpc-reply; it really seems a natural fit for the protocol. It doesn't seem to be as intuitive for it to be notification/syslog; how many APIs return warnings out-of-band? > > > I still do not understand what an implicit change is within the NETCONF standard. That has not been explained. I am not going to discuss the solution details when I do not agree there is a problem to be solved. The client is 100% responsible for what it puts in a NETCONF message. Period. There are several ways for a client to validate input. Everything the client does is explicit. Phil once argued that we don't need warnings because we cannot rely on them. If the problem is that important, make it an error. Use -Werror if you care about warnings. I agree with this POV, especially for proprietary warnings. > >>> 2) it's only applicable to , , and >>> - it's not applicable to most RPCs >>> >>> >> it's up to the RPC. It certainly applies to validate. >> Maybe delete-config as well. >> > > I don't think or could generate an implicit-change. is read-only and is on the entire datastore. But where implicit-changes are applicable is not too important, so long as we agree that reporting them in them in is the right thing to do ;) > > > > >> I think Martin changed my mind >> > > I searched Martin's responses, but I can't locate what it is he may have said to change your mind. He mentioned that how to process warnings would have to be documented - I thought you correctly responded "why is this a problem?" > We have entrenched logic in NETCONF: " or ", but not both. I do not see a compelling reason to change that in the standard. I forgot about that aspect of the NETCONF XSD. So my original proposal is broken. It would only work for operations that return data, because data and can be combined in the rpc-reply. > > > >> I don't think 'implicit-change' is really needed >> in the standard. It seems very specific to >> 1 implementation. >> > > I may be the only ones mentioning it on the WG list, but the real question is if the WG can/should define a mechanism for warnings. I've already identified one use-case, maybe there are others yet to be identified? How about letting a "trim" server warning that it trimmed some defaults values from the datastore? > > > > >> Another solution completely is the '-Werror' approach. >> Add a flag to edit-config and to validate >> to elevate warnings to errors. >> > > I don't understand this suggestion. We don't want implicit-changes to generate an error. They occur under normal operation, we just need to be notified when they do... > If they are normal, then why are they warnings? > > Thanks, > Kent > > > Andy From andyb@iwl.com Mon May 24 12:47: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 B92393A6A1A for ; Mon, 24 May 2010 12:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.526 X-Spam-Level: X-Spam-Status: No, score=-1.526 tagged_above=-999 required=5 tests=[AWL=0.739, 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 gutpLJ+RF9D5 for ; Mon, 24 May 2010 12:47:18 -0700 (PDT) Received: from smtp174.dfw.emailsrvr.com (smtp174.dfw.emailsrvr.com [67.192.241.174]) by core3.amsl.com (Postfix) with ESMTP id 061043A67A3 for ; Mon, 24 May 2010 12:47:17 -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 37ED92C70396; Mon, 24 May 2010 15:47:09 -0400 (EDT) Received: by relay17.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id CEEC92C704B8; Mon, 24 May 2010 15:47:08 -0400 (EDT) Message-ID: <4BFAD7AF.9080003@iwl.com> Date: Mon, 24 May 2010 12:46:55 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <4BF464C3.20800@iwl.com> <20100521.131210.78187880.mbj@tail-f.com> <4BF6734D.3090307@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763E9@EMBX01-HQ.jnpr.net> <4BF6D820.3000209@iwl.com> <84600D05C20FF943918238042D7670FD36C7D763ED@EMBX01-HQ.jnpr.net> <4BF70916.60700@iwl.com> <84600D05C20FF943918238042D7670FD36CAB1B436@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36CAB1B436@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] rpc-error details 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, 24 May 2010 19:47:19 -0000 Kent Watsen wrote: If you want proprietary warnings for edit-config, commit, etc., you can use YANG legally to do it: module my-warnings { ... import ietf-netconf { prefix nc; } grouping warning-group { list warning { ... // clone rpc-error info } } augment /nc:edit-config/nc:output { uses warning-group; } augment /nc:commit/nc:output { uses warning-group; } augment /nc:copy-config/nc:output { uses warning-group; } } This is legal NETCONF and YANG so all clients MUST accept it. > > Thanks, > Kent > > > Andy From bertietf@bwijnen.net Wed May 26 00:21: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 926E23A6861 for ; Wed, 26 May 2010 00:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 rYHAmiPkVA4T for ; Wed, 26 May 2010 00:21:06 -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 ED1243A68AD for ; Wed, 26 May 2010 00:20:59 -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 1OHAux-000291-KW for netconf@ietf.org; Wed, 26 May 2010 09:20:49 +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 1OHAux-0004QR-Fu for netconf@ietf.org; Wed, 26 May 2010 09:20:43 +0200 Message-ID: <4BFCCBCB.8020109@bwijnen.net> Date: Wed, 26 May 2010 09:20:43 +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: 86ab03e524994f79ca2c75a176445dd45bec6e856403d92df8fcd80a34de4f7a X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd45bec6e856403d92df8fcd80a34de4f7a Subject: [Netconf] WG Last Call for daft-ietf-netconf-with-defaults-08. Please review BEFORE June 6th, 2010 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 26 May 2010 07:21:07 -0000 WG participants, This is a(nother) formal WG Last Call for this this document. Please review and comment BEFORE June 6th 2010. We did have a pretty extensive discussion on various topics with the previous WG Last Call. It seems however that we did come to (at least rough) consensus on the issues that were raised. As a result, Andy has posted revision 8. The changes since the last rev are: Added report-all-tagged mode. Changed conformance so report-all or report-all-tagged mode SHOULD be supported. Clarified capability requirements for each mode, for edit-config and NV storage requirements. Changed rpc-error details for unsupported with-defaults value. Added XSD for wd:default attribute Expanded example to show report-all-tagged for a basic-mode=trim server. For direct pointers to the document and diffs etc, see: http://tools.ietf.org/wg/netconf/draft-ietf-netconf-with-defaults/ There was also some discussion on merging all or part of the with-defaults into the 4741bis document. However, we (WG chairs) do not believe that we should explore that path this late in the process. Besides, we certainly did not see a WG consensus to do so. Bert and Mehmet -------- Original Message -------- Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-08.txt Date: Thu, 20 May 2010 13:15:02 -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-08.txt Pages : 30 Date : 2010-05-20 The NETCONF protocol defines ways to read and edit configuration data from a NETCONF server. Part of this data may not be set by the NETCONF client, but rather a default value is used. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to 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 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-with-defaults-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From root@core3.amsl.com Wed May 26 09:15:21 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 1311D3A68FE; Wed, 26 May 2010 09: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: <20100526161513.1311D3A68FE@core3.amsl.com> Date: Wed, 26 May 2010 09:15:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] 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: Wed, 26 May 2010 16:15:22 -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-13.txt Pages : 40 Date : 2010-05-26 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-13.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-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-26090112.I-D@ietf.org> --NextPart-- From mark.scott@ericsson.com Wed May 26 09:53: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 9044B3A68BB for ; Wed, 26 May 2010 09:53:09 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body 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 vYchj1L-h7uW for ; Wed, 26 May 2010 09:53:08 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 8A7513A67B2 for ; Wed, 26 May 2010 09:53:08 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o4QGqwJ5011228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 May 2010 11:52:59 -0500 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.126]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 26 May 2010 12:52:58 -0400 From: Mark Scott To: "netconf@ietf.org" Date: Wed, 26 May 2010 12:52:56 -0400 Thread-Topic: [Netconf] I-D Action:draft-ietf-netconf-monitoring-13.txt Thread-Index: Acr87wpvADidMvEKTx2XGNB8HuNcQgAA1p0Q Message-ID: <75C89D709A9670428520E1CF8DD1344F208D0F317B@EUSAACMS0714.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_003_75C89D709A9670428520E1CF8DD1344F208D0F317BEUSAACMS0714e_" MIME-Version: 1.0 Subject: [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: Wed, 26 May 2010 16:53:09 -0000 --_003_75C89D709A9670428520E1CF8DD1344F208D0F317BEUSAACMS0714e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, A new version (v13) of the "YANG Module for NETCONF Monitoring" draft has b= een posted. This addresses comments received on v12 during WGLC, AD and Gen-Art reviews= . In addition some further changes were worked in a smaller group (which incl= uded WG chairs). The noteworthy changes being: 1. Sec 6, Security Considerations a. new security text template (rev4) as agreed by WG b. 'username' identified as sensitive data 2. 'username' description updated to specify the standard value for SSH tra= nsport (i.e. the mandatory NETCONF transport). For the optional transports= the derivation remains implementation specific. 3. Yang module updates: a. added Martin to list of contacts b. prefix changed to 'ncm' (netconf monitoring); better reflects the mod= ule name c. fixed double reference statement bug in yin identity d. added presence statement to locks container e. name changed from container to leaf node f. name key added for datastores list g. added typedef sessionid-or-zero h. additional mandatory nodes added (username, locked-time, namespace) i. additional descriptions added j. leaf locked-by-session type changed to session-id-or-zero 4. updated IANA considerations: a. "Yang Module Names" registry reference added for module registration b. 'rfcxxx' removed from module namespace per (netmod) consensus to drop = that guideline Please refer to the Change Log (Appendix A) for details on all changes. cheers, Mark -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Internet-Drafts@ietf.org Sent: May-26-10 12:15 PM To: i-d-announce@ietf.org Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-13.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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-13.txt Pages : 40 Date : 2010-05-26 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-13.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. --_003_75C89D709A9670428520E1CF8DD1344F208D0F317BEUSAACMS0714e_ Content-Type: message/external-body; name="draft-ietf-netconf-monitoring-13.txt" Content-Description: draft-ietf-netconf-monitoring-13.txt Content-Disposition: attachment; filename="draft-ietf-netconf-monitoring-13.txt"; size=231; creation-date="Wed, 26 May 2010 12:18:13 GMT"; modification-date="Wed, 26 May 2010 12:18:13 GMT" Content-Transfer-Encoding: base64 RklMRSBRVUFSQU5USU5FRA0KDQpNaWNyb3NvZnQgRm9yZWZyb250IFNlY3VyaXR5IGZvciBFeGNo YW5nZSBTZXJ2ZXIgcmVtb3ZlZCBhIGZpbGUgc2luY2UgaXQgd2FzIGZvdW5kIHRvIG1hdGNoIGEg ZmlsdGVyLg0KRmlsZSBuYW1lOiAid2lubWFpbC5kYXQtPmRyYWZ0LWlldGYtbmV0Y29uZi1tb25p dG9yaW5nLTEzLnVybCINCkZpbHRlciBuYW1lOiAiRklMRSBGSUxURVI9IHVubmFtZWQ6ICoudXJs Ig0K --_003_75C89D709A9670428520E1CF8DD1344F208D0F317BEUSAACMS0714e_ Content-Type: text/plain; name="ATT00001..txt" Content-Description: ATT00001..txt Content-Disposition: attachment; filename="ATT00001..txt"; size=136; creation-date="Wed, 26 May 2010 12:18:13 GMT"; modification-date="Wed, 26 May 2010 12:18:13 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYg bWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmYNCg== --_003_75C89D709A9670428520E1CF8DD1344F208D0F317BEUSAACMS0714e_-- From andyb@iwl.com Wed May 26 10:19:13 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E74943A681E for ; Wed, 26 May 2010 10:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLTViDhSdJwe for ; Wed, 26 May 2010 10:19:12 -0700 (PDT) Received: from smtp114.iad.emailsrvr.com (smtp114.iad.emailsrvr.com [207.97.245.114]) by core3.amsl.com (Postfix) with ESMTP id 18A463A6925 for ; Wed, 26 May 2010 10:18:45 -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 290F444C0E5; Wed, 26 May 2010 13:18:36 -0400 (EDT) Received: by relay1.r1.iad.emailsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id AC94044C0B8; Wed, 26 May 2010 13:18:35 -0400 (EDT) Message-ID: <4BFD57EA.8010103@iwl.com> Date: Wed, 26 May 2010 10:18:34 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Mark Scott References: <75C89D709A9670428520E1CF8DD1344F208D0F317B@EUSAACMS0714.eamcs.ericsson.se> In-Reply-To: <75C89D709A9670428520E1CF8DD1344F208D0F317B@EUSAACMS0714.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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, 26 May 2010 17:19:14 -0000 Mark Scott wrote: > Hello, > > A new version (v13) of the "YANG Module for NETCONF Monitoring" draft has been posted. > > This addresses comments received on v12 during WGLC, AD and Gen-Art reviews. > > I do not remember a public discussion and resolution that led to changing the datastore name from a container to a leaf. Since a client has to support this container-of-empty-leaf all over NETCONF, it doesn't really help to fix it here. I do not strongly object, but this is a big change so late in the process. I do not understand why this document is defining the NETCONF session-id and session-id-or-zero typedefs. The ietf-netconf module is defining session-id-type and session-id-or-zero-type. There is no way 4741bis is going to incur a normative reference to this RFC for some out-of-place typedef. That means 2 sets of typedefs going forward. Quite lame. Andy > In addition some further changes were worked in a smaller group (which included WG chairs). The noteworthy changes being: > > 1. Sec 6, Security Considerations > a. new security text template (rev4) as agreed by WG > b. 'username' identified as sensitive data > 2. 'username' description updated to specify the standard value for SSH transport (i.e. the mandatory NETCONF transport). For the optional transports the derivation remains implementation specific. > 3. Yang module updates: > a. added Martin to list of contacts > b. prefix changed to 'ncm' (netconf monitoring); better reflects the module name > c. fixed double reference statement bug in yin identity > d. added presence statement to locks container > e. name changed from container to leaf node > f. name key added for datastores list > g. added typedef sessionid-or-zero > h. additional mandatory nodes added (username, locked-time, namespace) > i. additional descriptions added > j. leaf locked-by-session type changed to session-id-or-zero > 4. updated IANA considerations: > a. "Yang Module Names" registry reference added for module registration > b. 'rfcxxx' removed from module namespace per (netmod) consensus to drop that guideline > > Please refer to the Change Log (Appendix A) for details on all changes. > > cheers, > Mark > > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org > Sent: May-26-10 12:15 PM > To: i-d-announce@ietf.org > Cc: netconf@ietf.org > Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-13.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Configuration Working Group of the IETF. > > > Title : YANG Module for NETCONF Monitoring > Author(s) : M. Scott, M. Bjorklund > Filename : draft-ietf-netconf-monitoring-13.txt > Pages : 40 > Date : 2010-05-26 > > 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-13.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 May 26 10: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 8D8DF3A67A6 for ; Wed, 26 May 2010 10:29:49 -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 y6vbXIK4nKNI for ; Wed, 26 May 2010 10:29:48 -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 9118D3A6994 for ; Wed, 26 May 2010 10:29:47 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 73890616002; Wed, 26 May 2010 19:29:37 +0200 (CEST) Date: Wed, 26 May 2010 19:29:36 +0200 (CEST) Message-Id: <20100526.192936.236301148.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4BFD57EA.8010103@iwl.com> References: <75C89D709A9670428520E1CF8DD1344F208D0F317B@EUSAACMS0714.eamcs.ericsson.se> <4BFD57EA.8010103@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] 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: Wed, 26 May 2010 17:29:49 -0000 Hi, Andy Bierman wrote: > I do not remember a public discussion and resolution that led > to changing the datastore name from a container to a leaf. > Since a client has to support this container-of-empty-leaf > all over NETCONF, it doesn't really help to fix it here. > I do not strongly object, but this is a big change so > late in the process. I think this is different from the other places, since this is in a (non-config) data model, and the other places are rpc input params. By using a leaf we can make it a key, which directly defines that the name identifies an entry in this list. This was not clear in the previous version. This is also the way we want new data models to look like, and it plays well with subtree filtering too (no, I do not want to re-start the deep keys discussion here :) > I do not understand why this document is defining the > NETCONF session-id and session-id-or-zero typedefs. The only reason is to avoid a normative reference to 4741bis. /martin From andyb@iwl.com Wed May 26 11:03: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 146963A680C for ; Wed, 26 May 2010 11:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-1.300, 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 Yu2lV9lAxmYr for ; Wed, 26 May 2010 11:03:42 -0700 (PDT) Received: from smtp164.iad.emailsrvr.com (smtp164.iad.emailsrvr.com [207.97.245.164]) by core3.amsl.com (Postfix) with ESMTP id 148E63A67AD for ; Wed, 26 May 2010 11:03:42 -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 B126E16D00A; Wed, 26 May 2010 14:03:32 -0400 (EDT) Received: by relay6.relay.iad.emailsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 4F06316CFCF; Wed, 26 May 2010 14:03:32 -0400 (EDT) Message-ID: <4BFD6273.6050304@iwl.com> Date: Wed, 26 May 2010 11:03:31 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Bjorklund References: <75C89D709A9670428520E1CF8DD1344F208D0F317B@EUSAACMS0714.eamcs.ericsson.se> <4BFD57EA.8010103@iwl.com> <20100526.192936.236301148.mbj@tail-f.com> In-Reply-To: <20100526.192936.236301148.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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, 26 May 2010 18:03:43 -0000 Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: > >> I do not remember a public discussion and resolution that led >> to changing the datastore name from a container to a leaf. >> Since a client has to support this container-of-empty-leaf >> all over NETCONF, it doesn't really help to fix it here. >> I do not strongly object, but this is a big change so >> late in the process. >> > > I think this is different from the other places, since this is in a > (non-config) data model, and the other places are rpc input params. > By using a leaf we can make it a key, which directly defines that the > name identifies an entry in this list. This was not clear in the > previous version. This is also the way we want new data models to > look like, and it plays well with subtree filtering too (no, I do not > want to re-start the deep keys discussion here :) > > It is OK -- should have figured that out in draft-02, though. I wish all of NETCONF used an enumeration instead of what we have now, e.g.: choice config-target { mandatory true; leaf database { type netconf-datastore-type; } leaf url { type inet:uri; } } Semantically, this is much cleaner, not just simpler syntax. Too late for that I guess. >> I do not understand why this document is defining the >> NETCONF session-id and session-id-or-zero typedefs. >> > > The only reason is to avoid a normative reference to 4741bis. > > I figured that out. But solving this artificial IETF-process-related problem introduces long-term confusion and duplication. IMO it would be better to think about how these YANG modules will be used during their expected lifetime, rather than worry about the 6 week to 6 month time frame for avoiding normative references. 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. > /martin > > Andy From mehmet.ersue@nsn.com Thu May 27 09:37: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 9CCB43A698D for ; Thu, 27 May 2010 09:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[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 pCo2LlPnymn8 for ; Thu, 27 May 2010 09:37:18 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 1F52B3A6819 for ; Thu, 27 May 2010 09:37:17 -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 o4RGb2ar007941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 May 2010 18:37:02 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o4RGb1GX026818; Thu, 27 May 2010 18:37:01 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 May 2010 18:37:01 +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, 27 May 2010 18:37:00 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A648E3E8C@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Approval for the Monitoring draft before we go to IESG Chat Thread-Index: Acr9utSsavXkD+5oQIyvffL0+QmQqQ== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "NETCONF WG" , "ext Romascanu, Dan (Dan)" X-OriginalArrivalTime: 27 May 2010 16:37:01.0708 (UTC) FILETIME=[D541BCC0:01CAFDBA] Subject: [Netconf] WG Approval for the Monitoring draft before we go to IESG Chat X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 16:37:19 -0000 Dear NETCONF WG, the Monitoring draft was in AD review and IETF LC.=20 Mark and Martin updated it as v13 after some changes=20 and bug fixes (please see the mail below and Change=20 Log of the draft). V13 of the Monitoring draft is available at:=20 http://tools.ietf.org/html/draft-ietf-netconf-monitoring-13 The co-chairs and the authors of the Monitoring draft=20 think that the update addresses all known issues and=20 should be brought to IESG chat. If there are no objections by June 1, 2010, I will ask our=20 AD Dan Romascanu to consider to bring the draft to the=20 next step.=20 Thank you all who contributed to the development of=20 the Monitoring draft. Cheers, Mehmet (Document shepherd) -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Mark Scott Sent: Wednesday, May 26, 2010 6:53 PM To: netconf@ietf.org Subject: [Netconf] FW: I-D Action:draft-ietf-netconf-monitoring-13.txt Hello, A new version (v13) of the "YANG Module for NETCONF Monitoring" draft has been posted. This addresses comments received on v12 during WGLC, AD and Gen-Art reviews. In addition some further changes were worked in a smaller group (which included WG chairs). The noteworthy changes being: 1. Sec 6, Security Considerations a. new security text template (rev4) as agreed by WG b. 'username' identified as sensitive data 2. 'username' description updated to specify the standard value for SSH transport (i.e. the mandatory NETCONF transport). For the optional transports the derivation remains implementation specific. 3. Yang module updates: a. added Martin to list of contacts b. prefix changed to 'ncm' (netconf monitoring); better reflects the module name c. fixed double reference statement bug in yin identity d. added presence statement to locks container e. name changed from container to leaf node f. name key added for datastores list g. added typedef sessionid-or-zero h. additional mandatory nodes added (username, locked-time, namespace) i. additional descriptions added j. leaf locked-by-session type changed to session-id-or-zero 4. updated IANA considerations: a. "Yang Module Names" registry reference added for module registration b. 'rfcxxx' removed from module namespace per (netmod) consensus to drop that guideline Please refer to the Change Log (Appendix A) for details on all changes. cheers, Mark -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: May-26-10 12:15 PM To: i-d-announce@ietf.org Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-13.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : YANG Module for NETCONF Monitoring Author(s) : M. Scott, M. Bjorklund Filename : draft-ietf-netconf-monitoring-13.txt Pages : 40 Date : 2010-05-26 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-13.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. From kwatsen@juniper.net Thu May 27 10:30:13 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9503A6908 for ; Thu, 27 May 2010 10:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J30a+RIHv2QV for ; Thu, 27 May 2010 10:30:12 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id D7E733A6929 for ; Thu, 27 May 2010 10:30:11 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKS/6sGCQ4StatTJeewJl0zeawFcdI85+4@postini.com; Thu, 27 May 2010 10:30:03 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 27 May 2010 10:24:38 -0700 From: Kent Watsen To: "'Bert (IETF) Wijnen'" , netconf Date: Thu, 27 May 2010 10:24:37 -0700 Thread-Topic: [Netconf] WG Last Call for daft-ietf-netconf-with-defaults-08. Please review BEFORE June 6th, 2010 Thread-Index: Acr8pB3PjBt+fcivTxeebKB9eTJDSwBDLfow Message-ID: <84600D05C20FF943918238042D7670FD36CAB1B44D@EMBX01-HQ.jnpr.net> References: <4BFCCBCB.8020109@bwijnen.net> In-Reply-To: <4BFCCBCB.8020109@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] WG Last Call for daft-ietf-netconf-with-defaults-08. Please review BEFORE June 6th, 2010 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 27 May 2010 17:30:13 -0000 1) Sections 2.2.3 and 2.3.3 describe report-all-tagged behavior for 'trim' = and 'explicit' servers respectively. On the mailing list it was suggested = that a 'report-all' server could also-support 'report-all-tagged', should w= e add a similar section to 2.1.3? 2) Typo in section 3.1, "it is present within configuration input"? 3) Clean up text in section 4.1, change from "The :with-defaults capability indicates that the NETCONF server supports a specific defaults handling basic mode" to maybe "The :with-defaults capability indicates which defaults handling basic mode the NETCONF server supports" 4) in section 4.4, remove the line return between the first and second sent= ences 5) in section 4.4, in the first sentence, s/will treat/treats/ 6) in section 4.4, the paragraph that begins with the word "Note" implies t= hat the message will need to contain two lines: urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=3Dexplici= t urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults&revision=3D2010-05= -19 is this really necessary? 7) in section 4.6.1, it says "Allowed values of the with-defaults element a= re taken from the list in Section 2", but section 2 doesn't include report-= all-tagged, s/section 2/section 3/? 8) in section 4.6.2, it says "If the wd:default attribute is present and se= t to 'true', then the server MUST treat the new data node as a request to r= eturn that node to its default value (i.e., remove it from the database)." = I liked the text from section 2.2.3 better, as it also asserts that the va= lue MUST be the same as the schema default value. 9 In section A.3.2, it says "Any subtrees within the element are also consi= dered to be tagged as dafault data". While I agree with the statement, it = probably should be specified in section 3.1 10) In section A.3.2, it says "The actual data nodes tagged by the server d= epends on the defaults handling basic mode used by the server" and "If the = server's basic mode is 'report-all', then no data nodes are tagged." I dis= agree, I think that a "report-all" server that also-supports "report-all-ta= gged" should tag its defaults, if "report-all-tagged" is requested by the c= lient. Thanks, Kent > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behal= f > Of Bert (IETF) Wijnen > Sent: Wednesday, May 26, 2010 3:21 AM > To: netconf > Subject: [Netconf] WG Last Call for daft-ietf-netconf-with-defaults-08. > Please review BEFORE June 6th, 2010 >=20 > WG participants, >=20 > This is a(nother) formal WG Last Call for this this document. > Please review and comment BEFORE June 6th 2010. >=20 > We did have a pretty extensive discussion on various > topics with the previous WG Last Call. It seems however that we did > come to (at least rough) consensus on the issues that were raised. > As a result, Andy has posted revision 8. The changes since the > last rev are: >=20 >=20 > Added report-all-tagged mode. >=20 > Changed conformance so report-all or report-all-tagged mode SHOULD be > supported. >=20 > Clarified capability requirements for each mode, for edit-config and > NV storage requirements. >=20 > Changed rpc-error details for unsupported with-defaults value. >=20 > Added XSD for wd:default attribute >=20 > Expanded example to show report-all-tagged for a basic-mode=3Dtrim > server. >=20 > For direct pointers to the document and diffs etc, see: > http://tools.ietf.org/wg/netconf/draft-ietf-netconf-with-defaults/ >=20 >=20 > There was also some discussion on merging all or part of the with-default= s > into the 4741bis document. However, we (WG chairs) do not believe that we > should explore that path this late in the process. Besides, we certainly > did not see a WG consensus to do so. >=20 > Bert and Mehmet >=20 > -------- Original Message -------- > Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-08.txt > Date: Thu, 20 May 2010 13:15:02 -0700 (PDT) > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > CC: netconf@ietf.org >=20 >=20 >=20 > 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. >=20 >=20 > Title : With-defaults capability for NETCONF > Author(s) : A. Bierman, B. Lengyel > Filename : draft-ietf-netconf-with-defaults-08.txt > Pages : 30 > Date : 2010-05-20 >=20 > The NETCONF protocol defines ways to read and edit configuration data > from a NETCONF server. Part of this data may not be set by the > NETCONF client, but rather a default value is used. In many > situations the NETCONF client has a priori knowledge about default > data, so the NETCONF server does not need to 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 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. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-with-defaults- > 08.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From andyb@iwl.com Thu May 27 11:21: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 29EEA3A684A for ; Thu, 27 May 2010 11:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.601 X-Spam-Level: ** X-Spam-Status: No, score=2.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_27=0.6, SARE_OBFU_PART_ONE=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO3jpzPx9aFD for ; Thu, 27 May 2010 11:21:55 -0700 (PDT) Received: from smtp164.dfw.emailsrvr.com (smtp164.dfw.emailsrvr.com [67.192.241.164]) by core3.amsl.com (Postfix) with ESMTP id 7036D3A67ED for ; Thu, 27 May 2010 11:21:54 -0700 (PDT) Received: from relay6.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay6.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 1138530735; Thu, 27 May 2010 14:21:45 -0400 (EDT) Received: by relay6.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id BE3F1301B9; Thu, 27 May 2010 14:21:44 -0400 (EDT) Message-ID: <4BFEB835.2050200@iwl.com> Date: Thu, 27 May 2010 11:21:41 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <4BFCCBCB.8020109@bwijnen.net> <84600D05C20FF943918238042D7670FD36CAB1B44D@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36CAB1B44D@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf Subject: Re: [Netconf] WG Last Call for daft-ietf-netconf-with-defaults-08. Please review BEFORE June 6th, 2010 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, 27 May 2010 18:21:56 -0000 Kent Watsen wrote: > 1) Sections 2.2.3 and 2.3.3 describe report-all-tagged behavior for > 'trim' and 'explicit' servers respectively. On the mailing list it > was suggested that a 'report-all' server could also-support > 'report-all-tagged', should we add a similar section to 2.1.3? > We could add a sentence explaining that nothing would ever be tagged if basic-mode=report-all. There is no difference between a basic=report-all and with-defaults=report-all-tagged reply. .... > 6) in section 4.4, the paragraph that begins with the word "Note" > implies that the message will need to contain two lines: > > urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=explicit > > urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults&revision=2010-05-19 > > > is this really necessary? Yes. The YANG RFC specifies that a server supporting the ietf0netconf-with-defaults module MUST advertise a module capability. That is what this 2nd URI represents. I think this section makes that point clear. The YANG module URI is an awesome tool that exists on its own, separate from the defaults modes supported. It allows the client app to re-create the server object tree on-the-fly, instead of using trial-and-error + a data silo. > > 7) in section 4.6.1, it says "Allowed values of the with-defaults > element are taken from the list in Section 2", but section 2 doesn't > include report-all-tagged, s/section 2/section 3/? OK > > 8) in section 4.6.2, it says "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)." I liked the text from section 2.2.3 better, as > it also asserts that the value MUST be the same as the schema default > value. OK > > 9 In section A.3.2, it says "Any subtrees within the element are also > considered to be tagged as dafault data". While I agree with the > statement, it probably should be specified in section 3.1 > > 10) In section A.3.2, it says "The actual data nodes tagged by the > server depends on the defaults handling basic mode used by the > server" and "If the server's basic mode is 'report-all', then no data > nodes are tagged." I disagree, I think that a "report-all" server > that also-supports "report-all-tagged" should tag its defaults, if > "report-all-tagged" is requested by the client. A report-all basic-mode server has no concept whatsoever of a default. Nothing will ever be tagged. Every node is considered to exist in the database. Technically, the report-all server is tagging all (zero) of its default nodes. > > > Thanks, Kent Andy From phil@juniper.net Thu May 27 12:37:21 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 314413A6CBC for ; Thu, 27 May 2010 12:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 MpqwIlGXHDiw for ; Thu, 27 May 2010 12:37:20 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id B09973A7009 for ; Thu, 27 May 2010 12:32:24 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKS/7IutGoaSnut0U91gjlPB+ihpobjJjB@postini.com; Thu, 27 May 2010 12:32:16 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; Thu, 27 May 2010 12:30:46 -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); Thu, 27 May 2010 12:30:46 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 May 2010 12:30:45 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 May 2010 12:30: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 o4RJUhD46076; Thu, 27 May 2010 12:30:44 -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 o4RJDF87079745; Thu, 27 May 2010 19:13:15 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005271913.o4RJDF87079745@idle.juniper.net> To: In-Reply-To: <4BFEB835.2050200@iwl.com> Date: Thu, 27 May 2010 15:13:15 -0400 From: Phil Shafer X-OriginalArrivalTime: 27 May 2010 19:30:44.0846 (UTC) FILETIME=[19EE60E0:01CAFDD3] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf Subject: Re: [Netconf] WG Last Call for daft-ietf-netconf-with-defaults-08. Please review BEFORE June 6th, 2010 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 27 May 2010 19:37:21 -0000 Andy Bierman writes: >> urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=explicit >> urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults&revision=2010-05-19 >The YANG module URI is an awesome tool that exists on >its own, separate from the defaults modes supported. It allows >the client app to re-create the server object tree on-the-fly, >instead of using trial-and-error + a data silo. I guess the sad part is that we didn't add this sort of parameter mechanism to YANG, so that one announcement can handle both. This is a scenario that we are likely to hit repeatedly. Thanks, Phil From andyb@iwl.com Thu May 27 12:43: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 726223A6890 for ; Thu, 27 May 2010 12:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.768 X-Spam-Level: * X-Spam-Status: No, score=1.768 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=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 mrBIv-WRJFwK for ; Thu, 27 May 2010 12:43:35 -0700 (PDT) Received: from smtp134.dfw.emailsrvr.com (smtp134.dfw.emailsrvr.com [67.192.241.134]) by core3.amsl.com (Postfix) with ESMTP id C9EBA3A67B6 for ; Thu, 27 May 2010 12:43:35 -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 660A91568A1D; Thu, 27 May 2010 15:43:26 -0400 (EDT) Received: by relay23.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id D63AF1568A16; Thu, 27 May 2010 15:43:25 -0400 (EDT) Message-ID: <4BFECB5A.1080204@iwl.com> Date: Thu, 27 May 2010 12:43:22 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201005271913.o4RJDF87079745@idle.juniper.net> In-Reply-To: <201005271913.o4RJDF87079745@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf Subject: Re: [Netconf] WG Last Call for daft-ietf-netconf-with-defaults-08. Please review BEFORE June 6th, 2010 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, 27 May 2010 19:43:36 -0000 Phil Shafer wrote: > Andy Bierman writes: > >>> urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=explicit >>> urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults&revision=2010-05-19 >>> >> The YANG module URI is an awesome tool that exists on >> its own, separate from the defaults modes supported. It allows >> the client app to re-create the server object tree on-the-fly, >> instead of using trial-and-error + a data silo. >> > > I guess the sad part is that we didn't add this sort of parameter > mechanism to YANG, so that one announcement can handle both. This > is a scenario that we are likely to hit repeatedly. > > I disagree, as I pointed out a couple times already. It is just an implementation detail, which URI string has which parameter. It would be horrible if a client had to first parse foo.yang to find out if the URI parameters advertised for foo.yang were valid. If the client understands the static part of the URI, then it should expect to find a subset of fixed parameters. Arbitrary parameter/value pairs not defined for the capability are not useful to the client. > Thanks, > Phil > > Andy From kwatsen@juniper.net Thu May 27 14:01: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 43DA23A6979 for ; Thu, 27 May 2010 14:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.792 X-Spam-Level: X-Spam-Status: No, score=-3.792 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_40=-0.185, 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 BBT9r7v19qrE for ; Thu, 27 May 2010 14:01:33 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 47A0E3A6940 for ; Thu, 27 May 2010 14:01:33 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKS/7dnI14VZgzVgSkdDnxCEqUSoFWp5xS@postini.com; Thu, 27 May 2010 14:01:24 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 27 May 2010 13:58:15 -0700 From: Kent Watsen To: "'andyb@iwl.com'" Date: Thu, 27 May 2010 13:58:15 -0700 Thread-Topic: [Netconf] WG Last Call for daft-ietf-netconf-with-defaults-08. Please review BEFORE June 6th, 2010 Thread-Index: Acr9yXerCCsHhD0NSFu6PmkCprDYMQACpV3w Message-ID: <84600D05C20FF943918238042D7670FD36CAB1B450@EMBX01-HQ.jnpr.net> References: <4BFCCBCB.8020109@bwijnen.net> <84600D05C20FF943918238042D7670FD36CAB1B44D@EMBX01-HQ.jnpr.net> <4BFEB835.2050200@iwl.com> In-Reply-To: <4BFEB835.2050200@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: netconf Subject: Re: [Netconf] WG Last Call for daft-ietf-netconf-with-defaults-08. Please review BEFORE June 6th, 2010 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 27 May 2010 21:01:35 -0000 > > 10) In section A.3.2, it says "The actual data nodes tagged by the > > server depends on the defaults handling basic mode used by the > > server" and "If the server's basic mode is 'report-all', then no data > > nodes are tagged." I disagree, I think that a "report-all" server > > that also-supports "report-all-tagged" should tag its defaults, if > > "report-all-tagged" is requested by the client. >=20 > A report-all basic-mode server has no concept > whatsoever of a default. Nothing will ever be tagged. > Every node is considered to exist in the database. > Technically, the report-all server is tagging all (zero) of its default > nodes. I don't agree. For instance, even for a report-all server, when the client= creates an interface, it could choose to not specify the MTU parameter, at= which point the server would use the schema-defined default (1500) by copy= ing the value into the datastore. I understand that the server then no lon= ger manages the value as a default, but that doesn't mean it couldn't compa= re the current value to the schema defined value to see if it is, in fact t= he same and mark it as such. IMO, if a report-all server can't do this, th= en it shouldn't advertize supporting "report-all-tagged". BTW, this is how both our SSL/VPN and Universal Access Control products worked for many releases (i.e. report-all). Only recently did th= ey update to support the "trim" behavior, which they were able to do becaus= e, yes, even report-all servers can know what defaults are. Thanks, Kent From andyb@iwl.com Thu May 27 17:13:38 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 BEAE13A696A for ; Thu, 27 May 2010 17:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.052 X-Spam-Level: * X-Spam-Status: No, score=1.052 tagged_above=-999 required=5 tests=[AWL=0.717, 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 kzmEl57w92zO for ; Thu, 27 May 2010 17:13:34 -0700 (PDT) Received: from smtp144.dfw.emailsrvr.com (smtp144.dfw.emailsrvr.com [67.192.241.144]) by core3.amsl.com (Postfix) with ESMTP id 1E7913A67B3 for ; Thu, 27 May 2010 17:13:34 -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 592D134E8786; Thu, 27 May 2010 20:13:24 -0400 (EDT) Received: by relay24.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 2AF7F34E837B; Thu, 27 May 2010 20:13:24 -0400 (EDT) Message-ID: <4BFF0AA0.5000502@iwl.com> Date: Thu, 27 May 2010 17:13:20 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <4BFCCBCB.8020109@bwijnen.net> <84600D05C20FF943918238042D7670FD36CAB1B44D@EMBX01-HQ.jnpr.net> <4BFEB835.2050200@iwl.com> <84600D05C20FF943918238042D7670FD36CAB1B450@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36CAB1B450@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf Subject: Re: [Netconf] WG Last Call for daft-ietf-netconf-with-defaults-08. Please review BEFORE June 6th, 2010 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, 28 May 2010 00:13:39 -0000 Kent Watsen wrote: >>> 10) In section A.3.2, it says "The actual data nodes tagged by >>> the server depends on the defaults handling basic mode used by >>> the server" and "If the server's basic mode is 'report-all', then >>> no data nodes are tagged." I disagree, I think that a >>> "report-all" server that also-supports "report-all-tagged" should >>> tag its defaults, if "report-all-tagged" is requested by the >>> client. >> A report-all basic-mode server has no concept whatsoever of a >> default. Nothing will ever be tagged. Every node is considered to >> exist in the database. Technically, the report-all server is >> tagging all (zero) of its default nodes. > > > I don't agree. For instance, even for a report-all server, when the > client creates an interface, it could choose to not specify the MTU > parameter, at which point the server would use the schema-defined > default (1500) by copying the value into the datastore. I understand > that the server then no longer manages the value as a default, but > that doesn't mean it couldn't compare the current value to the schema > defined value to see if it is, in fact the same and mark it as such. > IMO, if a report-all server can't do this, then it shouldn't > advertize supporting "report-all-tagged". > > BTW, this is how both our SSL/VPN and Universal Access Control > products worked for many releases (i.e. report-all). > Only recently did they update to support the "trim" behavior, which > they were able to do because, yes, even report-all servers can know > what defaults are. > But you implement 'explicit' basic-mode, not 'report-all'. Think of it this way -- The tagged nodes are the ones that the server leaves out of a basic-mode reply. That is true in every case. Right? And the basic-mode=report-all server never leaves any nodes out of basic-mode reply. Right? So the set of nodes the report-all server needs to tag in a report-all-tagged reply is 'NIL'. Right? So the report-all and the report-all-tagged reply would be exactly the same in this case. Right? What matters is whether or not the server keeps a node in its database for a schema default. That is what the basic-mode represents. > Thanks, Kent > > Andy From kwatsen@juniper.net Fri May 28 10:10: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 DC90C3A696F for ; Fri, 28 May 2010 10:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[AWL=1.404, 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 roUdGeRoMRWr for ; Fri, 28 May 2010 10:10:11 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id D78703A68F5 for ; Fri, 28 May 2010 10:10:10 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKS//455tTHjEs0q2+DrvsdP8IePjRsEwR@postini.com; Fri, 28 May 2010 10:10:01 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 28 May 2010 10:08:55 -0700 From: Kent Watsen To: "'andyb@iwl.com'" Date: Fri, 28 May 2010 10:08:55 -0700 Thread-Topic: [Netconf] WG Last Call for daft-ietf-netconf-with-defaults-08. Please review BEFORE June 6th, 2010 Thread-Index: Acr9+pd8PAib4uAsS+iuYCNn5pdXWQAiRJCg Message-ID: <84600D05C20FF943918238042D7670FD36CAB1B453@EMBX01-HQ.jnpr.net> References: <4BFCCBCB.8020109@bwijnen.net> <84600D05C20FF943918238042D7670FD36CAB1B44D@EMBX01-HQ.jnpr.net> <4BFEB835.2050200@iwl.com> <84600D05C20FF943918238042D7670FD36CAB1B450@EMBX01-HQ.jnpr.net> <4BFF0AA0.5000502@iwl.com> In-Reply-To: <4BFF0AA0.5000502@iwl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: netconf Subject: Re: [Netconf] WG Last Call for daft-ietf-netconf-with-defaults-08. Please review BEFORE June 6th, 2010 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 28 May 2010 17:10:12 -0000 > But you implement 'explicit' basic-mode, not 'report-all'. Our JUNOS-based products implement explicit, but the SSL/VPN and UAC produc= ts I mentioned before are non-JUNOS based products. > Think of it this way -- The tagged nodes are the > ones that the server leaves out of a basic-mode reply. > That is true in every case. Right? You could use that definition, but I prefer defining tagged nodes as those = the server suspects as being such. Report-all and trim servers are similar= in that neither is sure if the user set the default value or not. The dif= ference, of course, is that a trim server MUST be default-aware, whereas a = report-all server *MAY* be default-aware. You seem to think that report-al= l servers can not be default aware, but don't assume that. My point is tha= t, *if* a report-all server is default-aware, then it can advertise report-= all-tagged and tag values having the same value as the schema-default; othe= rwise it should not advertize report-all-tagged. > And the basic-mode=3Dreport-all server never leaves > any nodes out of basic-mode reply. Right? Agreed > So the set of nodes the report-all server needs to > tag in a report-all-tagged reply is 'NIL'. Right? > > So the report-all and the report-all-tagged reply > would be exactly the same in this case. Right? With your definition, these are both true. I prefer the definition of tagg= ing defaults when they're presumed to be. For a report-all server, "report= -all-tagged" would return the exact same number of nodes as "report-all", j= ust that now some of them might be tagged, since the server can see they ha= ve the same value as the schema-defined default. Kent From andyb@iwl.com Fri May 28 14: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 F27013A6830 for ; Fri, 28 May 2010 14:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_05=-1.11, J_CHICKENPOX_27=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 O0a0z1-IFniq for ; Fri, 28 May 2010 14:18:01 -0700 (PDT) Received: from smtp114.iad.emailsrvr.com (smtp114.iad.emailsrvr.com [207.97.245.114]) by core3.amsl.com (Postfix) with ESMTP id 0622B3A6806 for ; Fri, 28 May 2010 14:18:01 -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 BF31244C0E5; Fri, 28 May 2010 17:17:50 -0400 (EDT) Received: by relay1.r1.iad.emailsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 680DC44C0BB; Fri, 28 May 2010 17:17:50 -0400 (EDT) Message-ID: <4C0032F7.7030100@iwl.com> Date: Fri, 28 May 2010 14:17:43 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Kent Watsen References: <4BFCCBCB.8020109@bwijnen.net> <84600D05C20FF943918238042D7670FD36CAB1B44D@EMBX01-HQ.jnpr.net> <4BFEB835.2050200@iwl.com> <84600D05C20FF943918238042D7670FD36CAB1B450@EMBX01-HQ.jnpr.net> <4BFF0AA0.5000502@iwl.com> <84600D05C20FF943918238042D7670FD36CAB1B453@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD36CAB1B453@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf Subject: Re: [Netconf] WG Last Call for daft-ietf-netconf-with-defaults-08. Please review BEFORE June 6th, 2010 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, 28 May 2010 21:18:02 -0000 Kent Watsen wrote: >> But you implement 'explicit' basic-mode, not 'report-all'. > > Our JUNOS-based products implement explicit, but the SSL/VPN and UAC > products I mentioned before are non-JUNOS based products. > > >> Think of it this way -- The tagged nodes are the ones that the >> server leaves out of a basic-mode reply. That is true in every >> case. Right? > > You could use that definition, but I prefer defining tagged nodes as > those the server suspects as being such. Report-all and trim servers > are similar in that neither is sure if the user set the default value > or not. The difference, of course, is that a trim server MUST be > default-aware, whereas a report-all server *MAY* be default-aware. > You seem to think that report-all servers can not be default aware, > but don't assume that. My point is that, *if* a report-all server is > default-aware, then it can advertise report-all-tagged and tag values > having the same value as the schema-default; otherwise it should not > advertize report-all-tagged. > I don't understand. Both the trim and explicit servers have their own definition of a default. They know what nodes to omit in a basic-mode reply. These are the nodes that get tagged in a report-all-tagged reply. How would you define it? I do not like "The server presumes this node to be a default". The server knows because it can support its own basic mode. t does not need to presume anything. > >> And the basic-mode=report-all server never leaves any nodes out of >> basic-mode reply. Right? > > Agreed > > >> So the set of nodes the report-all server needs to tag in a >> report-all-tagged reply is 'NIL'. Right? >> >> So the report-all and the report-all-tagged reply would be exactly >> the same in this case. Right? > > With your definition, these are both true. I prefer the definition > of tagging defaults when they're presumed to be. For a report-all > server, "report-all-tagged" would return the exact same number of > nodes as "report-all", just that now some of them might be tagged, > since the server can see they have the same value as the > schema-defined default. No -- a report-all server does not have to 'know' the node has its schema-defined default value. It is not required to have any concept of a default. That is not what wd:default means. It means the server treats that node as a default node, not the node is set to the schema default value. > > > Kent > > > Andy From dromasca@avaya.com Mon May 31 09:28: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 DE2EF3A68D4 for ; Mon, 31 May 2010 09:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[AWL=-0.501, 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 iXlFO-AsjE1X for ; Mon, 31 May 2010 09:28:38 -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 534413A68AA for ; Mon, 31 May 2010 09:28:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,334,1272859200"; d="scan'208";a="191247045" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 31 May 2010 12:28:22 -0400 X-IronPort-AV: E=Sophos;i="4.53,334,1272859200"; d="scan'208";a="479667059" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 31 May 2010 12:28: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: Mon, 31 May 2010 18:26:47 +0200 Message-ID: In-Reply-To: <4BFD57EA.8010103@iwl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: I-D Action:draft-ietf-netconf-monitoring-13.txt Thread-Index: Acr895Ze7uekfzpxTbSal0kbtD/+mAD5ZdgA References: <75C89D709A9670428520E1CF8DD1344F208D0F317B@EUSAACMS0714.eamcs.ericsson.se> <4BFD57EA.8010103@iwl.com> From: "Romascanu, Dan (Dan)" To: , "Mark Scott" , "Ersue, Mehmet (NSN - DE/Munich)" 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: Mon, 31 May 2010 16:28:40 -0000 Mehmet (as document shepherd), Can you please clarify if the WG plans to make any change (back) based on this content, or stick to the current version before submitting the document to the IESG?=20 Thanks and Regards, Dan > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Wednesday, May 26, 2010 8:19 PM > To: Mark Scott > Cc: netconf@ietf.org > Subject: Re: [Netconf] FW: I-D=20 > Action:draft-ietf-netconf-monitoring-13.txt >=20 > Mark Scott wrote: > > Hello, > > > > A new version (v13) of the "YANG Module for NETCONF=20 > Monitoring" draft has been posted. > > > > This addresses comments received on v12 during WGLC, AD and=20 > Gen-Art reviews. > > > > =20 >=20 > I do not remember a public discussion and resolution that led=20 > to changing the datastore name from a container to a leaf. > Since a client has to support this container-of-empty-leaf=20 > all over NETCONF, it doesn't really help to fix it here. > I do not strongly object, but this is a big change so late in=20 > the process. >=20 > I do not understand why this document is defining the NETCONF=20 > session-id and session-id-or-zero typedefs. > The ietf-netconf module is defining session-id-type and=20 > session-id-or-zero-type. There is no way 4741bis is going to=20 > incur a normative reference to this RFC for some out-of-place=20 > typedef. That means 2 sets of typedefs going forward. Quite lame. >=20 >=20 >=20 > Andy >=20 >=20 >=20 >=20 > > In addition some further changes were worked in a smaller=20 > group (which included WG chairs). The noteworthy changes being: > > > > 1. Sec 6, Security Considerations > > a. new security text template (rev4) as agreed by WG > > b. 'username' identified as sensitive data 2. 'username'=20 > description=20 > > updated to specify the standard value for SSH transport=20 > (i.e. the mandatory NETCONF transport). For the optional=20 > transports the derivation remains implementation specific. > > 3. Yang module updates: > > a. added Martin to list of contacts > > b. prefix changed to 'ncm' (netconf monitoring); better=20 > reflects the module name > > c. fixed double reference statement bug in yin identity > > d. added presence statement to locks container > > e. name changed from container to leaf node > > f. name key added for datastores list > > g. added typedef sessionid-or-zero > > h. additional mandatory nodes added (username,=20 > locked-time, namespace) > > i. additional descriptions added > > j. leaf locked-by-session type changed to session-id-or-zero 4.=20 > > updated IANA considerations: > > a. "Yang Module Names" registry reference added for=20 > module registration > > b. 'rfcxxx' removed from module namespace per (netmod)=20 > consensus to=20 > > drop that guideline > > > > Please refer to the Change Log (Appendix A) for details on=20 > all changes. > > > > cheers, > > Mark > > > > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On=20 > > Behalf Of Internet-Drafts@ietf.org > > Sent: May-26-10 12:15 PM > > To: i-d-announce@ietf.org > > Cc: netconf@ietf.org > > Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-13.txt > > > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > > This draft is a work item of the Network Configuration=20 > Working Group of the IETF. > > > > > > Title : YANG Module for NETCONF Monitoring > > Author(s) : M. Scott, M. Bjorklund > > Filename : draft-ietf-netconf-monitoring-13.txt > > Pages : 40 > > Date : 2010-05-26 > > > > This document defines a NETCONF data model to be used to=20 > monitor the=20 > > NETCONF protocol. The monitoring data model includes information=20 > > about NETCONF datastores, sessions, locks and statistics. =20 > This data=20 > > facilitates the management of a NETCONF server. This document also=20 > > defines methods for NETCONF clients to discover data models=20 > supported=20 > > by a NETCONF server and defines a new NETCONF =20 > operation=20 > > to retrieve them. > > > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-13.t > > xt > > > > 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=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > > =20 > >=20 > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From dromasca@avaya.com Mon May 31 09:37: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 0F30F3A677D for ; Mon, 31 May 2010 09:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[AWL=0.849, 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 hvL9oEox7V4U for ; Mon, 31 May 2010 09:37:45 -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 39F413A68A3 for ; Mon, 31 May 2010 09:37:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,334,1272859200"; d="scan'208";a="220713372" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 31 May 2010 12:33:41 -0400 X-IronPort-AV: E=Sophos;i="4.53,334,1272859200"; d="scan'208";a="479667843" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 31 May 2010 12:33:41 -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, 31 May 2010 18:32:49 +0200 Message-ID: In-Reply-To: <4BFD6273.6050304@iwl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: I-D Action:draft-ietf-netconf-monitoring-13.txt Thread-Index: Acr8/cVUwIrKnAaFQ9euiZlbGRAUbwD4IL0g References: <75C89D709A9670428520E1CF8DD1344F208D0F317B@EUSAACMS0714.eamcs.ericsson.se> <4BFD57EA.8010103@iwl.com><20100526.192936.236301148.mbj@tail-f.com> <4BFD6273.6050304@iwl.com> From: "Romascanu, Dan (Dan)" To: , "Martin Bjorklund" 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: Mon, 31 May 2010 16:37:56 -0000 =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > I prefer to have all the common NETCONF typedefs in the=20 > draft-ietf-netmod-types draft. (e.g., session-id, 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 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?=20 Dan (speaking as a contributor) From andyb@iwl.com Mon May 31 09:50: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 61D603A67FF for ; Mon, 31 May 2010 09:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.817 X-Spam-Level: X-Spam-Status: No, score=-2.817 tagged_above=-999 required=5 tests=[AWL=0.782, 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 hTZuVzNg57jf for ; Mon, 31 May 2010 09:50:52 -0700 (PDT) Received: from smtp124.iad.emailsrvr.com (smtp124.iad.emailsrvr.com [207.97.245.124]) by core3.amsl.com (Postfix) with ESMTP id E110A28C0ED for ; Mon, 31 May 2010 09:50:32 -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 735901B4056; Mon, 31 May 2010 12:50:20 -0400 (EDT) Received: by relay22.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 185261B4057; Mon, 31 May 2010 12:50:20 -0400 (EDT) Message-ID: <4C03E8C0.2010401@iwl.com> Date: Mon, 31 May 2010 09:50:08 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <75C89D709A9670428520E1CF8DD1344F208D0F317B@EUSAACMS0714.eamcs.ericsson.se> <4BFD57EA.8010103@iwl.com><20100526.192936.236301148.mbj@tail-f.com> <4BFD6273.6050304@iwl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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, 31 May 2010 16:50:59 -0000 Romascanu, Dan (Dan) wrote: > > > >> -----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? > Another solution is to not use any typedef in ietf-netconf-monitoring. Just use uint32 instead. I really don't care that much. I just want to make sure the IESG is not going to force 4741bis to import session-id from this draft. > Dan > (speaking as a contributor) > > Andy From andyb@iwl.com Mon May 31 10:22: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 D4B103A6A5B for ; Mon, 31 May 2010 10:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=-0.714, 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 k5iQAsBFjmtR for ; Mon, 31 May 2010 10:22:30 -0700 (PDT) Received: from smtp194.iad.emailsrvr.com (smtp194.iad.emailsrvr.com [207.97.245.194]) by core3.amsl.com (Postfix) with ESMTP id 2FEF03A67FF for ; Mon, 31 May 2010 10:22:29 -0700 (PDT) Received: from relay19.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay19.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 6B1321B5230 for ; Mon, 31 May 2010 13:22:17 -0400 (EDT) Received: by relay19.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 3C67F1B40B9 for ; Mon, 31 May 2010 13:22:17 -0400 (EDT) Message-ID: <4C03F03D.9070709@iwl.com> Date: Mon, 31 May 2010 10:22:05 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [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: Mon, 31 May 2010 17:22:50 -0000 Hi, There are many YANG objects in ietf-netconf.yang that do not have description-stmts yet. Originally, I had more of them. The goal was to make the YANG module be the normative source for the protocol details. This did not really work, and we ended up not changing the normative text sections around. The 'capability template' is too entrenched, and this module may be a corner-case anyway. So what to put in the description-stmts? This issue is also showing up in with-defaults. The YANG descriptions are not the same as the normative definitions (as Kent pointed out). Perhaps I should either cut-and-paste or use a reference-stmt instead. The preferred solution seems to be to use the description-stmt as a label (e.g.,config-source == the source of the copy operation), and use a reference-stmt to point at the real normative text. Another solution is to make the description-stmt optional in IETF modules if the reference-stmt is present. Any preferences, comments? Andy From j.schoenwaelder@jacobs-university.de Mon May 31 10:27: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 410AD3A6A70 for ; Mon, 31 May 2010 10:27:41 -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 LDz8rmOgJ5FO for ; Mon, 31 May 2010 10:27:40 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1390728C0E0 for ; Mon, 31 May 2010 10:27:40 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 520AAC0024; Mon, 31 May 2010 19:27:28 +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 JAFub8VgvE0u; Mon, 31 May 2010 19:27:26 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 34120C0006; Mon, 31 May 2010 19:27:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 276E7126679F; Mon, 31 May 2010 19:27:25 +0200 (CEST) Date: Mon, 31 May 2010 19:27:25 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20100531172725.GA2160@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "andyb@iwl.com" , Martin Bjorklund , "netconf@ietf.org" References: <75C89D709A9670428520E1CF8DD1344F208D0F317B@EUSAACMS0714.eamcs.ericsson.se> <4BFD57EA.8010103@iwl.com> <20100526.192936.236301148.mbj@tail-f.com> <4BFD6273.6050304@iwl.com> 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@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 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, 31 May 2010 17:27:41 -0000 On Mon, May 31, 2010 at 06:32:49PM +0200, Romascanu, Dan (Dan) wrote: > > > > -----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? The ietf-yang-types module is for generally useful types - I do not think NETCONF specific types belong there. They should either be in an ietf-netconf-types module or straight in ietf-netconf. The last time we discussion session-id and friends, the proposal was to keep them in the monitoring document and to replace them with an import once we have a better document to import them from. I agree with Andy (very rare these days but it does happen ;-) that importing something from ietf-netconf-monitoring into ietf-netconf is not what we want. Perhaps the solution is to add a comment stating that these types might be imported in future versions from a netconf specific yang module. /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 Mon May 31 10:37: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 618973A6A75 for ; Mon, 31 May 2010 10:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-GRTmOs+ETn for ; Mon, 31 May 2010 10:37:30 -0700 (PDT) Received: from smtp154.dfw.emailsrvr.com (smtp154.dfw.emailsrvr.com [67.192.241.154]) by core3.amsl.com (Postfix) with ESMTP id DA1913A6A76 for ; Mon, 31 May 2010 10:37:29 -0700 (PDT) Received: from relay25.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay25.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 5FCB93600FD; Mon, 31 May 2010 13:37:18 -0400 (EDT) Received: by relay25.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 2256A3600DF; Mon, 31 May 2010 13:37:18 -0400 (EDT) Message-ID: <4C03F3C2.4040604@iwl.com> Date: Mon, 31 May 2010 10:37:06 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , Martin Bjorklund , "netconf@ietf.org" References: <75C89D709A9670428520E1CF8DD1344F208D0F317B@EUSAACMS0714.eamcs.ericsson.se> <4BFD57EA.8010103@iwl.com> <20100526.192936.236301148.mbj@tail-f.com> <4BFD6273.6050304@iwl.com> <20100531172725.GA2160@elstar.local> In-Reply-To: <20100531172725.GA2160@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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, 31 May 2010 17:37:33 -0000 Juergen Schoenwaelder wrote: > On Mon, May 31, 2010 at 06:32:49PM +0200, Romascanu, Dan (Dan) wrote: > >> >> >> >>> -----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? >> > > The ietf-yang-types module is for generally useful types - I do not > think NETCONF specific types belong there. They should either be in an > ietf-netconf-types module or straight in ietf-netconf. The last time > we discussion session-id and friends, the proposal was to keep them in > the monitoring document and to replace them with an import once we > have a better document to import them from. > > I agree with Andy (very rare these days but it does happen ;-) that > importing something from ietf-netconf-monitoring into ietf-netconf is > not what we want. Perhaps the solution is to add a comment stating > that these types might be imported in future versions from a netconf > specific yang module. > > I agree with you (!) It is too late to add a 'ietf-netconf-types' module to the yang-types draft. I never imagined these types would go into 1 of the existing modules. Originally, I had all these "NETCONF related typedefs" in my netconf.yang draft. They got removed because they were not directly used within the objects. IMO, we should add the ietf-netconf-types module to 4741bis now, and start with the session-id-type in ietf-netconf.yang. > /js > > Andy From mbj@tail-f.com Mon May 31 11:37: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 1754E28C12F for ; Mon, 31 May 2010 11:37:39 -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 wh0E7c13tx2k for ; Mon, 31 May 2010 11:37:37 -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 57EBF28C11D for ; Mon, 31 May 2010 11:34: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 4BA6E616002; Mon, 31 May 2010 20:34:30 +0200 (CEST) Date: Mon, 31 May 2010 20:34:27 +0200 (CEST) Message-Id: <20100531.203427.218922716.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4C03E8C0.2010401@iwl.com> References: <4BFD6273.6050304@iwl.com> <4C03E8C0.2010401@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] 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: Mon, 31 May 2010 18:37:39 -0000 Andy Bierman wrote: > Romascanu, Dan (Dan) wrote: > > > > > > > >> -----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? > > > > Another solution is to not use any typedef > in ietf-netconf-monitoring. Just use uint32 > instead. I think this is a reasonable way forward. We should remove the two session-id types from monitoring, and just use unit32. > IMO, we should add > the ietf-netconf-types module to 4741bis now, and start > with the session-id-type in ietf-netconf.yang. 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? /martin From andyb@iwl.com Mon May 31 12:17: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 0745628C127 for ; Mon, 31 May 2010 12:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.629 X-Spam-Level: X-Spam-Status: No, score=0.629 tagged_above=-999 required=5 tests=[AWL=0.294, 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 uTH86BnUbUbr for ; Mon, 31 May 2010 12:17:49 -0700 (PDT) Received: from smtp164.dfw.emailsrvr.com (smtp164.dfw.emailsrvr.com [67.192.241.164]) by core3.amsl.com (Postfix) with ESMTP id 280D028C125 for ; Mon, 31 May 2010 12:17:49 -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 4D77214C9D; Mon, 31 May 2010 15:17:37 -0400 (EDT) Received: by relay16.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 0C60714C9C; Mon, 31 May 2010 15:17:36 -0400 (EDT) Message-ID: <4C040B45.6050704@iwl.com> Date: Mon, 31 May 2010 12:17:25 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Bjorklund References: <4BFD6273.6050304@iwl.com> <4C03E8C0.2010401@iwl.com> <20100531.203427.218922716.mbj@tail-f.com> In-Reply-To: <20100531.203427.218922716.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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, 31 May 2010 19:17:50 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: > >> Romascanu, Dan (Dan) wrote: >> >>> >>> >>> >>> >>>> -----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? >>> >>> >> Another solution is to not use any typedef >> in ietf-netconf-monitoring. Just use uint32 >> instead. >> > > I think this is a reasonable way forward. We should remove the two > session-id types from monitoring, and just use unit32. > > >> IMO, we should add >> the ietf-netconf-types module to 4741bis now, and start >> with the session-id-type in ietf-netconf.yang. >> > > 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? > I am thinking that there will be more types later. I have a specific use-case already implemented, which is the 'sysStartup' notification event: http://www.netconfcentral.org/modulereport/yuma-system#sysStartup.162 It includes any boot errors in the format. http://www.netconfcentral.org/modules/yuma-netconf/2010-05-24#RpcErrorType.399 Since NETCONF cares about real-world use-cases -- not all vendors want the server to crash if there are errors in the config. The server (or operator) can figure out from the boot error messages what went wrong, and decide how to fix it. Of course, the only way to get the 'sysStartup' event is via the notification replay buffer. It is always the first event in the buffer (until the buffer rolls over). The enumerations from various fields are likely to show up in RPCs and notifications over time. IMO it is cleaner for a ietf-foo module to import from ietf-netconf-types because it is more precise and less complexity for the reader. The modules would be in the same RFC to prevent a normative reference. > > /martin > > > Andy